🕹️ Opportunity Solution Trees for product managers: the AI-era prioritisation workflow & /make-requirements-great

Hello!

This is 🕹 prodmgmt.world | Becoming Top PMs Together

🆕 In today’s edition:

🆓 Opportunity Solution Trees for product managers: the AI-era prioritisation workflow

🆓 /make-requirements-great

🔒 New AI Skills

I like quantification. I just don’t trust quantifying things you haven’t learned yet, then treating the output as truth because it has a decimal point.

The real fix sits one stage earlier. Before you prioritize features, you map opportunities. And the way you map them decides whether your roadmap is a set of real bets or a feature queue wearing a discovery costume.

This is the workflow I run for that. It chains three steps, each grounded in Teresa Torres’s Opportunity Solution Tree from Continuous Discovery Habits. I’ll walk all three, since the sequence does the work.

RICE was built to rank features you already understand. Reach, Impact, Confidence, Effort all assume a known thing you can estimate. That assumption holds at the bottom of the funnel, when you have a designed solution and you’re deciding what to build next quarter.

One level up, at the opportunity stage, it falls apart. You don’t have a solution yet, so you can’t know effort. You don’t know reach until you’ve done the research that the scoring is supposed to prioritize. Impact becomes whatever number justifies the thing the team already wanted to do.

So you get a spreadsheet that looks defensible and a rationale that lives nowhere. The number anchors the room. Nobody argues with 8.4 versus 6.1. The conversation ends before the real one starts.

Torres’s position, which I’ve come to agree with, is blunt. Choosing the right opportunities to solve is where product strategy happens. If you skip that and debate features, you never make a directional bet. You just sequence work.

The first skill in the workflow is intake. It does one boring, high-leverage thing: it forces your inputs into the right shape before you draw a single node.

Two of those inputs decide everything downstream.

The first is the outcome. It has to be a measurable behavioral or business result, phrased without a solution in it. If your stated goal is “build a notifications center,” the intake step reframes it to the behavior you’re chasing, something like “increase the share of users who return within 48 hours of a relevant event.” If you can’t phrase your Q3 priorities as customer behaviors you’re trying to change, you’re working from outputs, not outcomes. That’s a five-minute audit you can run on your own roadmap today.

The second is journey nodes, and this is the move most PMs have never consciously made. The nodes are distinct moments in time: Discover, Decide, Onboard, Use, Review. They are not problem categories like Reliability, Trust, or Performance.

That distinction matters more than it sounds. When you organize a problem space by category, you inherit your company’s internal mental model: engineering domains, team boundaries, the org chart. A customer doesn’t think “I have a reliability issue.” They think “I needed to check something right before a meeting and it wouldn’t load.” Moments-in-time framing drops you into the customer’s actual sequence, and it exposes gaps. If your journey has no Review node, you probably don’t know what happens after a customer succeeds or fails.

The second skill turns raw interview material into the tree itself: outcome at the top, opportunities in the middle, solutions at the leaves. The mechanics are where most teams let an opportunity list rot into a feature list.

An opportunity is a customer need, pain, or desire, stated from the user’s point of view. It is never a solution. “Users can’t export to PDF” is not an opportunity. It’s a prescribed solution with the verb filed off. The reframing rule is concrete: “Phone settings broken” becomes “I can’t review all my calendars at once.” Run that conversion on every snippet before it enters the tree.

Do this honestly and you’ll find half your roadmap is solutions dressed as needs, the tell of discovery theater: interviews that confirm what the team already planned to build, with a customer quote stapled on for cover.

Then you run two structural checks on the tree that humans skip under deadline pressure.

The distinctness test runs sibling to sibling: if you can pursue one opportunity without addressing the other, they stay separate; if you can’t, you combine or reframe them. The parent-child test runs down the branch: if solving the child partially solves the parent, the link holds; if it doesn’t, you reframe. And when a generic parent has only one specific child, you delete the parent and promote the child, because the category adds no information.

There’s an optional MECE pass for one slice of the tree when siblings overlap or you suspect a coverage gap. Mutually exclusive, collectively exhaustive. It catches the two failure modes a busy PM can’t see in their own tree: hidden overlap and a missing branch.

Every node also carries its evidence: representative quotes, how often the need surfaced, and a confidence level. Only needs you heard go in the tree. Hypotheses get logged separately so you don’t confuse a hunch with a finding.

