Latest / The Life-First Solopreneur / 20. Turning Your App Idea Into A Reality With Josh Jordan
Transcript
- Carly Ries (00:00): I just have to say, I am the least technical person on the planet. I don't understand it at all. And Josh, you have so thoroughly put the whole process into something that I can understand. So if you're listening right now and you don't have the tech background, keep listening, this is so important. Intro (00:19): Bigger, doesn't always mean better. Welcome to the One-Person Business podcast, where people who are flying solo in business, come for specific tips and advice to find success. As a company of one, here are your hosts, Joe Rando and Carly Ries. Joe Rando (00:37): Hello, and welcome to the One-Person Business podcast. I'm one of your hosts, Joe Rando, Carly Ries (00:42): And I'm Carly Ries. Joe Rando (00:44): Today we're gonna be talking with Josh Jordan. Josh has been building software applications for over a decade. He is going to talk about what you need to know before hiring a software developer for your app or your website. Josh has worked at massive corporations like Amazon and Vistaprint. In fact, when you talk to Alexa, you're really talking to Josh's code. He's done some startups as well, where he's only been one of a couple of software engineers and he got bitten by the startup bug when he did that. He has since founded a couple of businesses, helping startups and small businesses build their tech products from ideas to scale. He's worked on lots of different things from web apps to mobile apps. He lives in upstate New York. He has a wife, kids, and a dog. Josh splits his free time between typical geek activities like serious board gaming and writing code for fun as well as atypical geek activities like hiking and camping, which involve moving away from the keyboard. Plus, I've worked with Josh on the LifeStarr app. I've worked with a lot of software people over the years, and he's an amazing guy. He's going to have a lot of great insights for you. So Josh, does that sound about right? Did I sum you up? Josh Jordan (01:55): Yes. Thank you for that. Joe Rando (01:57): Also, I know that you have a book coming out that we're going to talk about today. Maybe you could tell us just a tad about that book. Josh Jordan (02:04): Yeah. So it's called Starting Your Startup, seven steps to launching your app on web mobile. I really wanted to help entrepreneurs come through the process of starting with a single idea and figuring out how they're going to turn it into a real software product that you build a business on top of. I think there's a lot of guidance out in the ether about how to work with developers and how to turn your idea into a spec, but nobody's really bringing that together. What I want to really talk about is how you build a business on top of technology, Joe Rando (02:33): This would apply to solo entrepreneurs too, right? Somebody that was trying to do a One-Person Business, but needed an app. Josh Jordan (02:38): Absolutely. I think it applies especially to solopreneurs because they aren't going to have a technical co-founder who can manage that process for them. And there's a lot of gotchas working with developers, especially if they're not going to be full-time permanent employees in your company. You really want to be efficient about how you use them. There's a lot to know about the software development process. Carly Ries (02:57): I just have to say, I am the least technical person on the planet. I don't understand it at all. And Josh, you have thoroughly put the whole process into something that I can understand. So if you're listening right now and you don't have the tech background, keep listening, this is so important. Joe Rando (03:14): So let's talk a little bit Josh, about what are the kind of the important things that so entrepreneurs would need specifically when they're thinking about creating their own app, whether it's a web app or a mobile app or both, uh, what, what do they need to think about what do they need to do to have a successful outcome? Josh Jordan (03:31): Yeah. So putting together a team of developers is obviously a big part of the process. I don't want people to jump right into that because there are a couple things that you'll miss if you do. One of the key bits, in my mind, is making sure that you are engaging with a team who can get excited and invested with the idea that you're bringing to them. I also want the entrepreneur to have a really good understanding of the high level technology pieces that are gonna play a big role in the business for years to come. You don't have to become a software engineer, but you do need to have a basic understanding, especially if those people aren't going to be a part of your company on a full-time permanent basis. You need to be able to find and vet the right people and make sure the process is going right for you. Josh Jordan (04:12): So before I get into describing how to build the right team, I want to talk about two steps that I want an entrepreneur to complete before they get there. One is writing a good product brief that succinctly describes the business idea and how technology fits into it. That way the folks on the other side of the table can really understand every part of the business, not just the technology, but the business as well. And without that, I find people kind of start rambling about the exciting parts of the idea and leave off the important technical bits that the technical folks are going to need in order to anchor it to reality. After that, I want to provide a little bit of education about the basics that you should know as you go into that conversation so tyou know, that the folks on the other side of are the real deal. Does that make sense? Joe Rando (04:58): Definitely, So what you're saying is Carly's gonna have to learn a little bit about technology if she wants to build an app Josh Jordan (05:04): Just a little bit, and I'll give you enough information that I think you can have that conversation. Josh Jordan (05:16): Let's start talking about the product brief. What I really like to tell entrepreneurs, when they come up with a great idea and they're super excited about it, and you should be, because you're the one who's gonna need to push this idea right from the idea stage all the way out to building a great business on top of it. First thing you need to do is get that product brief written. I see that as kind of a one to five page document. There are some key pieces that I'll take you through. The first one is tell us what the problem statement is. There are so many great ideas that I hear entrepreneurs come up with, but they haven't fully defined what problem they're trying to solve, as you go out to real users and you try to convince them to give you money for your product. Josh Jordan (05:57): We need to have a good idea of what problem we're trying to solve so we can stay focused on that throughout the process. Number two, give me a detailed solution to the problem. This is probably the piece you're really excited about. This is the piece that will flow most easily for you, but tell us exactly how you intend to solve that problem. Then this is where I start to ask for more detail. Sometimes people start to stumble, but they are really important things to think through. Give me one to three important use cases for your product. If you can get to the point of drawing a sketch on how somebody goes from having a problem that's causing them real pain, time, money, productivity, loss to having their problem solved and feeling that pain relief. That's perfect. That's what we want to see. Josh Jordan (06:43): Tell us who the user is. Why they feel that pain and what makes it go away for them in excruciating detail. Then I ask folks to tell us how the user experience should feel. In other words, what parts of your brand are gonna come through in your product? If it's a financial product, you're probably talking a lot about trust. If it's a task management application, we're probably talking a lot about organization and feeling like the software is doing things for you. If your problem is productivity loss, you probably want to do some reporting and tell the user how much time they've saved. You don't have to have all those questions answered in this step, but you need to be thinking about them and have some explanation for it. That's gonna help the other side of the table, the developers, stay focused on exactly what the user should feel, not just the exact problem they're trying to solve, but the experience all along the way to having your problem solved is actually really critical to building trust and engagement so the users come back. Josh Jordan (07:42): Then from user experience, we want to talk a little about what the visual design is, how should it look? This has some overlap with what I just talked about. Then we should talk about what the go to market strategy is. This is not a situation of if you build it, they will come. The fact is that the technology markets are so saturated with products that we can no longer put out a product and just expect that people will organically come to it. We need to develop a really good strategy around how we intend to get people on it. This might be going from a beta group of users to inviting all their friends and providing some incentive to that beta group and then running ads beyond that, to get people in the door. But we really do need to have a strategy down on paper, even if it's not the one that we're ultimately going to stick to. Let's start with some strategies because we're gonna think about it throughout the app. Josh Jordan (08:32): If the application needs to have invitation features so that one user can bring another one on, that's something that we should know in advance, cause the feature we're gonna have to build no matter what that mechanism is, it's going to impact the technology. Then finally, I want to see people talk about what the business model is. I want to know how this application is ultimately going to make money. Maybe the user is also the buyer. That's typically the case in consumer applications. That's a pretty straightforward process. Maybe the business model is just based on advertising. Maybe it's a little bit more complex and we're doing business to business sales and the buyer will be somebody different than the actual user. We need to plan for that in our sales process. All of these things come together to form what I call a product brief. This is one document that the other side of the table can digest. You'll see, it's really focused on the business and not just the technology because the business really does impact what we're building. Carly. Could you go write a product brief based on what I've told you at this point? Carly Ries (09:29): So far it is making a little bit of sense but, what kind of tech are you talking about? Josh Jordan (09:33): When we talk about technology, I'm talking really broadly about web applications, mobile applications, desktop applications. I'll get into talking about those in more detail at this next step where we kind of have our high level tech understanding that you're going to need in order to take your product brief to a team of developers and have a meaningful conversation about what they're going to build for you. So I have a checklist of things that I like people to have a passing knowledge about. I go into this really deeply in chapter two of the book., I'll talk about each of the things on that checklist right now. Like I said, don't be intimidated by it. You don't have to go get a computer science degree in order to have a meaningful conversation, but as an entrepreneur who has technology as a significant part of their business, these are things that are not just going to be important in this initial conversation, they're going to be important for the rest of your product's lifetime. So it does really help out for you to have some knowledge about the kind of conversations you're going to have with your developers on an ongoing basis. Some of this is really technical and gets into how your databases work. Like I said, it's not terribly deep, but let's have a conversation about it. Josh Jordan (10:46): The first item I'm going to talk about is the delivery mechanism for your application, whatever solution you have in mind. We need to talk about whether this is going to be a website that somebody types in their browser or a mobile app they download from one of the app stores, iOS app store or the Google play store or both. Or, is it going to be a desktop application that they download to use on their laptop or their desktop computer? We also talk at this step a little about responsive design, which is a strategy we can use on the web to make the application look really good. Even if somebody's using it on their mobile device. That's a great way to avoid having to spend all the money on building an additional mobile app if you aren't sure whether you want to be on web or mobile. Josh Jordan (11:29): Typically we tell people that it'll be cost effective for them to build a web application that is also available on mobile. Then you hit all the platforms I just described because every device has a web browser on it. Some applications, they'll be kind of thinking about mobile first. And when I say mobile first, that could mean we're designing for mobile as a website that's responsive, or it could be, we are truly building a mobile app as the first release of the product, or perhaps the only release of the product. If your application is really heavily dependent on the features that are only found on a mobile device, like a persistently ready camera or push notifications, then a mobile app is probably the right way for you to go. You don't have to have all the answers to which of these platforms is the best for you based on the features available. Josh Jordan (12:18): But you need to have an understanding of what they are because you're gonna be talking about them. The developer is going to be asking you questions about which is appropriate. So just having that understanding at this point, when we're talking about delivery mechanism, it's web, mobile or desktop. Beyond that, something we'll talk about is client side versus server side. In most of these applications, we're going to be talking about code that runs on the client, which is the device that your user owns. So my laptop computer, or my mobile phone, that's my client. This is important because client code is what makes the application feel really good when you have a great interaction on your device, where you tap on something and then fireworks, pop off. That's great. And that feels nice, but we can't run any secure code on the client because we don't trust the client. Josh Jordan (13:11): That's where somebody malicious could be changing the code or manipulating it. So all the secure stuff happens, server side, that's on a server that YOU as an entrepreneur own, or are paying a hosting provider for, if we're doing credit card processing, if we're updating user information or sending email, that all happens, server side. You don't have to go write the code that runs client or server side, but you're going to be having conversations with your development team about what operations in your application are secure. So client side versus server side is going to come up. You're going to want to talk about the system integrations that you see happening in your application. When I say system integrations, I'm talking about what other systems does your application interact with? If you're doing integration with HubSpot or Salesforce or with an email client, these are all places where you might bring data into your application or push data out to other systems. So when we talk about integrations, we just mean interactions between your system and something else. There are a lot of forms these can take. Just be aware of those integrations because very often we're building applications that do not just live on their own. They're much more interesting when they interact with something that's already a part of the user's everyday life. Joe Rando (14:26): Could this include something like a Stripe integration, where you are trying to collect credit cards to get paid? Josh Jordan (14:31): Yeah. Stripe is a great example. PCI compliance is a big deal for software applications. If we can, we can avoid a lot of cost in the build by never touching the credit card. If the credit card number never enters our system, we can avoid PCI compliance. So a tool like Stripe is a great integration because it allows us to do that. Anytime a credit card from the user's perspective is entered into the application, that actually goes right to Stripe's servers. We do that by building an integration. That's the conversation you would have with a development team about a specific integration you would need. And many applications are going to need to do that. There are a couple of different payment providers you can use that offer this feature. Stripe is the one that we've worked with most often, but that's a prime example of an integration because we don't want to take on all the complexity of storing credit card information in a way that complies with the payment card industry standards. Josh Jordan (15:24): I want to talk a little about data model and data access patterns. Again, you're not expected to design the data model or build the indexes that will enable great data access patterns. This is just about having a passing knowledge of what the developers are talking about when they get into this. When we talk about the data model we're talking about where is your data stored and what shape does it take? If you can imagine a database like a big spreadsheet with different columns, and you would say, everything in this column represents money and everything in this column is a name. We'll call that a string. We need to know what data types every single data field in the application is, and how that data is grouped up and related to one another. Josh Jordan (16:08): So actually your database is many spreadsheets and each table in a spreadsheet relates to other tables. We need to know what those relationships are. When we talk about data model, that's really all we're talking about. Imagine your database as a group of spreadsheets. When we talk about data access patterns, we're talking about how data is read and written in your application. For example, if you are building a forum, there are posts that are made in your forum. These posts are written relatively infrequently, but they're read all the time. Every other user is probably going to see every post many, many times. We would think about that as written infrequently and read frequently. There are other types of data like log data, compliance data, that would be probably written most often and read almost never, except when there's a particular type of audit happening. Josh Jordan (16:58): One thing we'll talk about is for each piece of data, for each spreadsheet that you can imagine in your application on the backend, what are the data access patterns? This is important to tell the developer so that they can design it according to the intended use. Remember the developer is going to be coming in without particular knowledge about the problem you're trying to solve other than what you told them in the product brief. So if compliance is important in your industry, and you're going to be writing some compliance log data, they need to know that and they need to know how that should work. That brings us to talking about databases themselves. You don't need to know which database to choose, but you should have a passing knowledge of the various options as the developer brings them to you so you can have a meaningful conversation about them. Josh Jordan (17:44): A lot of applications today still use what's called a sequel relational database. This kind of fits really nicely with the spreadsheet idea that I brought up a couple minutes ago and imagines each piece of data as a table that gets related to one another. There are other types of databases that are a little bit less structured. We call that a non relational or, no sequel database. Those are really great for rapid prototyping, moving quickly, especially in cases where we don't know how our data is going to evolve over time. And there are graph databases that store data in what we would call a graph, but basically looks like nodes and edges between the nodes so you can travel between those paths. If you think of something like Facebook or LinkedIn where there's a large social network, those are often visualized as graphs. Josh Jordan (18:31): When we want to know how many degrees of separation do I have between somebody else, that's traveling through nodes and figuring out what that distance is. Distance is a classic graph problem that could be solved really nicely by a graph database. It's not the only solution to the problem, but it's an important one. Just having some fluency in that as the developer talks to you about whether they want to use SQL or no SQL, spend a little time understanding why they are proposing the technology that they're proposing. One of the reasons I bring this up at this point is because often we see development teams that are fluent in a particular set of technologies. In my view, that's not really the right way to approach what technology stack do we use for your application. Josh Jordan (19:17): I'm a big fan of using the right tool for the job, which means figuring out which database and backend technology and client side technology are right for the particular needs of your application, not the ones the developer just happens to be fluent in. So if they can't articulate exactly why a particular database is the right solution for your use case, that's a red flag. The final bit that I want people to understand, is the difference between user experience and user interface. User experience is what does the user do overall? What do they feel as they do it? How do they experience your application? This is if I want to get my problem solved, which pages do I have to go through? Which things do I click on and how do the elements on the screen react when I interact with them. That's as compared to user interface, which really just refers to the visual aspects of the application. Josh Jordan (20:11): What does it look like? And what do I see? Those are important because the user experience is something that's going to permeate all the way through the application. You want to have consistent user experience patterns so the user gets used to interacting with your application and it trains them. For instance, when you release a new feature, they're probably gonna have some intuition about how that works already, because they have intuition about how your application works just by using it. Then the user interface bit is, let's talk about what pieces of flare are going to make this really stand out to the user and visually appeal to them and delight them as they use it. Carly Ries (20:46): Going through everything you just discussed, you said it's important to be conversational in all of it, but how do you go about finding somebody that is fluent in all of this and finding the right people to bring onto your project? Josh Jordan (20:58): It's a great question. I think there is no easy answer to it. I do really like to tell people they should start with their immediate network. There's almost definitely someone in your network that you can trust either personally or in terms of their technical skills, hopefully both that can help you. I want you to cling to that person. It might be you based on your past experiences, it might be a friend or family member, it might be a colleague. In any case, this person could be a future member of your team, but they most likely aren't. I want you to use this person to help you vet the team members that you're going to be talking to soon. Since we're talking specifically about solopreneurs, we don't need to get into how you bring out a technical co-founder or what software developers as permanent full-time folks look like as part of your team. Let's talk about outsourcing your development, which I assume is the path that most of our listeners are going to take. Your best bet on this front is to ask around your network for other folks that had good experiences with an agency or a consulting group. Josh Jordan (21:52): I'm a bit biased towards small focused agencies, because that's what I do. But there are larger agencies that do good work too. It's all about how willing they are to get their heads into your product and really become a part of your team once you engage them. Again, that's about making sure that they are seeing your product as unique and serving its specific needs rather than their specific process or previous experiences. I also like to tell people that when considering outsourcing, offshore versus onshore or nearshore, there's a quality gap that we see for better or for worse. I like to talk about this as programmers versus software engineers. When we talk about a programmer, we're talking about somebody who can be handed a set of requirements and can go implement them and there's plenty of need for that. But when we talk about software engineers, I'm talking about somebody who can really engage with the problem and think deeply about what the solution is because in your shoes, if you're listening to this and thinking about how you go forward to do it, you probably don't know how to solve your problem from a technical perspective. Josh Jordan (22:50): That's why typically I'm recommending that software engineers are the right way to go. If you had a technical, co-founder, a CTO who could manage the process and write very succinct requirements and review the code against those requirements, then perhaps programmers would be right for you and maybe you could save some money by doing some offshoring, but generally I want engineers who can think really deeply about the problem. So I'm generally recommending that onshore people that you can get on a call with kind of at any time and dive deep into, well, what if I changed the business in this way, how would that affect the technology? That's what I think will help most. I do like for people to find those agencies through their networks. That's basically how you're going to get folks that you trust. Josh Jordan (23:33): Once you find a few agencies that you want to talk to, you absolutely should have multiple options to compare between. You're going to call them up and grill them. Like your life depends on it. Your product's life really does depend on it. And I kind of wrote a guide to what your first call with them looks like and how you vet them, that I'd like to go through. The first thing that you're going to do is convey your idea to them. This is why you wrote a product brief. You don't have to stress about exactly what you should be telling them, because you can share this with them in advance. You may want to put an NDA in place before that. They should be used to that. NDA being a non-disclosure agreement. Carly Ries (24:10): If people are writing all of this down really quickly for this particular article that you're talking about, we will include this link in the show note. This is super valuable, and we will have that link to his "Guide To Agency Intro Calls". Josh Jordan (24:25): The second step is to let them describe their relevant experiences. You don't need to push them here. I'm hoping that when you have shared your product brief with an agency, their eyes are gonna light up and they will tell you they have the chops to go implement what you described and that they understand it well enough to relate it to the similarities of other products that they might have worked on. Then we should talk about constraints. Sometimes I liken the process of finding the right team to work with, to dating. I think there are some good analogies there, but this is finding out if you're compatible at all. We want to know if there's a specific launch date you need to hit. Maybe they don't have the availability to do it. Is there some kind of promotion that you want to do at a specific time, or if there is a specific market event? Josh Jordan (25:12): Does your business need to demonstrate certain metrics in order to keep the project funded? Are there certain internal quality standards that you need to hit ? Share these things with them and see how they react. You want to understand that they can meet the requirements of all those constraints. I usually tell people not to share their budget at this time. That's not how we operate, but you can imagine that there are less principled firms out there that will fit their estimate up to your budget. So if you tell them that you have 50 grand to build a product, they might say, well how coincidental, it looks like we estimated this at about 48 grand. That's not what we want to see. Let them give you an estimate based on what you described. Then we want to ask them about what their process is. Josh Jordan (25:54): Some of the key things to look for in their development process. 1) plenty of opportunity for you to see some work in progress and to give early product feedback. I could talk at length, we could do a whole podcast about agile software development and why early feedback is important. The bottom line is early feedback reduces the cost of fixes and changes. Fundamentally believe that there will be changes as you start to use your own product and understand how to interact with it. At Supervillain, we do this by deploying code multiple times per week in an environment where you, as the product owner, can go use the real thing, even if it's not complete, that's okay. It allows us to capture feedback and say, wait a minute, this doesn't feel right, or this is great, let's continue down this path. 2) listen for quality checks without you prompting them too heavily. They should be able to tell you how they keep their software quality very high. We do this by writing a lot of automated tests, so at any point in time, we can press a button and verify that everything we've written to date works just the way we intended it to work. Joe Rando (26:55): Can I jump in and say, this is an easy one to skip. A lot of people skip it. I've been there and it can be very costly because you can find out that a change you've made to your software has broken something you don't know about and very bad things can come out of it. I can tell some horror stories, but I won't. This idea of these automated tests to keep quality high, it doesn't really do anything, it doesn't make the app feel better at the time, but I just want to drive home how important it is to getting a good result and good maintainable code over the life of the product. Josh Jordan (27:34): It's true. And it can be particularly daunting at the beginning of the process because it does add a non-trivial amount to the cost because your developers are going to spend a fair bit of time implementing these tests. But I want you to imagine the cost down the line. If every time you deployed a new version of your product, which might be as often as multiple times per week, you had to go retest every single feature of the application. And that's not just a matter of clicking around the application, which itself is quite time intensive as the application grows. But imagine in your integrations where if you've integrated Stripe or some email system where you need to go test every case, which means signing up from scratch with a brand new credit card and verifying that the application still charges that credit card at the right times. In reality, you are not going to do that. Josh Jordan (28:20): You're not going to be able to test all those things every single time you deploy code. It'll be very expensive because you'll leave gaps for yourself. Then you will inadvertently have broken things. The nature of software is that it's very complex. Sometimes it's difficult to tell that one benign change you're making has some downstream effects that will impact some other feature. That's unfortunately just the nature of the game. So we do recommend building automated tests because although they're relatively expensive to build upfront relative to the features that you're building, it's not as large as the feature work, but it's still a significant portion of the time that your developers will spend but it will save you so much time down the line . Not to mention the pain of having to do emergency bug fixes once your users are the ones testing the application for you, if you don't have these automated tests. Another thing to ask is who manages the servers that your application will live on? Josh Jordan (29:12): Is that them, or what do they need from you in order to make it happen? There are a lot of different models here in terms of who hosts the application, who pays for it. I don't think the answers to those questions are things that we can exactly anticipate. Every agency is going to approach this differently, but you should know what that is upfront. The next thing you want to talk about is, what is their financial model? Are they going to get paid hourly or at certain milestones, or do they want to make a portion of your future revenue? You need to assess the risk, both yours and theirs and what the future impact to your business is, especially if you're planning to share profits or revenues with them. Most are going to want to work hourly or in milestone payments because they don't want to take on that risk. Josh Jordan (29:54): Do they have any minimum commitments? Are they looking for a monthly retainer? What happens if you decide you don't like their work and want to cut ties? I think this is specific to every single engagement and you need to decide what's right for you, but you should have a very serious conversation about it. That brings us to talking about what it's going to cost. I can't emphasize this enough. They should be able to put a reasonable projection together. This might take them a few days, but you should be able to see in their projection that they understand your business at a fairly deep level and they have customized their proposal to the specifics of your project. If it smells generic, you can expect that they're planning to throw your project together according to generic patterns that are specific to them not you. Run away from that. Joe Rando (30:35): A question Josh. On the construction side of real estate, there's something called change orders. You give them blueprints and they start building the building and you go, wait a minute, we need to change this. The next thing you get an additional bill or you sign an agreement, a change order. Is that common in software? Josh Jordan (30:52): It is common in software. Especially because we embrace change with Apple's agile software development. It's important. You should expect that there will be changes. Like I said, once you start to use your own product, I think you're going to think differently about what the experience should be. So instead of building in specific requirements that go right into your contract and you should be talking about specific requirements, but instead of putting them in your contract, especially if the folks you're working with are going to be working hourly, you should have a conversation about what that change process looks like. There's no reason why even once you engage in the process, the developers can't continue to provide you estimates. If you say, well, what if I wanted to insert another page between pages one and two in a specific process? What will that cost me? Josh Jordan (31:36): You should be able to have an ongoing conversation about how much effort each thing you take on is. And especially if you are constantly reprioritizing as you start to get customer feedback. As you get close to your launch or post-launch, that should be a pretty regular conversation. The last bit is to find out if they want to stay with you long term. I always tell our perspective clients that our goal is to develop a long term relationship. Even if that meant we weren't building a whole lot together in the first pass. Sometimes I'll tell people that the first pass at their business can be built in a spreadsheet, and that might be the right way to go. That doesn't make us a whole lot of money in the first iteration, but selfishly, we do best with our clients when we do have a long term relationship. But for you, it's an indication that your development team wants to stand by their work. Josh Jordan (32:20): They're able to stand by the quality. We show off quality to our clients just by working with them. If it starts to feel like the developers want to cut and run after the first iteration, move on. You can expect they're not building with quality if they don't want to support it after it's launched. That's unfortunately a typical model for offshore firms. Unfortunately, we've been part of a lot of rescue projects where an offshore firm built something that could not be maintained or scaled and entrepreneurs come to us in a panic to fix this. So suss that out early on in the process, look for folks who are going to stand by their work, by committing to staying with you in the long term, until you are ready to ramp onto either full-time developers or you've gotten the product into a state where you don't need constant changes, bug fixes and feature improvements. Carly Ries (33:06): Well Josh, just to piggyback off of that, a benefit of the long term relationship too, is the education component. It has been so helpful working with you over the past year plus because now I feel like I'm more in know with everything that's going on and again, speak conversationally to all of it because of that long term relationship that you don't get with the short term. Josh Jordan (33:26): Yeah, absolutely. Joe Rando (33:27): That brings us to one of the common mistakes you see people make, most specifically with one person companies. I guess we'd have to call these solopreneurs as opposed to freelancers, but they're trying create a business and it's just them. They're trying to do all of this software development with an outside contractor. What are the mistakes that these people tend to make? Josh Jordan (33:49): Yeah, I think the first really big one that I see often is it's really the process of planning rather than the plan itself. That is going to be most useful throughout the process of software development. I think it was Eisenhower that said plans are useless, but planning is indispensable. I don't want people to expect that the vision in their head is exactly what they're going to end up building. Fundamentally, I think once you get to use your own software and really touch and feel it, you'll come to understand your own idea at a much deeper level than you ever could have in the planning phase. It's going to mean making changes to the original vision. That's okay, that's a good outcome. So we build our process, our agile software development process to embrace change. It means throughout the initial product development phase, it means again, when we have our first beta customers, it means on an ongoing basis. Josh Jordan (34:37): When we develop a regular feedback mechanism with our everyday users for the rest of the product's life, this is why we do agile software development. Our agile development practices let us react quickly and inexpensively and ultimately build a better product that's more in tune with what the user wants. I also see people who build too big in their first iteration. We don't need to build for every use case, for every possible user persona in the first version. Let's get something meaningful into the market first and assuming your business model permits it, then we can change directions drastically if we get feedback from your users that ultimately is gonna make the product better. I don't want you to spend too much money before you get that feedback. It makes the product more complex if we build features that really don't resonate with the users. So let's prove that the product is necessary in the market by getting it to a user, getting them to agree that the product is worth real money or change the product until it is. Then let's have a conversation about how we tackle the next big, hairy problem. I think there's a tricky balance in building for scale for Solopreneurs, especially. There is a famous quote from Paul Graham about doing things that don't scale first. So you can learn how to do them once you do scale. Frankly, I can't really teach a computer to do something if you can't tell me first how it's done by hand with a couple of notable exceptions. I believe in that a lot. It saves money and it gets the processes right. Often this means inserting yourself as a ghost in the machine so for example, when a user submits a piece of data, maybe we tell them, okay, come back in a few hours once we process this. Josh Jordan (36:12): And it's really you doing the work to do that processing in the first version of the product, perhaps. But as a solopreneur, you are not going to have the luxury of releasing a feature that creates a huge operational burden for you. So if your feature takes off, you need to know how the software is going to address that. Plan for a realistic level of scale in every feature you build. There is no easy answer here. It's specific to every single feature. The last one that I see frankly, is having unrealistic expectations about how long it takes to build the product. Often something that sounds simple, sounds like it can be built quickly, but even small variations on it could introduce a lot of complexity from a development perspective. Work really closely with your development team to find costly requirements and find alternative ways to satisfy them. Josh Jordan (36:58): It requires some trust with your team, but it can save you weeks and weeks of development time. Make sure to allocate time for the odds and ends that are boiler plate for every product. Think about user authentication, logging into your application, think about security concerns, user settings, or options that you're going to want the user to have to set. It could be as simple as light and dark mode in a mobile app, or it could be how often do you want notifications. Users are gonna expect that. Expect to have to build something to handle spam, opt out links that go in your emails, notifications, customer support. These are all things that require development time, even though they're not a core part of your idea. Even if your idea is as simple as having a black box that takes in something from the user and satisfies a problem for them by spitting out some answer, you're still goiing to need to think about how these other aspects fit into your product. It's just part of productizing your idea. Joe Rando (37:52): Makes a lot of sense. My next question is if you had one thing that you want a person who is flying solo in business to take away today, what would that be? Josh Jordan (38:02): We should talk about how we turn use cases that are in your head into user stories. We have a language that we like to speak, in terms of user stories at my company and so every time we have a feature, we like to phrase it as a specific sentence with three fill in the blanks. This helps the development team think really deeply about what we're implementing and why. I think I've put a lot of emphasis on the why, and that's because I really do believe that we'll build a better product if the developer can think about why they're building. There are many very nitty gritty details to solve. I was talking a minute ago about productizing the idea, the developers should be able to think about who they're building it for. Josh Jordan (38:45): If there are decisions to make, is the user going to experience two pages or 10 in order to complete this process? We should know what the user's goal is. We have a template we use that says as a blank, and in that blank, we put a predefined user persona type. This might be a two-sided marketplace. This might be as an expert or as a buyer. whatever those personas are for your specific application. As a blank, I want to blank. This is a clear statement about what action they're trying to perform in the system, then we follow it with, so I can blank. And that's the why. That's the mission or the fulfillment of the problem. Joe, we did this many times on LifeStarr. Do you want to give an example of one that we wrote for LifeStarr? Joe Rando (39:36): Sure. As a user, I want to be able to set the start date for a task into the future so I can be reminded to start doing that task when it's appropriate. Josh Jordan (39:48): That's a great example. It tells us not only that we need to have a field for the user to fill out that start date, but now we know why it's important to the user. I might ask Joe as a response to that, "do we also need a notification so that the user can understand on that date and be drawn back into that task? "And if I said that, what would you say? Joe Rando (40:08): I would say absolutely. And that's the point. That process of explaining it that way, draws out a lot of implications, which is what you were saying earlier. It's really a powerful way. I've developed a lot of software over the years and it's definitely been the best way to get started. At least at some point it doesn't become as important because you've established the patterns, but early on, it's really magical. Josh Jordan (40:33): Exactly. So I've given a lot of caveats. I hope I'm not making people think twice about whether software is the right direction for them to go. I don't want you to second guess that. My hope is that you can save a lot of time and money based on what I've told you. But I do want to be really clear. I think building software is how even a single person like the listeners to the podcast can create incredible scale in their business. I've seen clients who had good, solid manual businesses. They were working hard at every single day, then invested in putting their process on the web or into an app and they're now seeing massive scale by selling their process via software. There are lots of years of work that went behind that to get their process right and the time and capital they put into building their software, but the reward can be really significant. It's a powerful approach to doing business. Joe Rando (41:22): Besides your book, which I'd love to talk about at the end here, do you have any resources you think would be helpful for a person going it alone? Josh Jordan (41:31): There are a couple that I'd really like to point at. There's a site called UI patterns, ui-patterns.com. It's a great site you can use to kind of cobble together sketches of common user interfaces and user experience patterns to mock out and test your idea on paper. Go ahead and draw those out on paper or print them out and, and cut them into pieces and look at it all end to end and get an idea of whether it makes any sense to you before you share it with anybody else. The creator of duckduckgo, a wonderful search engine, his name is Gabriel Weinberg. He wrote a book called Traction that I love about growing your user base. First, I really recommend that everybody read Eric Ries' Lean Startup or Michael Gerber's, The E Myth Revisited. These books are not exactly specific to technology, but they teach you how to build scalable processes that can be implemented by technology rather than being an operator of your business. In other words, the one implementing that manual process. It shows you how to make that leap. Carly Ries (42:25): I'm going to second that one . That is such a good book to read for anybody looking to get into entrepreneurship, Solopreneurship, what have you. Joe Rando (42:33): Talking about The E Myth Revisited? Carly Ries (42:34): The E Myth Revisited. It's fascinating. It totally changes the way you think about it. Josh Jordan (42:40): It taught me a ton of lessons about my own businesses. I did it and I can see how it applies to every single product I've worked on. Carly Ries (42:46): So Josh for solopreneurs, do you think a good community is important for people to have? Josh Jordan (42:51): Yeah, I really think that's the best resource you can have. It'll keep you grounded, keep you on the right track. If you're lucky to hook up with the right people, they can even help to keep you accountable. You need to figure out what the right group of people for you to work with is Joe Rando (43:04): So, this is a standard question that we have for everybody on this show. And that is what is your favorite quote about success? Josh Jordan (43:12): I love Reid Hoffman's quote that "if you aren't embarrassed by the first version of your product, you've launched too late". It's not exactly about success, but I think launching is a key step. It's a success in itself because some folks won't ever even get that far. Reid sums up a lot of what I talked about here, in terms of not wasting your money, gold plating your product. Get it out there, get feedback, and respond to that feedback. Your product is never going to be perfect or done. That's not the nature of business and certainly not the nature of software development. So don't chase perfection as a goal. Chase success with your product. Joe Rando (43:45): That's perfect. Can you talk a little bit about how people might get ahold of you if they wanted to get information about your book or what you do for your company and that kind of thing. Josh Jordan (43:55): Sure. You can get me on our website at supervillains.io or you can just shoot me an email, Josh@supervillains.io. I love talking about how we can improve the world with technology and I'm happy to talk. If I can point somebody in the right direction, that's a big win for me, please reach out. And you're right. We're launching the book in a few months. We're in the final phases of editing right now. It's called Starting Your Startup. It outlines seven steps to launching an app on the web or on mobile. It starts by going in depth on the things we talked about today and continues on through how a solopreneur should prepare and involve themselves for the rest of the software lifecycle. Meaning the design process, the development process, internal testing and feedback cycles preparing for your launch. The chaos of a launch day and where you go after your initial release. If you're interested at all in that, we're going to be taking early signups and happy to give a One-Person Business podcast listeners a discount when released. So Carly, I think you're gonna put a link in the notes. Carly Ries (44:52): Yes, there will be a landing page where you can sign up to get on the waiting list and that link will be in the show notes. Be sure to check that out. Josh Jordan (44:59): Wonderful. Joe Rando (45:00): Well, Josh, thanks so much. This was really great. I've been doing this a long time and I learned something today. Getting something into my brain is an impressive accomplishment. Josh Jordan (45:11): My pleasure. Thank you for having me. Carly Ries (45:13): My brain exploded, but in a good way. thank you so much. We really appreciate it. Joe Rando (45:20): Thank you, Josh and thank you everyone for joining and listening. Obviously, please sign up for this podcast. Subscribe and there will be a lot more great stuff like this coming your way. Look forward to next time. Take care. Carly Ries (45:33): You may be going solo in business, but that doesn't mean you're alone. In fact, millions of people are in your shoes, running a One-Person Business and figuring it out as they go. Why not connect with them and learn from each other's successes and failures. At LifeStarr we're creating a One-Person Business community where you can go to meet and get advice from other solopreneurs. Be sure to join in on the conversation at community.lifestarr.com