When we first picture our new product, it’s wonderful, looks beautiful, and works perfectly every time. We imagine how people will use it and how successful we’ll be. We dream of how quickly and smoothly everything is going to go. In short, it’s fantastic.
Then we sit down to figure out how to create our product and life gets more complicated. We start to consider the what, how, and who of our product and we start to grasp the massive complexity in front of us. While we want to build the entire product immediately, we’ll need to prioritize for our timeline and budget.
Prioritizing for Version One
We have to be honest with ourselves and realize that what we thought was a clear, coherent Vision is really a hodgepodge of requirements, ideas, dreams, and vague notions.
This also happens to be the riskiest time of any project. Without the constraints of an existing product, architecture, or existing customers, it’s hard to separate the good ideas from the distractions and dead ends. If we’re using new technology or a team that hasn’t worked closely together, it will be worse. If we’re working under a tight deadline – common if we mis-scoped things originally – it will be even worse.
While I won’t go into prioritization strategies here, my mindset always starts with understanding the user’s pain and solving the most valuable or painful tasks use cases first. If you can demonstrate saving a user real time, money, or pain quickly, you’re on the right track.
Version One: Vision vs Reality
As we make progress on our product, our Version One will look less and less like what we originally envisioned. Our product will have many critical capabilities but not all of the important ones. We’ll have discovered things that invalidated our starting ideas. We’ll have to make tradeoffs that made our product less effective. It will have flaws or bugs that make it unreliable outside a specific set of use cases. It will not be as stable or scalable as we hoped.
And the worst part – every time we look at our product, those flaws and issues will haunt us. Every time there’s a new bug, we’ll get irritated and frustrated and wish we had more time for testing. While it hurts and drives us crazy, the good news is that if our product solves a big enough problem, most of those issues won’t matter. We just have to be up front laying out expectations and boundaries so we don’t surprise our customers.
Version N+1 will Be Better
The best news is that later versions – shaped by actual usage & customer feedback – will be even better than we initially imagined. Because it turns out that our original Vision for the product was wrong in both subtle and obvious ways. Real life usage and feedback will end up giving us something better and more powerful, even if it takes longer than we expected.
Building a new product is ridiculously hard. We have to blend our instincts, our understanding, and feedback from potential users & customers, filter it all through our biases and experience, express it to our team, then figure out how to build it, and finally figure out how to sell it back to those potential customers.
When you stop and think about all the variables, complexity, and challenges in there, it’s amazing that we get anything shipped at all.. but I’ve already covered that in “My Startup is Broken.”
Caveat: None of this applies for mission critical systems, medical devices, or when lives are on the line. Then your Version One better not suck and any deficiencies MUST be disclosed up front.