Being an Engineer

S2E02 Soliciting Negative Feedback, Understanding The Problem, & Building Sales Success | Ryan Frederick

January 15, 2021 Ryan Frederick Season 2 Episode 2
Being an Engineer
S2E02 Soliciting Negative Feedback, Understanding The Problem, & Building Sales Success | Ryan Frederick
Show Notes Transcript

Ryan Frederick has spent his career building software product companies and during this episode shares just a few insights he has learned over the years. Directly applicable to both software and hardware companies, listeners will find his instruction a valuable asset in their bag of development tools. Ryan has also written two books, one about starting a new company (The Founder’s Manual) and the other about managing a services company (Sell Naked). 

 

The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.testfixturedesign.com and www.designtheproduct.com 


About Being An Engineer

The Being An Engineer podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people resources, and opportunities. We feature successful mechanical engineers and interview engineers who are passionate about their work and who made a great impact on the engineering community.

The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.teampipeline.us

Aaron Moncur:

Hey everyone, we're looking to add a new member to our engineering team. Ideally, we're looking for a senior level mechanical design engineer in the Phoenix area, who has experienced designing custom automated machines, equipment, and test fixtures. Also, having working experience with controls and system integration is a plus, if you'd like to apply or suggest Someone, please email us at info@testfixturedesign.com. The Being An Engineer podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people resources and opportunities. Enjoy the show.

Ryan Frederick:

Whenever you get to a certain level of understanding a problem, and when you think you understand it, well, you're probably only 30% to the level of understanding that you need to be able to build a product to solve the problem. And and what I've come to now believe is that if you don't understand the problem at an expert level, and to that end, I mean better than the users understand the problem, then you probably don't have much of a hope of building a product that is going to solve the problem in a valuable, meaningful way for them.

Aaron Moncur:

Hello, and welcome to the Being An Engineer podcast. Our guest today is Ryan Frederick, who started his career as a software developer and describes himself as a product person at heart. He started and grown several software and service companies today to helping them advance from inception, to viability to sustainability. I've been excited to talk with Ryan, because he is a little bit different than our typical engineering guest. He certainly works in the world of technology, but it's not an engineer himself. And as far as I know, it doesn't work directly with engineers, either. However, he does have deep experience, working with teams, and driving success within teams that are developing products and I think we can all relate to that. So with that, Ryan, welcome to the podcast. And thank you so much for joining us.

Ryan Frederick:

Aaron, good to be with you.

Aaron Moncur:

So let's start off by maybe telling the listeners a little bit about who you are, what you do now, and kind of how you got to where you are today.

Ryan Frederick:

Yeah, it's been a serendipitous road. I never wanted to be a big company person. So I knew the the entrepreneurial journey was probably more in the offing for me. And you know, in when that's the case, it's almost always more opportunistic than strategic, right, because you end up you know, getting access to or becoming aware of a problem and then trying to build the product to solve it. And then you meet people like investors and, and others an ecosystem that then support you in that in that arena. And then it opens up other, you know, options, you know, to work on other problems. And so been fortunate from that perspective. And then nine years ago, I joined AWH as a principal. And this is really my first step into...

Aaron Moncur:

What is AWH?

Ryan Frederick:

Yeah, we're a digital product and data consulting firm. So we help clients build net new software products, and then work to solve some data challenges sometimes, while we're building the net new software product, and sometimes we work on day to day challenges not associated to the products that we're building.

Aaron Moncur:

Alright, I'm probably gonna stop you like way too often here, because there are terms I'm not familiar with net new, what does that mean?

Ryan Frederick:

Yeah, it's just my way of because there are lots of software products that because the software product has never done, right. And so it net new for us means that the product doesn't currently exist, and we're building maybe a better way to phrase it moving forward is we often get engaged by our clients to build version one of a product.

Aaron Moncur:

Got it. The net new is just version one.

Ryan Frederick:

