Escaping the product death cycle
TL;DR
- You must understand your particular case of product death cycle through a proper diagnosis, before you can tackle it.
- Escaping the product death cycle will likely still mean producing new features, but you need to be very stringent on your prioritization.
- Know who you are talking to — and know what share of your users you are missing out. Don’t let yourself be guided entirely by a small group of power users.
- Use all the tools and methods for user-based learning available to you. Interviews, surveys, observations, data — and develop your own insights.
Analyzing what diffusion models in image creation or LLMs get wright and wrong is a topic worth at least one other article, should I ever write this other article, remind me to link it here.
But let’s dive in: Product Death Cycle. This article will focus not so much on the definition of the issue, rather much more on possible solutions to it — and will be an open sharing of our experience at Varia of what works and what does not, from our perspective. Keep in mind, all products, markets, teams and customers are different, so what worked for us might not pan out as well in other cases.
What is it?
As stated above, the definition of the product death cycle is not the main point here, mainly as there is plenty of good definition work already out there. But still, one visualization and a short explanation cannot be left out here:
David Bland has to be credited whenever one writes about this issue, as he is the one who coined the term and he also created the above, brilliantly simple visualization of the product death cycle.
People use different terms meanwhile to essentially describe the same problem. Melissa Perri refers to the problem as “the build trap” in her bestselling book, many others use the term “feature factory” — however I don’t know who came up with that first. Maarten Dalmijn certainly has written a nice article under that term, allowing you to recognize when you are trapped in a feature factory.
Diagnosis
Before jumping to ways out of the problem state, we have to look at what exactly is the problem. What I sometimes miss in articles about the product death cycle is an exact diagnosis. What is the reason behind your “no one uses your product”? Is it an awareness and customer acquisition issue, or is it an onboarding and activation issue? I think this is essential to differentiate, as depending on your root cause, different resolution measures will be appropriate.
Most companies face the product death cycle in rather early stages, likely pre product market fit. A precise diagnosis at this stage can be more difficult, as you have access to a smaller user base and as your monitoring systems are potentially not fully developed yet, limiting your observation options. Still, you must be able to know where in your acquisition funnel, the relevant drop-off is happening, where are users losing interest? Only once the where is clear, you can dig deeper and try to figure out the why.
Resolution
Some of the authors linked to above also provide great insights into how one might escape the product death cycle. Another great resource is this post by Pawel Huryn, as it not only highlights potential remedies, it also links to further great content on the matter. Now on to a subjective list of things that we tried, see working, or that I think are worth paying special attention to, when dealing with the product death cycle.
- Learning from your users
- Prioritization & engagement wall
- Expectations & communication management
Learning from your users
Oh wow, you must think — getting knee-deep into a medium article only to hear that one should learn from users. What a reward. But stay with me, there are things that are important in that realm.
In the above visualization by David Bland, one of the nodes says “ask customers what features are missing”. That is a question that should never be asked.
Learn to ask the right questions, focus on what the users are trying to accomplish, what job they are trying to get done. Try to understand how they are solving the problem today, what competitive solutions or workarounds are they using? Where do they have pains on their current pathway?
Only if you ask these types of questions, you can come up with new, original ways of solving a problem. This is a little bit related to the faster horses issue; you can’t count on your users to come up with original feature ideas. But you can absolutely count on them to provide insights into their struggles. It’s your job, the essential job of an entrepreneur, to then aggregate these user problem statements and come up with original ways to address them.
Another point is how you learn: talking to users is preferred, but it will not always work. Next to actual talking, there is the option of surveys, which can be an asynchronous way of asking relevant questions, even though less engaging. Other than that, you have to resort to observation methods in order to still learn from your users. Product insight and monitoring tools are abundant, choose one that works for you and provides the insights that you need. Again linking to the diagnosis, only when you know where to look, you can choose the right tool. For us, a combination of MS Clarity, MongoDB Charts, Kompassify, and Google Analytics provides great insights. Next to observing via tools, there is of course the option to observe real users live, shadowing them while they use your product. This can also deliver great insights, but be aware that them knowing that you watch will lead to different behaviours (Hawthorne effect).
And who you learn from: Be aware that those users who are ready to provide feedback in engaging calls are maybe not representative of the group of users you should be talking to; those abandoning your product/service. This is a big issue. Users who give your product a try but for whatever reason do not derive value from it, will quit it, and will have little motivation to engage in a call or survey. An Amazon voucher or other type of benefit/incentive might help, but only marginally.
So who are you left with? Your power users. Are they worth talking to? Absolutely, but be aware that you are talking to deeply engaged users — and be aware who you are not talking to. This links perfectly to the next important concept: the engagement wall.
Prioritization & engagement wall
To me the concept of the engagement wall is one of the most helpful and powerful ones, when dealing with the product death cycle. It’s very well described in this article by Andrew Chen. Andrew shares this graph in his article:
The chart is something that you need to develop and analyze for your own business. This is part of the afore mentioned essential diagnosis. You need to know where you have the relevant drop-offs. As illustrated in the above example, the biggest one will likely be in any action after a visit — that is normal and not necessarily a sign that you need to invest there. The “D1” etc. points on the x axis above stand for revisits/engagement after a certain number of days. In the above example, only 2% of people who ever visit your homepage are still engaged with the product after 30 days. Rest assured, these are average, not terrible numbers.
Apart from measuring engagement after a certain amount of days, you can look for specific activities that users take. How many reach a certain aha! moment of your product? If you work with North Star as strategic guidance and measure, the aha! moment should be reflected in it — so you should evidently measure what percentage of users get to one or more aha! moments of your product.
An aha! moment is a unique value proposition of your product, where the user realizes what value your offering provides.
In our product, Varia Research, this is e.g. the capability to work with online documents, create highlights and other annotations. Another aha! moment would be the automated creation of summaries for online articles. We have learned that far too few users ever get to experience those — and lose interest long before.
Here is how this ties to the issue of getting selective feedback, from power users mostly, as mentioned above. Power users will get to the deep engagement features, they know and love your product already. They will have requests and wishes that are relevant to them — but maybe only to them! How are their wishes helping you realize your product vision? Are their wishes representative for a relevant market?
The way out of the product death cycle will very likely and paradoxically contain more features. You might remove certain functionalities, but building new things will still be part of it. So yes, to escape the feature factory state, you will have to work on new features. BUT! When you are prioritizing features, look at your engagement wall and ask yourself how many people will ever see this? It might be a great feature, but if only your power users are going to experience it, it will not help you out of the product death cycle misery.
Furthermore: keep in mind that you don’t have to build all features. When prioritizing, you can also decide that you will actually build feature X, low-code-test feature Y and further validate feature Z. Far too often, especially in companies or startups that are a few years in, the prioritization only focuses on what is getting built first, next, or later. But you can also sketch, test and learn — without building.
Expectations & communication management
What are you selling? What are you over-selling? What does a typical visitor of your homepage think he/she is getting, when they click on the sign-up button? Why are they even on your homepage? What are they trying to achieve?
All these questions are very relevant and can provide great cues on the way to resolve the death cycle issue. But do you have the answers to them — in a representative manner — or do you only have some anecdotal statements? We had far too few insights in that realm and knew far too little about the average first time user of our product. Surveys are not getting answered enough, interviews and calls even less frequently, in order to have reliable amounts of data.
Our way towards more insight here was to force a questionnaire upon first time users as part of the onboarding flow. “Forcing” something upon your users is not nice, so you have to be gentle. Ask only what is necessary, make it easy and quick to answer. Questions like “what is your use case?” or “what are you trying to get done here?” can be incredibly revealing. You can of course also alter those questions, learn something different after a while. It’s certainly better to alter the questions, than to just stack more and more, making this more cumbersome for the user. Depending on your product, you can also use the answers from such an onboarding survey to customize the first-time experience of your product.
I linked to a lot of content in this article. Let me know what your most valuable resource is on that topic in the comments, so that this can grow into a repository on the product death cycle! Of course, also personal stories and learnings are very welcome.
This story was researched and written using Varia Research.
Thank you for reading, comments & feedback!
