Why Creating New Products is So Hard?
Let's face it, even firms with stellar sales and R&D departments still struggle to sell innovations.
There are thousands different factors that contribute to the success of a product, but the biggest reason for failure is building products based on wrong assumptions.
That includes failure to understand the market, what customers need and want, or fixing a non-existent problem.
And while there is a common consensus among product and startup professionals about the critical importance of testing and validating ideas before implementation — still, quite many organizations settle for full-blown product development from day one.
The reason behind this?
“Most projects are budgeted and structured for Delivery and not Discovery.”
It is quite typical for an "MVP" to take more than half a year in development, without a single customer touching it.
This is way too slow and way too expensive.
But that's not the biggest problem.
Long-running projects that don't have the feedback cycle with the customers are facing exact same problems:
more "mass", more inertia, less focus and less momentum, and in general start following Parkinson's law.
The bigger is the size of the infrastructure and code, the more time and resources it takes to maintain it, and the harder it becomes to make changes.
Most importantly, the more time is spent building features based on not validated assumptions - the bigger is the risk of making the product that nobody needs and wants.
Not to mention the opportunity cost.
“The biggest waste is to design, build, test and deploy a feature or product only to find out that it was not what was needed.”
So how to avoid risks?
Learn real facts that can be used to make right decisions. Test the biggest number of ideas in the shortest time possible.
It is possible to find real facts even starting with 100% wrong assumptions.
Convert assumption into facts. Fail fast, learn quick.
What is the fastest way to test product ideas for real?
How can we build an MVP during the time it takes to create a prototype?
How about many iterations per week, instead of one iteration every few weeks? What if we work together with the customer to shorten the feedback cycle to days and not months?
Can we cut all the overheads of a typical development process, avoid all the "busywork" that doesn't move the needle in terms of product validation? What if skip all the intermediate design artifacts and documentation that becomes irrelevant after each iteration?
What if we eliminate the meta-work, emails, slack and issue trackers, and instead iterate on the product collaboratively in real-time?