Yep, version one. And, and so we, you know, we have a team of designers and engineers and DevOps people and QA people, right, that engage with clients to build those, those version one products, sometimes we stay in, in place to help, you know, build version two and version three, etc. But, you know, our gig is really to take this murky vision of how they want to approach solving a problem for their bit their, their business and then building a software product to hopefully solve that problem.

Aaron Moncur:

Great, and you started off yourself as a developer, right?

Ryan Frederick:

I did. I originally started learning how to code I went to DeBry out of high school, and started to learn how to code there and you know, it'll date myself. But you know, we were studying Pascal and COBOL. And you know, lots of languages that are not very widely used anymore. And then, so I learned just enough to sort of be dangerous as a developer. And then the first company that I actually joined, that turned out to be a startup, we just didn't know that that's what we should call ourselves at the time. I gravitated toward the business side. And so I've been part of starting six software companies, it in most cases leading the product development, but then also engaged on the sales side and the marketing side to to figure out, okay, what are we building? How are we will building it for what's the right positioning, what's the right messaging, etc. So a big piece of, you know, what I think about a lot is, you know, not how, you know, we we make zeros and ones do what we need, you know, the product to do, but how do we ensure that we're building the right thing, and we're doing it in the simplest, most elegant way possible, so that we can drive as much value to the users as possible, especially given the fact that we're often building version one of products. So it's the first time that users are going to engage with the product. And if we don't get that initial user experience, and that initial onboarding right, the fact that it's incredibly scalable, and the code is powerful and robust, sort of doesn't matter. Version one of products often is about how well do you understand the problem? And how simply are you solving the problem?

Aaron Moncur:

So I think that's a big point, how well do you understand the problem, right? It's such a simple idea, but has huge ramifications down the road as you're developing your product? How does your team go about ensuring that everyone really truly understands the problem that they're solving?

Ryan Frederick:

Yeah, it is. It's way more time and energy investment than anybody wants it to be. Because we are wired and even as, as professionals in the space, we're innately wired as humans to want to begin to build and to solve as soon as somebody presents us with a problem. And so that, what you have to do is you sort of have to hold back and you have to reserve that desire to want to solve and build too early. And so often what what we do in working with clients is, we will make them initially almost defend the problem and to sell us on why this problem is worth working on, and why this problem is worth building a product around. So we often sometimes almost act like investors with with our clients, because we've got opportunities to build lots of different products with lots of different clients. And we want to work on the ones that are the most interesting, and the ones that are the most impactful ultimately, and, and so when we get into it, we start really just asking the client and then as we're digging into the problem ourselves, it's just a series of of 'why's' right? Why does this matter? Why does anyone care? Who's this, you know, who's this gonna help, right? And figuring out that whenever you get to a certain level of understanding a problem, you're probably still only 30. When you think you understand it, well, you're probably only 30% to the level of understanding that you need to be able to build a product to solve the problem. And and what I've come to now believe is that if you don't understand the problem at an expert level, and to that end, I mean, better than the users understand the problem, then you probably don't have much of a hope of building a product that is going to solve the problem in a valuable, meaningful way for them. So I think you've got to get to the problem, you've got to evolve to the point of understanding the problem at an expert level.

Aaron Moncur:

I love the way you put that you you have the customer defend why the problem is worth solving that's kind of flips the paradigm on its head a little bit, right? Because typically, as the developers as the team that's hired to solve the problem. You want to jump in and just assume that the problems we're solving almost find reasons why this problem is worth solving. Right? Because you want to have a job, but but you're saying flip that paradigm on its head and ask the customer and help me understand why is it really worth solving. This problem what what need is going to solve? That's a really great way to think about it, I think. So you started off as a developer and eventually made your way into sales and marketing and business development? Why what do you think you became more interested in the business side of things, then purely just the technical development side of things?

Ryan Frederick:

