Your framework is not the work. The read is.

You run a team that lives on frameworks. RICE for prioritization, JTBD for discovery, OKRs for planning. And now someone hands you an AI feature nobody has ever used and asks if customers want it. The old moves start to creak. Let me catch you up on what actually works when the templates and the interview scripts stop fitting.

The clean math that ranked your worst idea first

Here is the trap with scoring tools. They give you a number, and the number feels like proof. It usually is not. As Bart Krawczyk puts it, "a number you can't defend isn't evidence of product rigor." Your impact of 7 is someone else's 4, and neither of you can prove it.

He learned it on a freemium product with more than 50 conversion points. He scored everything, ranked it, and presented the top item with full confidence. It was wrong in a factual way, not a matter-of-opinion way. The framework flattened 50 moments into one list and buried what mattered.

The fix is not a better framework. It is reading your context first. Krawczyk says choosing the tool is the easy 20 percent. The other 80 percent is the read, and almost nobody does it.

Bend the tool, or drop the whole shelf

At Brainly, the funnel assumed the user was the buyer. But the users were teenagers, and teenagers do not enter credit card details. Parents do. Reweighting RICE around the actual buyer flipped the ranking. Dead-last features jumped to the top. Same framework, opposite answer.

So before you open a template, run a one-paragraph diagnosis. Is the problem complicated or truly complex? Is the decision a one-way door or a cheap two-way door you can reverse? What stage is the product in? Krawczyk's point is that half your process bloat vanishes once you spot how many one-way doors are actually two-way doors.

And sometimes the generic rule is backwards. On an adtech platform with over 100 million monthly users, the team showed more ads, not fewer. Complaints dropped, because better targeting came with the increase. Read your reality, then decide if the orthodoxy even applies.

The interview question that has no answer

Good discovery leans on one move: "Tell me about the last time you did X." It works because past behavior beats guesses about the future. But Jeff Gothelf points out the whole method breaks when the capability has never existed. There is no last time to walk through.

So people fall back on the move we all know is broken: describe the idea, ask if they would use it. They say yes. They are not lying. They are answering for a more organized, more patient version of themselves who does not exist, and they do not want to be rude to you.

Gothelf's shift is to stop asking about your shiny feature and ask about the need, which is not new. Someone is already meeting it with a spreadsheet, a coworker they message, or a step they gave up on. Ask them to walk through the last time they solved it, and pay attention to the parts they apologize for. That is the workaround, and it tells you the real job and the pain they will tolerate.

Build the thing so you can ask about it

You cannot ask someone to recall an experience they never had. So give them one. A clickable prototype, a wizard-of-oz version where a human does the work behind the interface, or a concierge round where you do it by hand for five customers over two weeks. Once they have the experience in mind, the interview skills you already have come back online.

What changed is cost. Gothelf notes that a working version of a novel capability is often an afternoon of work now. The old excuse, that you cannot afford to build something just to learn from it, does not hold. This lines up with Krawczyk testing that higher ad load on 2 percent of users for one week instead of spending a quarter arguing in meetings about whether people would revolt.

When you cannot ask about the product, ask about the decision it would change. Who decides this today? On what information? When did it last go badly, and what did that cost? That gets you the value model without asking anyone to grade a feature.

The deep cut

Before your next round of discovery, finish this sentence about the person you are about to talk to: today, when they need to accomplish [outcome], they currently do [behavior]. Gothelf's line is the sharpest test in the pile. If you can fill it in, you have an interview, and the whole talk can be about that behavior and what it costs. If you cannot fill it in, you are not ready to interview. Go watch someone work first.

Same discipline applies to your frameworks. Krawczyk's one nonnegotiable is to document what you changed and why: "We use RICE with custom weights because a flat Reach score misrepresents our multi-segment market." A documented change invites scrutiny. An undocumented one just pretends to be objective. Both moves force you to admit what you actually know before you spend a quarter executing the wrong list faster.

Three questions for your team

1. For the top item on our roadmap, can we write the sentence "today, when users need [outcome], they do [behavior]"? If not, why are we scoring it instead of watching someone work?
2. Which of our current "one-way door" decisions are actually reversible, and where are we adding rigor we do not need?
3. Every custom weight and skipped step in our prioritization, is it written down with the reason, or are we hiding opinions inside clean math?