The last skill is selection, and this is where the no-spreadsheet rule earns its keep.

You assess each candidate opportunity against four qualitative lenses from Torres. Opportunity sizing: how many customers, how often. Market factors: how it moves your competitive position. Company factors: how it fits mission and strategy. Customer factors: importance multiplied by dissatisfaction, where low satisfaction on a high-importance need is the strongest signal.

These are lenses, not a scoring rubric. You do not produce a weighted number. You write down, in plain language, why one opportunity beats another on each lens. The format is comparative: “Compared to A, B is stronger on customer factors because of this evidence, but weaker on market factors for this reason.”

Watch the phrasing. You never ask “should we address this opportunity?” That’s a binary question, and binary questions invite motivated reasoning toward whatever already has momentum in the room. You ask “which of these is most important to address right now?” Forced comparison makes opportunity cost visible, and people start reasoning about trade-offs instead of lobbying for whatever already has momentum.

Three more rules keep the decision honest. No effort estimates at this stage, because effort belongs to solution exploration, which happens after you’ve picked. Treat the choice as reversible: you’re committing to explore an opportunity, not to permanently solve it, so move with confidence and turn around if you’re wrong. And pick from a crummy first draft, then revise every three or four interviews. Waiting for perfect data is a deferral tax that buys neither certainty nor learning.

The output is a winner with a documented rationale, the key unknowns that could invalidate it, and the next three or four interview questions designed to reduce that uncertainty. Your next round of research stops generating generic quotes and starts answering a real question.

The leverage of AI in discovery is enforcement, and that matters more than the speed everyone talks about.

None of these checks are new. Torres documented them years ago: the distinctness test, the reframing rule, the parent-child logic. PMs skip them anyway when the cognitive load gets high. When you have forty interview snippets and a review in two days, you do not run the distinctness test on every node by hand, and nobody does.

An AI that knows the method runs the discipline on every node, every time. It reframes every solution-flavored quote into a need. It dedupes across forty snippets and links the supporting evidence. It flags the overlaps your MECE pass would have caught. The discipline becomes the default instead of the thing you do when you have a slow week.

Mapping a real opportunity space used to eat the better part of a week of synthesis: forty raw snippets and a blank doc. Now I hand the material to Claude running this workflow and get back a deduped, evidence-linked tree with a defended target in an afternoon. A week of synthesis becomes an afternoon, and the tree is more rigorous than the one I’d have built by hand, because the machine doesn’t get tired on node thirty-one.

The full version of this, the intake skill, the tree builder, the MECE check, and the four-factor selection wired into one workflow, is what /opportunity does inside PM OS. It’s one of 11 workflows in there, and it’s the one I reach for whenever a roadmap conversation jumps to features before anyone has named the need.

If you’re a PM who pastes PRDs into Claude or Cursor for review, you know the feeling. The AI demands the wrong things with total confidence. Paste in a business-intent statement and it comes back asking for latency targets. It flags missing detail that was never supposed to be there yet. The review looks thorough, and it points you straight at problems that don’t exist.

I hit this enough times to realize the problem wasn’t my prompts. The tool is trained to be maximally helpful, and that helpfulness is exactly what wrecks a requirements review.

So I built a skill to stop it. It lives on GitHub as make-requirements-great, and most of what it does is tell the AI to shut up at the right moments. Building it taught me a handful of things that hold whether you use my skill or write your own.

The fix is a concept the AI doesn’t hold on its own. A requirement has an altitude, and you have to know which one you’re reading before you judge it.

There are three of them. A business or strategic requirement describes what the organization wants, and the sponsor owns it. A stakeholder or user requirement describes what a group of users needs, and that group owns it. A solution or functional requirement describes how the system behaves, and the delivery team owns it.

A high-level requirement is a deliberate artifact with its own job, not a low-level one someone forgot to finish. “Update preferences from any surface” does its job perfectly as a business statement. Grade it against solution-level criteria and you’ve made a category error.

This is one of the most common ways a requirements review goes wrong. AI does it by default on every line, because most of its training comes from delivery-team documentation. So the skill starts by asking which altitude a requirement was written at. Then it refuses to apply solution-level tests to a business-level statement. That one instruction goes most of the way to stopping the AI from demanding latencies.