Yeah, I think it's because of the people and the people aspects of it. Because I think I hit a realization at some point that anything can get built. So it's not you know, whether something can get built or how it gets built, or how well it gets built? It is really, why is it getting built? Who's going to use it? Who's going to value it? And what's the, what's the meaning and purpose of what's getting built? And even back when, when I was a developer, you know, I would look at it and say, Oh, you know, we don't really we were over software in in the early 90s, when I was, you know, when I was a developer, or certainly over software now, right? There's lots of software and digital products that get built, that ended up in a in a digital product graveyard, right, that they never quite met the threshold of being successful and being useful and being that meaningful. And lots of code got written, and lots of time got invested in these products. That didn't go anywhere. So I became more interested in well, why is that? Right, than the actual coding of the products? Because it became more interesting to me of, okay, this product that's coded, well designed, well, is not succeeding, and it's not going anywhere. Well, what are the problems associated to that versus you know, that the the challenge of coding something because something can get built? I think we've I think we've gone through a couple of thresholds over the last couple of decades. I think the first threshold was, could we write really scalable, effective code? And could we architect software products so that they could be really scalable? And then we solved that problem? And then we went through a period of it being all about the code, and how efficient was the code, right? And how fast could the code process content and process data, and then we sort of crossed that threshold. And then we went into the design era of realizing, oh, we can build really powerful stuff now. But if we don't build stuff that has a good user experience, and has a good user interface, that are actually enjoyable to use, and easy to use, doesn't matter, you know, how robust the code is. So we went through a design, you know, period of UX and UI becoming critically important. Now, I think we're going into another threshold, which is, we, we know how to architect it, we know how to code it, we know how to build things that are beautiful. We know how to build user experiences that are lean, right. But now, I think it becomes, you know, this is sort of circles back to the beginning of the conversation. Now I think the challenges, we'll shoot a piece of software get built to solve a problem, or there are other ways to solve it. And and really, I think it becomes the almost humanistic part of it and the problem understanding part of it, and the distribution part of it, versus can we build something that's beautiful. And that's powerful? Of course we can. Now the question is, should we? And if we do, how is it going to get distributed? That How is it going to become commercially viable? Right, so I think we've crossed into another threshold of creating products.

Aaron Moncur:

Yeah, in the, in the medical device world, the they have design verification and design validation, they're called and verification is did we build the product correctly? And then validation is did we build the correct product? And I think that's, that's what you're getting at? I have another question. I wanted to ask you. So you talked about this validation? Or did we build the correct product? Right? Is this a product that actually has a place in the marketplace? As opposed to all of those lines of code that end up in the software graveyard? Are there cues that you have learned over the years, you know, in the beginning, or even in the middle of a project that you can pick up on or your teams can pick up on and say, my spidey senses are starting to tingle here. I'm not sure that this product is going to be something the market really needs? Or do you think you really just need to wait until the product is finished and shipped to get actual feedback from the market as to whether or not that product has a chance of success?

Ryan Frederick:

Now, I think there are signs along the way, especially as you should be iterating on the product, you know, with, with customers early, even if it's a group of, of ten customers early, but there are signs that I think the biggest sign is, users will will tell you what they want and what they need to solve the problem to the best of their ability. The challenge there is, until they actually get into the product to solve the problem. They don't know exactly what they need or what they want but when they begin using the product, now the lights start to go off, and the dots start to connect. And then and then they can begin to articulate better, when I said I wanted it to do this, what I really meant is I wanted it to do this. Because at the beginning, when it's just conversation when you're just doing sort of verification, if you will, right, with users, that's almost all verbal, right? It's almost all interview based, it's almost all survey based. And they they can only tell you to a certain degree of the the efficacy of a product, right. But once they get into it, and they start using version one, now they can tangibly start to tell you, whoo, I know I told you, I wanted to work this way A, B, and C. But now I see that I actually need a B and then any D, and then I need C, right. And, and so there's a real tipping point there, when you get users into the first version of the product, which is often called you know, an MVP, or prototype or what have you. I don't care about the labels, any any product that users get their hands on, and they can use it on their own is version one to me, you can label it anything else that you want to but if users are using it, it's version one. And, and so that's a big tipping point. The other thing along that same line that happens is, I feel really strongly that you've got to have analytics built into that version, one of the product, because users during the verification process will say, will articulate things and verbalize how they want it to work. And then when they get into the product, you will see them through the analytics using the product very differently than they told you how they were going to use the product. And that's that's both a huge opportunity and a huge red flag. Because at that point, again, the tangible nature of now being able to use the product versus just theoretically talk about it changes their perspective and their input dramatically.

