The Product Death Cycle and How to Escape It

Asking your customers what to build seems like a good idea. It's also the surest way to fall into the product death trap.

The product death cycle looks like this:

You come up with an idea for a new product (or a feature) and follow the tried and trueBuild-Measure-Learn (BML) cycle:

1. Build a minimal viable version of your product,

2. Release it so you can measure results,

3. Learn from what you’ve measured and refine your MVP,

4. Repeat until you find a good product-market fit.

It sounds like the perfect plan when you talk about it with your team. But then something else happens.

You launch your product with great aplomb just to see the usage metrics kissing the x-axis. The free subscription count is growing, but the actual engagement sucks. Conversion to paid plans is also lagging.

Naturally, what you are offering doesn’t quite resonate with your users. Maybe you need new features. But what new features?

You do the common-sense thing: you “just ask your customers” what to build next. After all, if you build what they want, then they should be using it.

⚠️ On why this is a terrible idea, read: What to Ask Your Customers, So You Build the Right Thing.

There is no shortage of advice. Your Slack community is bursting. Your feature request board is running counts in the thousands. Off you go building, building, building.

But still...

No one uses your product.

Congratulation. You are caught in the product death cycle.

Now, let’s talk about how to get out of it.

But hold on. This doesn’t make sense. If I’m building what users want, why are they not using it?

An app developer once told me that his users were assholes: they requested and upvoted features, but once built, they never used them.

Of course, his customers were assholes. At least most of them. They were just humans. And as humans, we are horrible at predicting our future behaviour. Every Sunday, I make plans to work out 5 times in the coming week. Ask me on the following Friday how I did.

It’s a popular research heuristic: what people say and what people do are two different things.

So, if we accept the reality that our customers have no idea what they will do in the future, there is no point asking them about their future behaviours.

There is something else at play too. When you ask someone to come up with a feature they’d like to see, their mind switches into a divergent ideation mode. They start thinking of all the cool things your app can do. The question “Will I actually use this” becomes secondary.

Recently, I had the following conversation:

Them: It would be cool if the app had a time tracker for each task

Me: Have you used such a time tracker in other apps in the past? How often did you track your time on a task in the last month?

Them: Well, no, I usually don’t, but it will be a handy feature to have.

The only way to build something your customers will actually use (and pay for) is by discovering their real needs and pain points. Asking them to ideate on the cool shit you can build is a fun but useless exercise.

Escaping the product death cycle

David Bland explains that startups fall into the product death cycle because they interpret the build-measure-learn paradigm too literally. Founders often spend time and capital to build products based on weak evidence of demand.  

I’ve seen two common patterns:

1. Founders do a basic survey, often with a loosely defined market, and get some directional validation. Usually, this evidence is extremely weak. It’s partly because the users put up no stake. The goal of these surveys is to answer the question: “If I build A, would you buy it?” So, they often ask leading questions about hypothetical solutions (not user problems).  

2. Founders don’t do a basic survey. They fool themselves that a) they know their users, or b) they are building the solution for themselves, and so, they know their users.

David Bland says founders should spend more time validating their hypotheses through a series of tests and experiments. Ideally, they will ask the user for a commitment (e.g. providing credit card information, putting down a deposit, sharing a link to a landing page). Any type of test where the user has to put up time, money or reputation on the line provides stronger evidence than simply asking them for hypotheticals.

David’s book Testing Business Ideas has over 40 experiments you can use to validate the product-market fit of your product before you write a single line of code.

But running experiments is not always cheap. Cost and time rack up, especially if you are seeking strong signals. Fortunately, there is something you can do, so you don’t dive in blind into experimenting. That something is discovery research.

Discovery research comes first

If you are like most founders, you’ve already done some discovery research. Probably, it has come in the form of researching competitors, speaking with users, and reading user comments in various communities. Jeanette Mellinger, head of UX Research at BetterUp, describes this type of research as valuable but lacking rigour.

Your approach to discovery depends on your starting position. Often, you have two options:

• Open-ended discovery

• Hypothesis-driven discovery

Open-ended discovery

You don’t have an idea, but you have a vertical or customer in mind. Many companies with successful core products take this approach in building adjacent innovation. They know they want to operate in market A but don’t know what their offering will be.

For example, a few years ago, I worked for a company that wanted to enter the e-mobility market. We saw it as an adjacent market to our core vertical, so we wanted to explore it. We didn’t have a product in mind. Our goal was to survey the space and uncover large problems we could solve.

If this is your starting point, use these methods to start discovery:

• Collect internal knowledge: if you are part of a bigger organization, there may be internal knowledge within your team. Identify the subject-matter experts, set up interviews and document your learnings. Keep in mind these people are not your target market and oftentimes may be too close to the kitchen to maintain an unbiased opinion.

• Desk research: chances are someone has already studied the market you are after. Industry reports and market studies are usually too broad to be useful at a tactical level, but they can give you good directional signals.
  
  Two years ago, I was working with a startup building a platform to help mature women get into tech. But what part of tech? We used WEF’s Future of Jobs report to identify high-level trends of jobs on the rise and skills in demand. The company was based in Spain, so we focused on the Spanish market. The report didn’t tell us what we should build, but it suggested that data science and analytics could be a good niche.

• Observational studies: the best way to learn about your users and their pain points is by observing them (not creepily) complete a job. You can conduct these types of ethnographic studies by being physically present with the user or by monitoring them remotely.

• User interviews: compared to observing your users, this approach is a notch lower in effectiveness. Still, it takes less time and is usually cheaper. Set up individual interviews and ask your users open-ended questions about their experience in your area of interest. User interviews work best to learn more about behaviours, attitudes, and pain points your potential customers might have.
  
  A few years ago, I was working on a financial modelling service for early-stage startups. I conducted several interviews with potential users. I learned that financial modelling and planning is not an urgent pain point at this stage of business building. Validating their product-market fit was. These early signals of my research told me that a financial modelling service would not have resonated with this market. I had to find a better market or pivot.

Hypothesis-driven discovery

This is the starting point for most entrepreneurs. You have an idea and you want to validate it with the market. The first step is to define the key assumptions (hypotheses) that must be true for the idea to work. You rank them based on their impact on the overall success of the business and how much you know about them. The ones with the highest impact and the lowest knowledge represent the highest risk. This is where you start testing.

What methods you use will really depend on the hypothesis. Some methods you can use include:

• Competitive testing: you ask the user to complete a task on a competitor’s product. The idea is to identify pain points you can address and offer a superior experience.

• User Interviews: usually, we combine those with competitive testing but you can do them separately. The idea is to understand behaviours and attitudes towards the problem in your hypothesis.

• Observational studies: if your hypothesis is built around a pain point of how users currently accomplish a task, observational studies may be appropriate.

The evidence you collect through your initial research will give you some guidance on what you need to validate further. This is when you can start exploring experiments and probing for stronger signals.

If all of this seems like a lot of work and effort, it is. Still, it’s less work, effort and money than building something no one wants.

The good news is, you don’t have to do it alone. I help founders go through the discovery process so they build products their customers (and investors) love. If you need help, drop me an email, and we’ll schedule a quick call.