Skip to main content
search

© 2021 Excellerate. All Rights Reserved

Lean Start Up

The Lean and Mean Startup

By November 28, 2013No Comments

Main concept in “The Lean Startup” is learning from failure by engaging iteratively in validating hypotheses that lead to the next logical step. Its better to get early validation of “leap of faith” assumptions forming the basis of your business plan. Do we have to fail ourselves to learn? Can we not learn from other’s failure? There are so many failures around. Most startups fail. Can we not learn from their failure?

Proxy Prototypes
In this blog I want to share my thoughts on how the idea of “The Lean Startup” can be tweaked a little to make it easier, faster and cheaper to execute. “The Lean and Mean Startup” follows almost all the main concepts from “The Lean Startup” but for the grunt work involved in product validation. The “Mean” approach is different in the fact that it advises startups to use –

  • Competitive products.
  • Similar Products that are targeted towards some other market.
  • Similar Products that are made with some other use in mind.

We call such products “Proxy Prototypes”. These “Proxy Prototypes” can be used by startups before building their own prototypes or landing pages to validate a product concept that solves a known problem.
Selling a “Proxy Prototype” to your target audience is one way of doing market validation. You can validate the product by using the “Proxy Prototype” yourself to solve your target problem.
Solving Known Problems
This approach works well for startups who have ideas that are not the next iPhone or iPod . These are like most startup ideas – solving known problems and not launching ground-breaking innovations that solve unknown problems.
Solving Problems
Search – Use – Learn
If you just look around and search you will find products that attempt to solve the same problem you are. If such “”Proxy Prototypes” are carefully evaluated by putting them in hands of target users, you will develop valuable insights.
If there’s a feature that the users like – add it to your product. If there’s something that users hate – learn from it.
If your market doesn’t have a product that can work as a “Proxy” ; look elsewhere – you might find one in a geographically distant market. This is particularly true of products like the “mobile shopping assistant” that address localized markets. Entrepreneurs in emerging economies are most likely to find their “brilliant idea” already in use somewhere in the west – most likely in the Silicon Valley.
Interview the current users of the “Proxy Prototype” to find out how you can do better. If you find some segment of the users deserving better attention explore further. Can I carve out a niche and extend the “Proxy Prototype”?
If the company owning the “Proxy Prototype” is burning cash trying to “Cross the Chasm” , find out why their customers are not ready to pay enough. May be the problem the product solves is not big enough. User research might reveal a more overwhelming problem. Start looking for another “Proxy Prototype” that solves that problem. Continue these “Search-Use-Learn” iterations till you find a problem that is big and yet its not properly addressed by these “Proxy Prototypes”.
How easy or difficult was it for you to find the “Proxy Prototype” for your target problem? Are users actively looking for solutions? You might discover many “Solutions” waiting to be found. Ask yourself a question- if users are not pro-actively finding those; why would they find the one that you are planning to build? Most of them passively live with the problem. There might be a big communication gap between available solutions and target customers. Try selling a “Proxy Prototype” to such a passive user to understand her objections; you will definitely learn why people prefer to live with a problem than with “So Called Solutions”.
Conclusion
Does this mean that there is no need to build a prototype? How would we validate a product by showing some other product? The idea is to save time and money by reducing the number of iterations to get to the “Compelling Solution” that has the best chance to address a “Really Big Pain Point”.  Finally you will have to start building your own prototype – but you would be much wiser by the time you get down to do it.