Aaron Moncur:

Well, you you've worked with a lot of startups over the years. And can you share with us? What are some of the common pitfalls that that startups you know, stumble into? And and how can new teams who might be listening to this avoid those pitfalls?

Ryan Frederick:

Yeah, I think the you know, some of the biggest one we've already talked about, which is they don't understand the problem well enough, before they start building the solution, they will build the first version of the product as they as they should, based upon what users are saying, but then it becomes too much about about them, and they sort of go into a vacuum building the product, and then they come out with the product. And then they don't have the level of adoption and use that they expected they would. And they you know, they then sort of fall back on the fact that that well, we built what the users told us that they that they wanted, but now nobody's using it to the level that we expected. And we don't have the kind of traction that we expected around it. And it the the point that they miss through that process is that they have to be able to transition from what users are saying to what users are actually doing. The other thing that they miss is they have to transition from doing product validation in the in the positive to doing product validation in the negative. And what I mean by that is that they've got to transition from saying to users, tell me what you like about it, tell me what you like about this feature, tell me how this experience is going to be valuable to you, etc. to shifting as they continue to iterate with those users on the product to tell me what you don't like about what we've done. Tell me why this feature won't be a value to you. And if they don't make that transition from what I call positive validation to negative validation, that they're likely to release the first version of the product that is based upon a lot of false positives from the users because the users will have continued to give them positive feedback, because they never gave users an opportunity to ask permission to give them negative feedback.

Aaron Moncur:

I think that's the big deal because people are typically nice and want to please others. And so if you don't give them if you don't make it clear that it's okay to give me negative feedback, sometimes people won't do that. Has that been your experience as well?

Ryan Frederick:

Absolutely, because they won't, because they, they, they want to be nice, they want to be supportive, presumably, if they are a small group of users that you've gotten together that that, you know, are okay, investing some time and energy, trying to help you to build a product to solve this problem. Presumably, they want the problem solved. And presumably, they want you to be successful solving it. So they're mostly going to give you positive feedback. That's okay. And that's okay at the beginning. But if you don't evolve that to giving them permission, and almost taking it to the extent, which is totally counterintuitive, taking it to the extent of saying that, thanks for the positive feedback, appreciate it. Now, I want you to tell me what you hate about it. Right? And really dig into not only giving them permission, but almost eliciting out of them, what they don't like about what you've done with the product.

Aaron Moncur:

Yeah, encouraging or even demanding that negative feedback?

Ryan Frederick:

Yep. Because otherwise, they just won't do it.

Aaron Moncur:

That's a great insight. great insight. Speaking of insights, I wanted to talk to you a little bit about sales, because as we all know, if we can build an incredible product, but if we don't know how to sell it, then it's not going to be a commercial success. And everyone on the team, nobody likes that. So you've been involved with with sales for much of your career. And I have, to a much lesser extent, I would say I'm still learning. But I spent a few years really focusing on sales. And one of the, one of the insights I think I've come to is that persistence is so crucial. I mean, I can contact 100 people once each, and probably get nowhere. Or I can contact 10 people 10 times each, or maybe even five people 20 times each. And even though the total number of touch points is the same for all three of those scenarios, what I focus my energy on following up consistently with a fewer number of people, the results are much better. It seems like a simple thing. But it's proved to be powerful for me, have you found that to be the case in your work as well? And maybe what other insights can you share about finding success success in selling your product?

Ryan Frederick:

