Building software is hard. You have all the fun of being excruciatingly specific in certain situations, incredibly general the rest of the time, and expressing all of it in a language that isn’t your own.
In the context of a new product – whether it’s for a startup or an established company – it’s even worse. In the best of times, Version 1 is challenging and in the worst of times, it’s catastrophic. There are a ton of reasons why but let’s talk about Version 2 first.
Version 2 is Special
The second version of your software survived first contact with your customers. You’ve learned and they’ve learned and it solves more problems than Version 1. Most likely the user interfaces are clearer, the code is more reliable, and your Support team spends less time helping each individual customer.
Yes, there are still bugs and rough edges but your team has a feel for where they are and the consequences, so they’re getting to them. In fact, as they extend or improve the system, you’re steadily making the system more stable, faster, more efficient, and generally making your own lives better. When you come up with a new concept, you probably have a rough feel for how much time and effort it might take.
Most importantly, you have customers!
There are people who find your work valuable and give you money to demonstrate it. That’s special and powerful. In some cases, they don’t just like your product but need it do do their own job.
Why is building Version 1 dangerous?
Put in that context, it should make more sense.
Version 1 hasn’t spent much time in front of customers. In fact, you’re not 100% sure it solves a big enough problem for them. And even if it does, you’re figuring out the best approach and they’re trying to figure out how to use it. Regardless, no matter how hard you work, your Support team (aka you in the early days) will have to diagnose those “oddball” problems that turn out to be common. But even these points are after you’ve shipped something. What does it take to ship?
Before you ship, you have some rough features or use cases, your favorite framework, and a free hand to do whatever you want. You have the unique opportunity to define the structure, flow, and operation of the software from the ground up. And when you get it wrong – because we all do – you’ll suffer through updating everything and converting customers to Version 2.
And worse of all, you don’t have customers. You have to trust that you’re building the right thing in the right way to appeal to an audience you believe exists and you hope will pay.
At Version 1, the decisions are the hardest, the risk is the highest, and it’s almost all downside.
Can I skip to building Version 2?
Unfortunately, there is no silver bullet that lets you skip these steps directly into a wonderful product. You will struggle, you will make mistakes, you might be successful, and you will need a good stiff drink occasionally.
That said, there are some strategies to improve your odds. None of them are perfect and none of them are foolproof, but choosing and applying the right ones for your situation will make a world of difference.
- First, have a clear Vision of what you are and aren’t building. Draw clear boundaries for where your app begins and ends to make sure you know what problems you are/aren’t solving. Check out “So you want to build an App..“ for more details on that one.
- Next, eliminate the telephone game The people building the software should speak to the prospects regularly without middlemen to muddle, confuse, or drop details. We don’t know what information is/isn’t important, so we can’t drop anything!
- Next, shorten the feedback loop. Don’t wait months to ship. Get something – even mockups – in front of them as quickly as possible. The faster you can get a yes/no, the less time you’ll waste.
- Don’t outsource. If the people learning about your customers and building your product walk out the door after, everyone has to re-learn everything for Version 2 because that’s a great use of time.
- Spend at least half your time selling. If there are problems, nothing highlights them faster than prospects trying to use your product. If things are Good Enough, there is nothing better than getting paid. Cashflow solves a lot of problems.
Finally, you get 1 new thing: team, technology stack, or industry.
When people work together, they learn who is good at what, who is reliable how, and where each others’ expertise begins and ends. When your team has a deep understanding of the tools, frameworks, and technologies, they make better decisions every step of the way. As a result, their demeanor, work, and results are radically better. Finally, when you work in your industry, you know the jargon, the people, and the tools to get things done.
A new product can survive missing any one of those things:
- An established team using their ideal tools can learn enough about most industries to build something useful.
- An established team with deep industry experience can learn enough of a new framework to build something useful.
- A bunch of strangers who know the industry and know the tools can segment the tasks to build something useful.
Some new products might even survive missing two of the three but very few products can survive missing all three:
A bunch of strangers without experience with their tools or the industry is doomed to failure.
Every choice adds a little more risk
It’s a place to make a mistake. It’s an opportunity to miscommunicate. It’s a chance for assumptions to override data. It’s another place to go over budget and miss deadlines.
The only way to figure out Version 1 and survive to Version 2 is to reduce risk.