By Eugene Yamnitsky
Product Management & Innovation
Over the past 5 months I’ve been talking to many people interested in innovation, and fairly consistently people assume that innovation is only for engineers. This is a myth worth busting. Like it is with many things in life, the real answer is in finding the right balance. Seasoned Entrepreneurs unanimously advocate balance in the form of the “3H” founding team: Hacker (the coder) / Hipster (the designer) / Hustler (the go-getter).
Remember the dot-com bubble? There were many factors which led to its burst, but one in particular worth mentioning is how often companies ignored the desirability of their products. A major problem was that founders followed the “if we build it, they will come” mentality, and were surprised when “they” didn’t come. Many of these founders ignored the desirability aspect of their cool ideas, and instead went straight to coding.
Don’t get me wrong, having a working prototype you could give to the user to get feedback is invaluable, but unless you are a good software engineer who can produce the proof of concept fast, and make changes often to adapt to the feedback, that path has a high barrier to entry – it is simply too difficult and risky to follow.
Thankfully, the Lean Startup framework outlined by authors Steve Blank and Eric Ries holds the key to innovation, and does not require coding in the early stages when your most important task is to find the product-market fit. This framework has several practices and tools. These include Customer Development, Design Thinking, Value Proposition Design, and Business Model Canvas.
Regardless of whether the founding team is versed in coding, following these practices will help increase the likelihood of your venture’s success. Here is how it works at a high level. Note that these steps are not sequential; it is recommended to do a little of everything and iterate, iterate, iterate.
Define the Customer/Problem/Solution trio
Too many startups attempt to solve multiple problems for a very large market. This leads to a lack of focus, and precious resources being spread too thin. Instead, try to define one customer segment which is most likely to benefit from your solution, define what the biggest problem you are solving for that segment is, and define a solution to that problem.
Define your hypotheses and validate them
Now that the above trio is defined, you need to make sure your assumptions about the problem are right. Ask yourself: does the problem really exist and is it worth solving? In order to validate your assumptions, you’ll need to form several hypotheses then build a questionnaire that you will use to learn about your customer and validate the hypotheses. Then it’s time to reach out to your friends, family, and colleagues to find people matching your customer profile and interview them. After 10+ interviews assess what you have learned. Are your assumptions being validated? Did you learn about a different problem worth solving instead? Refine your assumptions, update your questionnaire and continue the interviews.
Define the business model and validate it
If after several iterations and going back and forth between the previous steps you begin to feel like you are onto something, then it’s time to define things like the business model, your unique value proposition, what unfair advantage your solution could leverage, and what partnerships, revenue streams, etc. might be possible.
Build a Minimum Viable Product (MVP)
When you are getting even closer to making a decision on whether to build the product it’s time to show your customers what the solution may look like in the upcoming interviews. The MVP may take many forms. Perhaps it is a simple click-through prototype made in a tool like InVision. According to Eric Ries, an MVP is not merely a minimum set of features acceptable to the customer, an MVP is a minimum set of features that helps validate your hypotheses, and as such, does not have to be a real product. In fact, even your questionnaire is an MVP of sorts.
Now you’re ready to code
After you have validated that you are solving a pressing problem, and the feedback on your prototype is positive, you can go ahead and start coding the first version of your app. If you skip these steps and go directly to coding, there is a risk that you will be building something that no one wants, like so many did in the dot-com bubble days. Unfortunately this mistake is being repeated by startups these days as well.
We can all innovate
Now you can see that coming from non-engineering disciplines like Sales, Care, Services, Product Management, and Marketing has unique advantages, as founders from these disciplines have skills which are key to finding the product-market fit, and contribute to a successful innovation journey.
You can come from any discipline and become a successful innovator, and the time to get started is NOW!
Eugene is an innovation catalyst and product development leader with over 15 years of experience getting things done in conditions of uncertainty and fast paced change. He has a proven track record of success in early and late stage startups and large companies.