Yeah, I think sales is all about relationships. And and, and that's probably why you've seen the the more contacts you have with a smaller number of contacts, you get a better return. Because every one of those, those outreaches, and every one of those exchanges is a wrong on building a ladder of a relationship. And sometimes they can be very innocuous, right? Sometimes it's Nope, not ready sometimes Nope, timings not right. Sometimes Nope, budget hasn't gotten approved, whatever the case might be. But every one of those micro interactions is the foundation to a relationship. And so that's key. And that's why sometimes it's it's the numbers game and sales is different than what we what we think the numbers game is. Sometimes the numbers game and sales isn't volume, it's actually quality with a fewer number of people but solidifying a better relationship with with those fewer people.

Aaron Moncur:

I love how you put that I'm an engineer, and I think you know very linear linearly and analytically, and I think, okay, I need to contact this person. And then I'm going to schedule a follow up for you know, a week later, and then I'm going to do another follow up two weeks later. And I'm going to use text here, and I'm going to use phone here and I'm going to use email there. But you've, you've condensed that whole thing to you're just building relationships, that's really what it comes down to.

Ryan Frederick:

Yep, that is really what it comes down to. But you know, doing it in a multifaceted way also makes sense. Because the the, if you take a step back and look at it from that individual relationship from a macro view, each one of those different communication channels has a different flavor and a different sense to it. Right? And it's in some of them are more formal, and some of them are or are less formal and more informal, right? It's like texting. So the those communication channels also have a different dynamic to them as a micro component to building the relationship. Something that I think is, is is also super counterintuitive, is that I like the jobs to be done methodology around, you know, figuring out what a problem is and what a work processes around it and where the gaps right and what a better future state would be. And if you're selling a product. In particular, if you go through a jobs to be done exercise and building the product, that jobs to be done work that you've done around building the product should also make it over to marketing and make it make it over to sales. Because the messaging and the positioning of the product is baked into that jobs to be done work that helped to define the problem, and the work process and the new reality and sales. Same thing. Because when you're selling something, every when you're selling something to has a current state, and they have a future desired new reality, and what you're really selling them is the existence of that new reality and the path to get to that new reality. And if you use jobs to be done in creating a product, you can use that same jobs to be done methodology to support your sales and marketing efforts.

Aaron Moncur:

Yeah, they have the hope that there is this new reality and you're selling them the belief that you can help them get there. Well, this is probably a good time to take a short break and share with the listeners that testfixturedesign.com is where you can learn more about how we help medical device engineering teams who need turnkey custom test fixtures or automated equipment to assemble, inspect, characterize or perform verification or validation testing on their devices. We're speaking with Ryan Frederick today who among other things, is a product and company builder in the software world. Ryan, I wanted to ask you a little bit about how software and hardware companies can work together. Obviously, we are a hardware company, most of the people we work with are also hardware companies. Occasionally we have customers ask us to implement software in our design. So we do plenty of you know, automation type software, but we don't create our own, you know, mobile or desktop apps. How should hardware companies approach working with with app development teams like AWH, kind of help us understand what should we expect during that collaborative process?

Ryan Frederick:

Yeah, I think the the champ, the, the end results should be similar. But I think the the where you started the process of getting there are different at the beginning. And what I mean by that is even if you think about just the design process of designing a piece of hardware versus designing software, when when you're designing hardware, because it's actually going to have to at some point, get tangibly produced. And and and even if you're building an initial prototype, right, it still has to go to some level of of specification for the hardware, you know, for the prototype to get produced. And then once you go beyond prototype and into more broad manufacturing, right, now you've got tooling, and you've got components and you've got supply chain thinks as part of it. So designing a piece of hardware gets a very specific and very particular really fast, where designing software is much more iterative, right? And you can, you can try a user experience and you can, you can try a user interface, and you can release three of them at the same time. And ABC test them against each other right to see which one resonates and which one works the best. You can't really do that with hardware. I mean, you could, you could presumably build three different prototypes and release three different products. But in most cases, that doesn't happen, right? And so I think, at the beginning, hardware is much more constrained and much more specific than software is. And I think then, so we just think about it from that perspective, they start, you know, very differently, I think where they start to intersect, and we have several IoT clients that are both hardware and software companies. I think where the intersection begins to happen is when you think about the user experience, holistically, and the fact that the hardware in most IoT situations is sort of the on ramp or the gateway to the, to the digital experience into the data, right, then you've got to begin to think about, alright, the hardware footprint is going to be this probably very exact and very specific as we were talking about. But you then also have to take into consideration will, what data do we need? And what user experience overall, are we trying to facilitate? And does the hardware facilitate that or doesn't it? And if it doesn't, yet, what do we have to do with the hardware to evolve it so that it facilitates the digital experience that we want for users and for us, right as the product owner, as part of the product footprint, and so the digital overlay has hardware implications for sure that then feed the digital experience for users. And then for the product owner, because the product owner in most IoT cases, is interested in the data flow primarily, right? How is someone using the hardware? Right? What's the state of the hardware? You know, we want to sell them upgrades to the hardware add ons to the hardware. And all of that means that you've got to have data flowing about all those aspects of the hardware. So what's that data plumbing look like?

