Jobs to be done, opportunity tree

Three consequences follow from stating demand as a job rather than as a request, and all three are practical rather than philosophical:

• It gives you more than one candidate. "We want summaries" has exactly one branch and it is already selected. "Arrive at Monday's meeting knowing what we agreed" has several: extract the decisions, resurface them at the right moment, make retrieval fast enough that reconstruction is unnecessary, or get somebody else on the team to carry the record. You cannot choose between alternatives you never generated.
• It survives your own roadmap. Ship summaries and the request is satisfied and gone. The job is still there next quarter, and the tree you built is still the map, with one branch marked done. Requests have to be re-elicited every planning cycle; jobs are re-used.
• It tells you who your competition actually is. Six of the eight interviewed admins never reopen a transcript, and 68% of surveyed admins still take their own notes. Your real competitor for this job is a person typing three lines into a channel while the call is still fresh, which is fast, free and reliable. That is a much more useful thing to know than which vendor is in the next deck.

A job is derived from verified material, not invented in a workshop. The four verified themes from b3 are doing the work here, and it is worth seeing exactly how:

• "The decision is the unit" (3 of 8) supplies the object. What the admin wants is not the recording, not the transcript and not a summary. It is what was agreed. Three independent admins said that in three different phrasings, which is why the job can name it without hedging.
• "Reconstruct from memory before recurring meetings" (2 of 8) supplies the moment. Jobs without a situation are unusable, because you cannot design for "sometimes". "Before Monday's meeting" is a moment, and it is a moment somebody described rather than one you assumed.
• "Do not reopen transcripts" (6 of 8) supplies the constraint. Any candidate that requires the admin to open a transcript is competing with a behaviour six of eight people have already stopped doing. That single count kills entire branches later, cheaply and on evidence.

What does not supply anything is the invented theme. Transcript accuracy had zero sources in the material, and accuracy complaints run at 1.4% of meetings, which makes it a guardrail to protect rather than a job to serve. A theme with no source does not get a branch, and this is the first place in the course where b3's verification discipline pays a visible dividend.

Four things are load-bearing in that sentence, and each one is there because a theme put it there:

• The situation is a moment, not a mood. "When a recurring meeting ends" can be pointed at on a calendar. Compare "when admins are managing their meeting information", which cannot, and which therefore cannot be designed for or measured.
• The segment is inside the statement. Paid workspaces of 5 to 50 seats, not solo self-serve users whose calls are short enough to skim. A job with no segment produces a tree whose branches serve different people, and you will not notice until the third planning meeting.
• No mechanism appears anywhere. Not summaries, not search, not notifications. The moment a mechanism enters the statement the tree has one branch, and building the tree becomes a ceremony that justifies a decision you already made.
• The outcome is theirs, not yours. "The team acts on the decision instead of re-deciding it" is something that happens in their week. "Increase summary adoption" is something that happens in your dashboard, and it is not a job, it is a metric wearing one.

Four fast checks, in the order that catches the most for the least effort. Any one failing means rewrite before you go further, because everything below inherits the error:

• Delete every product name. If the sentence stops making sense, it was anti-pattern A. This catches the most common failure in job statements written by people who work on the product every day, which is all of you.
• Ask whether a competitor with completely different technology could satisfy it. If only your planned feature can, it was anti-pattern B. A useful version of this: could a very organised human assistant do it? For this job the answer is obviously yes, which is exactly why 68% of admins are being that assistant themselves.
• Check it against the counts. Every clause should trace to a theme with two or more independent sources. If a clause traces to the anecdote or to nothing, cut the clause. This is where a job statement quietly acquires ambition nobody evidenced.
• Read it to somebody who does not work here. If they can restate the job in their own words after one reading, it is a job. If they ask what the product does, you have written a feature description.

This is the highest-value habit in the session and it takes about three lines per branch. Everybody builds the tree. Almost nobody records what happened to the branches they did not take, and the cost of that omission is entirely predictable:

• An unrecorded cut is not a decision, it is a gap. Nothing in the tree says whether a missing branch was considered and rejected or never thought of, and those two look identical three months later. Somebody will raise it again, in good faith, and the team will have the same discussion with less evidence and less patience.
• Write three things, not one. The branch, the reason it was cut, and the condition that would bring it back. The re-open condition is what turns a cut from a verdict into a decision with a shelf life, and it is the part that makes the person who wanted that branch willing to accept it.
• Cut on the evidence and the job first, on cost second. "Six of eight admins never reopen a transcript" kills a branch cleanly and permanently. "It felt expensive" does not, and it will not survive contact with somebody who wants the branch. Where cost is genuinely the reason, say so plainly and put a number next to it, because that is a claim somebody can check.
• Put the cuts in the same document as the choice. Not an appendix, not a separate doc, not somebody's notes. Beside the chosen branch, where anybody reading the decision reads the alternatives in the same glance. The trade-off in b5's check 6 is written from exactly this list.

