You shipped it. Adoption didn't follow. This finds out why — and leaves you with a fix list you can act on this sprint.
Its possible that the product has low usage, but the product is not necessarily at fault. Instead, it may be that users are not finding the product in the first place, or if they find it, they are not able to register or sign up. It could also be that the process to onboard is complex.
A demo is a controlled setting. The person has time set aside, someone is guiding them, and the example data has been chosen to work. Everyday use has none of that. The feature may sit somewhere people don't pass through in a normal week, or it may ask for a step they can't complete with the data they actually have. It's also possible that it works, but not well enough to be worth changing a habit for.
Both answers are expensive when they're wrong. Killing a feature people want but can't reach throws away real demand. Keeping one nobody wants spends engineering time every quarter it stays. The question is usually answerable: whether people are reaching the feature at all, and whether the ones who reach it get what they came for. Those are two different problems with two different fixes.
A mixed-methods diagnosis, built to close in one sprint cycle:
Funnel data shows where people stop, which narrows the search considerably. It doesn't say why they stopped, so this stage is about locating the drop rather than explaining it.
Prerequisiteaccess to analytics to build funnel data.
Walking the flow against known usability principles turns a drop-off point into a list of specific, nameable problems. This is where “60% leave at step three” becomes “step three asks for information most people don't have to hand”.
Prerequisiteaccess to the live product, or a working staging environment, with an account that can complete the flow end to end.
The people who stopped using something can usually say what they were trying to do and where it stopped being worth it. This is the part of the study that recovers intent, which is what tells you whether the feature is wrong or simply hard to reach.
Prerequisitea way to identify who reached the feature and stopped — product analytics or CRM records. Contacting and scheduling them is part of the study.
A list of everything wrong isn't much use on its own. Ordering the problems by how much of the drop-off each one accounts for, and by what can realistically ship soon, gives the team something to start on.