Aaron Moncur:

Yeah, it can you give us a sense, I'm sure this varies wildly. But are there some rules of thumb that maybe we can implement to anticipate what what expenses are going to be like, for developing a new piece of software?

Ryan Frederick:

Yeah, it varies greatly, of course, depending on what the complexity and the footprint of that that piece of software is. In it, it also depends on how sort of aggressively you know you want to go, you want to go after it in that it is the if version one is, hey, we want users to be able to have their own accounts, save their progress, have individual dashboards associated to their accounts, etc, right? That's a different product than a product that you take to users and you you show them how to use it. And but they can't use it on the row. So that's one call off point. That's pretty, that's pretty drastic, right? The the users can use it on their own, or you're at a point where you're still sort of demoing it trying to still work through validation and iteration as part of that. Because there's lots of back end service. And support things that vary depending on whether a user can use it independently or not. You know, if, if, when we engage with clients, and we talk about a new net new software product, that we would consider a robust version, one product, where users can use it independent of the client company and independent device, you know, that typically starts around 150k, and then go and then goes up from there. You know, we build prototypes that are not user independent, for less than that, you know, sometimes in the 30 to 50k range. But, you know, when I have conversations, when our team has conversations with prospective clients, you know, we want them, we want to sort of want to level set expectations that I was having this conversation with, with a prospect who became a client. And she said to me, look at what am I going to be in for over the first sort of nine months of this, and I knew that she had, you know, several phases in mind for the product, she understood the problem really well, she had a great product division already. And I said, Look, you know, if if, if we're going to be honest about it, you're probably going to be into this for $250,000, and over the over nine months, and it ended up being something like 237. But it was still pretty close to 250. So you know, how to build if you're going to build really commercially viable software. It's, you're not going to get away with spending, you know, 10, or 12k, doing it? Can you build a really, you know, low fidelity, inexpensive, you know, prototype or something like that, for that amount of money? Sure. If you're going to have users in the product, and you expect to then be able to go from version one to version two to version three, pretty quickly, it's not going to be, you know, it's not going to be a 20k engagement. And I probably should add in here, too, because I've been thinking about this a lot lately. And it's pretty popular, no, you know, no, we're low code, you know, is starting to get some momentum, right, where you take off the shelf stuff, and you essentially, you know, wire that together and and take and build an app and take a product to market using, you know, no, we're low code. And I think in that can work early on for version one of a product, but I think what ends up ends up happening inevitably, is that a product that is no or low code where you just take an off the shelf, stuff that stuff and wire it together. It is is sort of the is the the kernel tool product, but I wouldn't say that you've actually got a product yet, right? Because none of it is is none of it is is really scalable. None of it is certainly you don't have any intellectual property right to your efforts because anybody else could take those off the shelf things and also wire them together. So you don't have much defensible in the product and it becomes it so I'm not sure low code or no code equals you having a product, I think equals you having the maybe initial stages and phases to having a product, but I don't think that low code and no code ultimately equal you having a product.

Aaron Moncur:

Yeah, I see what you're saying. Well, let me switch gears a little bit here and ask about a couple of books that you have written. So you're an author, as well, you have two books that I know of, anyway, one of them is already out called the Founders Manual. And another one that is set to release in February, I think, is called Sell Naked, and Other Advice for Growing and Managing Service Firms. Tell us a little bit about both of these books.