This is one of the better places in the whole PM job to use a drafting tool, because the useful contribution is breadth and breadth is exactly what a tired human at 5pm does not have. Be precise about the boundary:

• Genuinely useful: candidate opportunities you had not considered. Hand it the verified themes with their counts and ask what obstacles to this job the material might be pointing at that are not on your list. You then check each suggestion against the snippets and discard the ones with no source. It is generating hypotheses, and hypotheses are cheap to reject.
• Genuinely useful: three solutions per opportunity. The strongest anti-anchoring device available. Left alone, you will write the first solution you thought of and then two weak ones to make it look considered. Asking for three seriously different mechanisms per obstacle, including one that requires no engineering, reliably produces at least one candidate worth arguing about.
• Genuinely useful: arguing against your chosen branch. "Here is the tree and here is the branch I picked - what is the strongest case for one of the others?" A critique of a fixed set is a much safer request than the generation of a new one, exactly as in b3.
• Cannot do: choose the branch. Choosing needs what the material does not contain - what your team can build and at what cost, what your company is trying to become this year, which customers you have decided not to serve, and who you will have to disappoint. None of that is in the transcripts, and a tool that offers you a choice anyway is producing a confident sentence, not a decision.

The tell is worth memorising: any suggestion that arrives with a source you can check is help, and any suggestion that arrives with a preference is noise. Breadth in, judgement yours.

Beyond level-mixing, trees go wrong in two more ways, both of which look like thoroughness:

• The tree that is too big to decide from. Nine opportunities, four solutions each, and nobody can hold it in their head. A tree is a decision aid, not an inventory. Four or five opportunities is usually the whole honest space for one job, because your research only supports that many. If your tree has nine, several of them are the same obstacle described twice or branches with no evidence under them.
• The tree with no counts. Every opportunity carries its source count or the tree quietly re-flattens everything into equally weighted boxes, which is the same failure a2 described for documents. "2 of 8, plus 214 tickets" beside one branch and "1 of 8" beside another does more decision-making work than any amount of drawing, and it takes four characters.

And one boundary worth stating: the tree does not tell you the answer. It makes the space visible so that a person can choose inside it, on evidence, with the alternatives written down. Anything that promises more than that is selling you a framework.

One sentence, in the shape from Part 2: when [situation], [this person] wants to [motivation], so that [outcome for them]. Then run the two tests on it in this order.

First, delete every product name in the sentence and read what is left. If it stops making sense, you wrote anti-pattern A, which is by far the most common outcome for people who work on the product daily - the product is the water you swim in. Second, ask whether a competitor with completely different technology could satisfy the statement, or whether an extremely organised human assistant could. If the honest answer is that only your planned feature fits, you wrote anti-pattern B and the tree you were about to draw would have had exactly one branch.

Most people fail one of the two on the first attempt. The rewrite takes ninety seconds and it is the highest-leverage ninety seconds in this session, because every level below inherits whatever you wrote at the top.

Write the obstacles between your named person and your job - as many as your evidence supports, with a source count beside each. Anything you cannot count gets written down with a question mark rather than left off, because a blank count is a research task and an absent branch is invisible.

Then take your single strongest obstacle and generate three genuinely different solutions for it, one of which must require no engineering at all. This is the step worth handing to a drafting tool with the obstacle and the supporting snippets attached: breadth is what it is good at and what you are worst at once you have had an idea you like. Judge nothing until all three are written down.

The uncomfortable part comes next. Look at the solution you had in mind before this session and ask whether it is still the best of the three, or merely the first. It is fine if it wins - most of the time it does, and now it has beaten something. What you are buying is the knowledge that it was chosen rather than arrived at.

Find something your team decided not to do in the last two quarters - the bigger the better, and ideally one that has already come back once. Now try to answer three questions from written material only: what was the branch, why was it cut, and what would bring it back.

You will almost certainly find the first, occasionally find the second in somebody's meeting notes, and essentially never find the third. That is the normal state of affairs and it is exactly why these arguments repeat. Write all three down retroactively now, in the document where the original decision lives, and mark clearly that you are reconstructing rather than recording - a remembered reason is weaker evidence than a written one and should look weaker on the page.

Then check the re-open condition you just wrote against reality. Quite often the condition has already been met and nobody noticed, which means the branch should be back on the table this quarter. That is the second dividend of recording cuts, and the one nobody expects: it tells you when to change your mind without anybody having to argue you into it.