Feature Bets: feature prioritization with evidence, not scores

Most roadmaps are a list of bets dressed up as decisions. Someone pulls a feature into "next quarter," the doc gets a confidence label that means nothing, and three months later nobody can reconstruct why it was there. The honest version of feature prioritization with evidence isn't a scoring spreadsheet. It's being able to point at the customer quote that put each item on the list, and the counter-evidence you chose to ignore.

A Feature Bet is our attempt to make that honesty structural. Instead of a title and a RICE score, every candidate on the roadmap carries the same six fields: the problem, the audience it hurts, a confidence level, the expected outcome, the counter-evidence, and the risks. If you can't fill those in from research, it's not a bet. It's a hunch, and hunches don't get ranked.

Why scores hide the reasoning instead of showing it

RICE, ICE, weighted shortest job first: they all collapse a messy judgment call into one number. The number feels objective, which is exactly the problem. A 7.2 tells you nothing about whether the "impact" came from twelve interviews or one loud account, or whether anyone checked for evidence pointing the other way.

The reach, impact, and confidence inputs are usually guessed and then never revisited. So the score launders an opinion into a metric. When the feature ships and underperforms, the trail is cold. You can't tell whether the bet was wrong or the estimate was. An evidence-based roadmap has to keep the reasoning attached to the decision, not boil it off.

The six fields of a Feature Bet

Each field forces a question that a score lets you skip:

• ·Problem. The specific pain, stated in the customer's words, traceable to source quotes rather than your paraphrase of them.
• ·Audience: who actually has this problem and how concentrated it is. "Power users" and "three enterprise admins who all churned" lead to very different bets.
• ·Confidence. Graded by how much corroborating evidence exists, not how strongly the loudest stakeholder feels. A theme cited by two interviews is a different confidence than one cited by nine.
• ·Expected outcome. The result you'd accept as proof it worked, written before you build so you can't move the goalposts after.
• ·Counter-evidence. The quotes and signals that argue against the bet. Surfacing them is the point, not a formality.
• ·Risks. What breaks if you're wrong: wasted cycles, a worse experience for a different segment, a commitment you can't walk back.

The counter-evidence field is the one most processes are missing, and it's the one that earns the word "defensible." A decision you can defend isn't one with no objections. It's one where you saw the objections and can say why you bet anyway.

Where the evidence comes from

None of this works if filling in six fields is manual archaeology through old call notes. The inputs have to come straight out of research. In Klyr, you upload interviews and notes, synthesis produces themes where every claim links to a verified source quote, and themes that can't muster at least two citations get dropped automatically. The Feature Bets are generated from what survives, so the problem statement, the audience, and the confidence level are inherited from cited evidence instead of typed in from memory. You can see a live cited report to watch how a claim threads back to the quote behind it.

Cited synthesis on its own is table stakes now. NotebookLM and your coding agent will both do it for free, and we're upfront about that in the comparison with NotebookLM. What's harder is keeping the citation attached all the way from raw quote to ranked decision, and then to the outcome after you ship.

Ranking, honestly

Once bets carry real fields you can rank them without pretending the order is math. Confidence and audience size give you a defensible sort; counter-evidence and risk tell you where to be cautious near the top of the list. The ranking is a starting argument, not a verdict, but it's an argument every field can be interrogated, which is more than a number on a spreadsheet ever offered.

Be honest about the limits. Evidence skews toward the customers who talk to you; quiet churned users and never-signed-up prospects are underrepresented in any interview corpus. Strong citations reduce guesswork, they don't remove judgment. The bet is still a bet. The discipline is making sure it's a bet you can explain six months later, not one you have to reverse-engineer.

The part most tools forget

Generating a ranked, cited bet is only half the value. The other half is what happens after it ships. A Feature Bet with an expected outcome is a hypothesis with a built-in check: when the result comes back, you learn whether the evidence pattern that justified it actually predicted reality. That outcome feeds back into Product Memory, so the next round of prioritization starts from what your own bets have taught you, not a blank doc.

This is the gap in the agent-driven workflow everyone's adopting. Your coding agent will happily build the feature, but it forgets the moment the session ends. It never learns whether the bet paid off. The persistent evidence-to-outcome graph is the thing a fresh chat can't reconstruct. Klyr is the memory it loses.

Start with one decision

You don't need to overhaul your process to get the benefit. Take the next feature you're about to commit to and write its six fields, sourced to real quotes. Especially the counter-evidence. If you can't fill them in, that's the finding. If you can, you've got a decision you can defend in a roadmap review instead of a score you have to apologize for. When you want the evidence-to-outcome loop to run for you, you can start free.