Ryan Frederick:

Yeah, thank you for the opportunity to the Founders Manual really came out of to me over over the course of a couple of years, jotting down notes around, if I had to do it over again, what would my sort of 20 year old self want to know about starting companies? And as I started compiling that list, you know, I realized that I had a, you know, something, you know, happening that could become a book, and I reached out to a publisher, and they said,"Yep, we'll do it". And so I hadn't really no intention of of writing a book. And so it just sort of materialized that way. But I, the founders manual, the intent around the founders manual, is to give people some insight into what's the real existence of building products, being a founder and trying to, you know, start a company on top of the product, and, and hopefully helps people increase the odds of success in in the endeavor. Because it's, most things don't work, right, most new products don't succeed, most new companies don't work. So it was really my effort to give people a look behind the curtain for, you know, somebody that's been through this for many years to give them some principles that they could consider as part of the process. And then, yeah, and then Sell Naked. You know, I, I've now been a principal at AWS for nine years. And I discovered that running a services firm is very different than running a product company. And, and so, Sell Naked is really a compilation of the things that I've learned over the last nine years, running AWH of those differences, and why it's really easy to start a services firm. I mean, it's easy, it's easy to put out a shingle and say, I'm now a consultant around this, or I now, you know, a CPA or a lawyer, you know, etc. And I've got a particular craft, it's a very different thing to then turn that services firm that's easy to start into something that's growing, and that is successful. And that isn't super fragile. Because since services firms are so easy to start, they're also really hard to grow. And they're also very fragile businesses, because in part because they're so easy to start.

Aaron Moncur:

I can attest to that I have found growing a services business to be one of the most complex challenges that I have faced in my career to date. It's kind of funny how we evolve right? In the beginning, I was the technician, right, I started Pipeline and I was the technician, I was the only technician and that's what I did. And then we grew a little bit. And then I became the the project manager. And that's what I did. And then we grew a little bit more, and I became the business owner, even though I have always been the business owner, but I started to actually act like a business owner. And now I'm in the face of growing this business and making it sustainable and solid. So I fully appreciate everything that you're saying right now. And I'm personally really looking forward to to reading that book, as well as the Founders, The Founders Manual as well. Well, Ryan, I don't want to keep you too long today. But I really appreciate your time and just sharing some of your knowledge with us before I let you go, how can people get ahold of you?

Ryan Frederick:

You're probably the easiest way is my personal site is Ryanfrederick.biz, and there are links out to the the books out there or there will be for the new book soon. And then AWH site is is awh.net and you can also get in touch with me through there.

Aaron Moncur:

Terrific. Is there anything that we haven't talked about that you think we really should have?

Ryan Frederick:

You know, I think that one of the things that I've learned over time is when you're building new products or you're trying to to build a company, whether it's a product company or a services firm, that you give yourself a chance to be more successful at it, the less you make it about yourself. And so if you if you work in the products, best interest in the company's best interest in your clients best interest and your team's best interest, and if you're if you're the last person in line of who you're trying to sort of satisfy and serve, then you're you, you probably have the right perspective around it. Because we often start building products and companies, you know, because it's a very ego-centric thing to do, right. But I think we quickly have to move off of that, to it being you know, about us, least of anybody that's involved in the equation, and if you can do that, I think it just, you know, it gets you in the right perspective, and I think it gives you a chance of being more successful with it.

Aaron Moncur:

That's an interesting insight. Thank you very much for sharing that. Well, Ryan, this has been awesome. Thank you again, so much for spending some time with us. And we'll see you next time on the Being An Engineer podcast. I'm Aaron Moncur, founder of Pipeline Design, and Engineering. If you liked what you heard today, please leave us a positive review. It really helps other people find the show. To learn how your engineering team can leverage our team's expertise in developing turnkey custom test fixtures, automated equipment and product design, visit us at testfixturedesign.com. Thanks for listening!