Iterative execution: The path to steady product dev
When working on a project, the approach to executing the idea and solving the problem can vary a lot, based on whether you have launched or not. Having worked on 7 projects, some launched, others not, I believe to be in a good spot to write about this.
The road from idea to billions of users (and revenue) is akin to the shortest path problem. You cannot wait at the start point to simulate (think) the entire journey in your head and make perfect decisions. Remember Doctor Strange visualizing 14 million possibilities to figure out the one right path? Yeah, we can’t do that. Like the shortest path problem, you need to take the best next step and not overthink steps B to Z.
But what is step A to B? And what factors determine which direction to lean to?
The answer is to turn the startup into science, and product dev into a research problem. Make a hypothesis you’d like to test. Questions whose answers could make or break your business. Set out to test these out.
When starting Ondigo, I set out to test 2 things: Would people buy from a vending machine or a robotic kiosk? And, would it make more sales than a local vendor?
To test these out, I didn’t need a fancy app or 2 years of product iteration to get hardware to perfection before bringing it in front of users. I just had to take the simplest subset of my vision and test it out in the real world. The results were promising. In 4 hours of daily operation for 53 days, we sold 3X food local vendors sold in the area in 14 hours of daily operation.
Having validated those 2 questions, I am currently evaluating the next set of questions: Will serving the food at the right temperature increase retention and word of mouth? And, would the right location help us sell 10X? Again, I’m only doing the bare minimum product dev required to answer these questions. Nothing else matters.
Those who have a background in computer science would find it similar to the shortest path problem. It is impossible to solve it in the most efficient manner, but taking the best next step is your best bet, especially since you’re low on resources.
In essence, to prioritize specs and tasks for the current product dev cycle, ask your team this question:
What’s the question of who’s answer could make or break your company?
And keep improving. This is what MVP means.