By far, the top reason startups fail is the lack of market need (42% of the cases). Many startups are founded based on unique technologies, or on problems that are interesting to solve, but don’t necessarily answer a real market need. Understanding what market you are serving, and the problem you are addressing is key. The basis for that is early, continuous feedback from the right people who fit the early adopter profile.
Collecting customer feedback when you already have customers is a struggle on its own; however, getting the first critical and actionable feedback needed to shape an MVP is significantly more complex. It is the classic chicken and egg problem — early adopters will give feedback, but they will come when you have built something. That something needs feedback in order to be built.
In this post I am going to tackle a few questions critical to succeed in getting meaningful product feedback:
The easiest symptom to recognize is no feedback- you still haven’t successfully engaged with customers to get feedback
Too frequently, companies only realize they have this problem when it is very late in the game- they have invested a lot of engineering work into a product that no one wants to buy.
Recently, I worked with a startup that had just launched its product. Engineering had an endless list of features that were all urgent and had to be implemented in order to close specific deals.
However, every time one of these features was released, this didn’t result in a sale, and they kept getting surprised. While these prospects liked the idea behind the product, it didn’t actually address a real problem for them. This resulted in tactical, usability features that the prospect asked for (for example role-based access control), but did not magically transform the product into one that actually answered the prospect’s (or any other company’s) business need.
Luckily, there is a common cause of all of these problems and a treatment for it.
The common problem underlying all of these symptoms is that you are NOT talking to your “early adopters”- a small group of early, visionary customers, who represent your initial target market, and will guide your learnings and product features until you find a profitable business model. This concept is explained at length by Steve Blank- I highly recommend reading his books.
The remainder of this post will include practical examples and tips that could help with this challenge.
Naturally, you would think this problem is reserved only for very early-stage startups. I will address these shortly, but I’d like to start with an example to illustrate why this applies to large companies as well.
Several years ago I was a product leader in a large business unit in a large enterprise. Our product had several thousands of paying customers, and similar to many organizations, we balanced our investments between increasing sales and supporting existing customers. We had a proven development and go-to-market process that was working, which resulted in a 30% growth year over year.
We wanted to plan for long term growth and therefore we also invested in new product innovations designed to expand into a new market (and increase our Total Addressable Market- TAM).
Our first step was to turn to our existing customers and prospects, believing they will help us get this off the ground as quickly as possible. We were very wrong!
It took us a while to realize they didn’t have the same pains and needs as the new market we were targeting. We realized that applying their feedback for ideas and solutions would negatively impact our progress to find product-market-fit:
It is absolutely critical to vet the people you are getting feedback from, and make sure they represent the market you are targeting (and therefore are candidates to become your early adopters). As you can see, this problem applies just as much to large corporations trying to innovate, as it does to startups.
Whether you are a startup, or a large company, when you target new market opportunities, the solution is finding your early adopters.
To be able to find them, you need to go through the customer development methodology (a customer-centric, scientific process; pose a hypothesis around who the potential consumers are, or how to meet their needs; then design an experiment and “get out of the building” and test it).
Plan an iterative approach to define and refine the following 4 hypotheses:
When you are done validating a hypothesis, move on to the next one. Any shortcuts or gaps in validation in early stages will result in exponential efforts to adjust in later stages.
Recently, I worked with a company that demonstrated the impact of not validating the problem hypothesis well enough in the right stage.
The company had built a product targeting a problem faced by the privacy market: the European GDPR regulation had come out, and companies found themselves needing to comply through a lot of repeatable manual effort. These were large enterprises, mostly in the retail industry.
The company wasn’t gaining traction in this market, and after joining and digging into this, I learned that the specific problem the company was addressing just wasn’t urgent for chief privacy officers (the buyer) or privacy managers/engineers (the user).
Eventually, after going through a proper customer discovery process, we pivoted the technology to a problem faced by the security market- mid and enterprise companies in the US, who had a significant amount of intellectual property they needed to protect. The beachhead industry we targeted was manufacturing and eventually, we closed the year with a dozen new customers.
Had the company validated their problem hypothesis from the start, taken the time to understand the privacy market, and the actual urgent problems it was facing, it would have been able to pivot and address the right security use cases much sooner, and saved a lot of wasted time and engineering effort.
While working in the large enterprise I mentioned earlier, we faced a different challenge- we didn’t validate our price hypothesis early enough.
The product we were working on targeted a new market, and a new buyer who we weren’t familiar with. This buyer had lower budgets than we were used to, and therefore a lower “willingness to pay”. This made us recalculate our cost structure and therefore our pricing. This in turn, required significant functionality tradeoffs (one example was how far back we stored data). Had we performed this validation earlier on, we could have made those tradeoffs sooner, and again- prevented the waste of numerous engineering hours.
In my next posts, I will provide examples and practical tips for the next steps in this process — getting out of the building and talking with potential early adopters as well as how to evaluate what you are getting.
Previously published here.
Create your free account to unlock your custom reading experience.