The Complete Guide to Nailing Customer Feedback

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:

1. How do you know whether you have a feedback problem?
2. What is the most common cause?
3. Who is at risk (spoiler: everyone)
4. What is the solution? (there is a really good and proven one)

How do you know whether you have a feedback problem?

The easiest symptom to recognize is no feedback- you still haven’t successfully engaged with customers to get feedback

• Contradicting or inconsistent feedback- you are unable to find commonality in responses to questions you are asking — preventing you from making critical product decisions
• Too much feedback- too many lists of features that are defined as a “must-have” for the MVP, resulting in a lot of waste added to the product, that isn’t really critical
• Too much positive feedback- everything you are hearing is validating your hypotheses, meaning you aren’t actually learning anything new

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.

What is the most common cause?

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.

Who is at risk?

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:

1. We received very tactical and positive feedback — these customers knew us and thought this is how they could help (sponsor bias is a known issue when conducting research. When respondents know the sponsor of the research, their feelings and opinions about that sponsor may bias their answers). Because they did not actually suffer from the problems we were aiming to solve, and they were not actively looking for solutions, we did not get the critical pushback and vetting that we needed. No door was slammed in our faces — and that was bad!
   
2. We also faced the flip side of this- we spoke with a customer who ripped our ideas to shreds. Our initial response was excitement for finally getting some critical feedback, but after letting it sink for a while, we realized most of their feedback came from their concern we were going to change their product, and they just didn’t like any change.
   

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.

What is the solution? Whether you are a Fortune 50 company or an early-stage startup- it is the same!

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:

1. Problem hypothesis- what is the problem you are trying to solve?
2. Target market hypothesis- who do you believe suffers from this problem? Is it big enough?
3. Solution hypothesis- does your target market believe your solution solves this problem?
4. Price hypothesis- does your target market find enough value in your solution to be willing to pay you for it?

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.

Lessons learned:

1. Getting the right feedback from the right people, is a problem relevant for large companies as well as small startups
2. You shouldn’t use your existing customers when your product is targeting a new/different market
3. If you don’t engage with the right people (early adopters) early on, this will turn into exponential costs and efforts later on

Previously published here.