When a requirement is missing detail, AI invents it.

Ask it to shape requirements from a messy thread of notes and it hands you a complete-looking document, where “complete” includes decisions nobody made. If the stakeholder hasn’t set a latency target, the AI writes “within 2 seconds” because two seconds sounds plausible. Now you have a guess presented as a requirement, and three sprints later someone builds to it as if it were real.

The skill treats that helpfulness as a defect. When a stakeholder hasn’t decided, the AI should write a flag rather than a plausible value: “Pending decision: target latency.” At high altitudes, missing detail isn’t a defect at all. It goes on a separate list called “Decisions to be taken during decomposition.” That list sits apart from the defect log, so nobody confuses an open question with a mistake.

The open question tells you where a real human still needs to decide something. A confident guess buries that decision point in the backlog, unmarked, where it surfaces as a surprise during the build. Getting AI to leave gaps open instead of papering over them is half the work.

This next part you can copy and use today.

Before any deeper analysis, the skill runs a literal scan for weasel words. These words feel like requirements but commit to nothing. They pass review, then explode during build when two people interpret them differently.

Here is the list it scans for:

appropriate, suitable, adequate, reasonable, user-friendly, intuitive, efficient, fast, slow, robust, scalable, secure, modern, simple, easy, seamless, flexible, optimised, high-quality, sufficient, normal, typical, standard, as needed, where applicable, if necessary, etc., and/or, may, might, could.

Each hit is a flag, not an automatic fail. The instruction is the same every time: quantify it or remove it. “Handle preferences appropriately” becomes “propagate preference changes to all surfaces within 5 seconds,” or it goes.

This one move takes requirements review from “I’ll know it when I see it” to something close to a grep. A human reviewer reading a 40-page spec for ambiguity spends most of an hour. They still miss half the hits, because attention fades. Run the scan and you get a defect log in about a minute, every word caught, no fatigue. What took 40 minutes to hunt now takes 1.

The deepest lesson took me longest to see. The 18 quality characteristics in the skill split into two groups.

Nine apply to one requirement at a time: unambiguous, clear, concise, correct, testable, implementation-independent, owned, relevant, feasible. A human reviewer can hold these in their head while reading line by line.

The other nine only make sense across the whole set: unique, cohesive, consistent, conformant, current, modifiable, traceable, categorised, complete. These are where real products break. Forty individually well-formed requirements can still contradict each other, drift in terminology halfway through, or miss an entire category like security or performance. No human reads 40 requirements and holds all of them in working memory at once. AI does, and it runs both passes at the same time.

You know the “but everyone signed off on the requirements.” They signed off on the sentences. Nobody checked the set. A catalogue of 200 requirements with zero non-functional requirements isn’t a clean bill of health. It’s an omission.

You can do this yourself. The skill is open on GitHub: https://github.com/gnurio/nurijanian-skills. It’s free to read, fork, and run in Claude Code or Cursor. Start with the weasel scan on whatever PRD is open in front of you right now. You’ll have a defect log before your coffee’s cold.

Requirements review is one recurring PM task. You have a dozen others that AI defaults to doing badly for the same reason: it’s helpful, it fills gaps, and it doesn’t know which chair it’s sitting on. Encoding the judgment for each one as a reusable skill takes real effort. Assembling that library by hand is slow.

That’s what PM OS is: the operating layer where make-requirements-great sits alongside 235 skills and 11 guided workflows. All sitting on top of a memory/context system that self-updates over time.

Share

Leave a comment

Today’s skills are something new and experimental. I distilled the JTBD maestro Bob Moesta’s 2 books - Demand-side Sales and Learning To Build - into 2 fat skills.

• /diagnose-the-switch: Diagnose a buyer’s switch - where they sit on the timeline, which of the four forces blocks them, what move comes next. Use when a deal is stuck, a customer interview needs prep or scoring, a job statement needs writing, a prospect needs disqualifying, or a sales call needs debriefing.

• /engineer-for-progress: Engineer a build in function-space, not problem-space - reframe symptoms, design right-to-left, prototype orthogonally not A/B-style, cut to a kick-ass half, set a wall. Use when a feature request needs reframing, a prototype needs designing, scope needs cutting, a project needs a postmortem, or a build needs scanning for confirmation bias and premature scaling.