You have the data and the interviews. You asked them in the wrong order.
A dashboard, a research repo with sixty interviews in it, and the last four things you shipped sitting at single-digit adoption. That is not a rigour problem. It is a sequencing problem, and it has three distinct shapes.
The teams that ship the most dead features are rarely the ones with no data.
They have a dashboard. They have a research repository with sixty interviews in it. Someone on the team can tell you the activation rate to two decimal places. And the last four things they shipped are sitting at single-digit adoption.
I used to read that as a rigour problem. It is not. It is a sequencing problem.
There are three questions in front of any product decision: where it hurts, why it happens, and whether your fix works. Most teams answer one of them properly and guess the other two, and which one they answer well is usually a function of who happened to be free that week.
Three ways the order breaks
Why without Where
The team talks to users constantly. Nobody can tell you which number the conversations are supposed to move.
You know this one by its output: a research repo that grows every month and gets opened twice a year, and a team that genuinely believes it is customer-centric because the interviews are happening. They are. They are about everything, so they produce insight about nothing.
The tell is a specific sentence in a readout: "users also mentioned...". If the findings arrive as a list of themes rather than as an answer to a question somebody asked, there was no Where.
Where without Why
This one is more expensive, because it looks like rigour right up until you ship.
The funnel says people leave at a particular screen. So you fix that screen. You have a number, you have a location, and you skipped the question of what is actually causing it, because the cause seemed obvious.
At elyps our analytics said eight in ten new sign-ups abandoned onboarding at the screen right before identity verification. The obvious read, which published market reports agreed with, was that the ID check was too much friction. The interviews said something else entirely: people were opening the app on the subway and at work, and did not want to pull out their ID in public. The problem was the moment, not the step.
Had we skipped Why, we would have spent a quarter simplifying a legally mandated identity check and moved nothing. Instead the fix was a "Do it later" option and an evening reminder, and drop-off on that screen went from roughly 80% to 60%. The case study is here.
Whether without either
A backlog of forty test ideas, a single-digit win rate, and nobody able to explain why the winners won.
This is the most defensible-looking failure of the three, because experimentation is happening and experimentation is good. But a test without a Where is a test on a number nobody agreed mattered, and a test without a Why is a lottery ticket with a control group attached. You will occasionally win. You will not be able to repeat it, because you never knew the mechanism.
Why capable teams do this
Not carelessness. Ownership.
Each of the three instruments tends to live with a different person. Analytics sits with the PM or a data analyst. Interviews sit with the designer or the researcher. Experiments sit with growth, or with whoever owns the flag. So the questions get answered in the order of who is available, not in the order that produces an answer.
Then each function reports back in its own vocabulary, and the team assembles a decision out of three partial answers that were never pointed at the same thing.
That is an operating-model tell rather than a skill gap, and it usually goes with the other one: the team does not have direct access to all three of users, data, and the people who decide. When access is rationed, you use whichever instrument you can reach.
The fix is not more research
Almost every team in this position has enough raw material already. What they do not have is agreement about which question is currently open.
So make it explicit, out loud, before the work starts. Four checks:
- Can you name the number and the segment? Not the metric. The number, and who it applies to. If not, you are on Where.
- Can you name the mechanism, and does everyone name the same one? Ask three people separately. If you get three answers, you are on Why, whatever the roadmap says.
- Can you state a result that would stop you shipping? If not, you are not on Whether yet either, you are on a plan.
- Do you know what the last decision taught you? If the answer is a slide rather than a number, the loop is not closed.
Most stuck decisions I see fail check 2. Everyone agrees on the problem, nobody has noticed they disagree about the cause, and the meeting is really an argument about mechanisms conducted in the language of solutions. That is also, incidentally, how a team ends up back in the product death cycle with better instrumentation.
Order is cheaper than volume
None of this asks for more research, more analysts, or a new tool. It asks the three questions in a fixed order and makes each one leave something behind.
That is the whole of the 3W Loop, and the framework itself is free to use and adapt under CC BY-SA 4.0, kit included. It also pairs with the distinction most teams need alongside it: being data-informed rather than data-driven, since a number tells you where to look and never why.
When a team has all three instruments and still cannot sequence them, that is usually a capability gap rather than a tooling one, and closing it is what Product Advisory exists for.