Strategy & Planning — Skills

Product Discovery & Scoping

Turns a request into a scope that can be estimated, staffed and shipped — with everything still unknown named rather than filled in.

Deliverable

One Markdown document, scope-definition.md, in the structure set out under Output below. It is the input to Roadmapping & Prioritisation.

Required inputs

The request, in the requester's own words — a brief, an email, a ticket or a meeting transcript. One is enough; more is better.
A named approver — the person who can sign off the outcome statement. Without one the result is a proposal, not a scope.

If either is absent, stop and report it. Never infer a request from a codebase: code shows what was built, not what was wanted.

Optional inputs

Repository access, system documentation, schemas, API contracts
Workflow descriptions, support tickets, user interviews, analytics
Budget, deadline, regulatory or contractual constraints
Earlier attempts at the same problem, and why they stopped

Every optional input that is absent becomes an entry under Open questions. It never becomes a guess.

Execution

1 — Separate the request from the problem. Record the request verbatim with its source and date. State the problem it implies: who has it, how often, and what it costs them now. If the problem cannot be stated without naming a feature, the problem is not yet known — write that down and continue.

2 — Inventory the current state. From the supplied material only, list the systems, data stores, integrations and manual work-arounds on the path being changed. Tag each one observed if it was found in a file or system you were given, or reported if a person stated it. An element that is neither does not go on the list.

3 — Draft the outcome and its measure. One sentence of what must be observably different after launch; one metric; its current value; its target. A current value that was not supplied is written unknown — required before approval, never estimated.

4 — Record the constraints. Budget, dates, regulation, systems that may not change, integrations that must keep working. Each with the source that stated it. A constraint with no source is an assumption and is filed as one.

5 — Cut the scope three ways. Ships first, Deferred, Out of scope. A Ships first item must be useful on its own and must trace to the outcome in step 3. An item that traces to nothing moves to Deferred or Out of scope, with the reason written down.

6 — Tag every statement. fact with its source, assumption with what would confirm it, or decision with who made it and when. An untagged statement is a defect in the document, not a shortcut.

7 — Collect what is missing. Every question the steps above could not answer, each with what it blocks and who can answer it.

Output

scope-definition.md, in this order:

1. Request as received — verbatim, with source and date
2. Problem statement — who, how often, what it costs, tagged
3. Outcome and measure — outcome, metric, current value, target, approver
4. Current state — one line per element: name, type, observed or reported, and the evidence
5. Constraints — one line each: constraint, value, source
6. Scope — the three lists; each Ships first item names the outcome it serves, each Deferred item the condition that would bring it forward, each Out of scope item why it is out
7. Assumptions and risks — the statement, what would confirm it, and what changes if it is wrong
8. Decisions — the decision, who made it, when, and the alternatives rejected
9. Open questions — the question, what it blocks, who can answer it

Validation

The document is ready when all of these hold:

Section 3 names an approver and a metric; a target may read to be set by <name>
Every Ships first item traces to the outcome in section 3
Every statement in sections 2 to 6 is tagged fact, assumption or decision
No figure appears without a source; unknown is a valid and expected entry
Section 9 is either non-empty or states explicitly that nothing is outstanding

Fail the run if a Ships first item traces to nothing, or if any number in the document has no source.

Failure handling

No request supplied — stop. Report that discovery has no input and cannot infer one.
No approver — produce all nine sections and mark section 3 UNAPPROVED. A scope in that state may not be estimated.
No access to the existing system — section 4 is reported only. State plainly that nothing was verified, and that every downstream estimate inherits that uncertainty.
Contradictory inputs — record both, name both sources, and raise the contradiction in section 9 as blocking. Do not resolve it by choosing.
Partial material — produce every section the material supports, mark the rest INCOMPLETE — pending <question>, and deliver. A partial scope that is honest about its gaps is usable; a complete-looking one that filled them is not.

Download .md

Roadmapping & Prioritisation

Turns an agreed scope into a sequence — what ships first, what waits, and the reasoning that put each item where it is.

Deliverable

One Markdown document, release-plan.md, in the structure set out under Output below. It takes the output of Product Discovery & Scoping and feeds Estimation & Risk Planning.

Required inputs

A scope list — the items to sequence. Section 6 of scope-definition.md is the expected form; any list whose items are separately shippable will do.
The outcome the work is measured against — the objective the order is optimising for.

Without both, stop. A sequence with nothing to optimise for is an opinion with numbers on it.

Optional inputs

Effort figures from the people who would do the work
Fixed external dates: contracts, seasons, regulatory deadlines, campaigns
Team composition and availability
Known dependencies: systems, vendors, approvals, data migrations
Stakeholder preferences, each attributed to the stakeholder who holds it

Value and effort are never invented. Where a figure is missing, the plan orders on the dimensions that are known and records the item as unscored.

Execution

1 — Normalise the items. One line per item, each separately shippable. Split anything that cannot ship alone, and record the split so every piece traces back to the scope it came from.

2 — Map the dependencies. For each item: what must exist before it can start, and who owns that thing. Mark every dependency internal or external. External ones — a vendor, an approval, another team — are listed by name, because they set the real critical path.

3 — Score what can be scored. Value is the outcome the item moves, taken from the input rather than from how strongly it is wanted. Effort comes only from the people who would do the work. An item missing either figure is marked unscored and carried forward; it is not given a number to make the list look complete.

4 — Place risk first. Identify the items that would invalidate the plan if their assumption turns out wrong. Schedule them into the earliest release that can carry them, ahead of higher-scoring but safer work, and write the reason next to them.

5 — Group into releases. Each release must be useful on its own. A group that only pays off once a later group lands is a milestone, not a release, and is labelled as one.

6 — Record the trade-offs. For each release: what was displaced to make room, who agreed, and when. Without this section a sequence cannot be reviewed, only argued about.

7 — Set the re-cut triggers. For each deferred item, the specific condition that would bring it forward. For the plan as a whole, the facts whose change would reorder it.

Output

release-plan.md, in this order:

1. Input and date — which scope this plan sequences, and when
2. Releases — per release: name, what it is for, the items in it, and whether it is independently useful
3. Dependency map — one line per dependency: item, what it needs, owner, internal or external
4. Critical path — the ordered chain that sets the earliest finish, with external links marked
5. Prioritisation — one line per item: value, effort, placement, and the reason; unscored items listed with what is needed to score them
6. Risk-first placements — items scheduled early against their score, each with the assumption they are there to test
7. Parked — deferred items, each with the condition that would bring it forward
8. Trade-offs — what was displaced, by what, agreed by whom, when
9. Re-cut triggers — the facts whose change reorders this plan
10. Missing information — what could not be scored or sequenced, and who can supply it

Validation

The plan is ready when all of these hold:

Every item in the input scope appears exactly once, in a release or under Parked
Every release states whether it is independently useful
Every external dependency names an owner outside the team
Every unscored item says what is needed to score it
Section 8 is non-empty whenever anything was deferred
No value or effort figure appears that did not come from an input

Fail the run if an input item is missing from the output, or if a number appears with no source.

Failure handling

No effort figures — produce the plan with every item unscored, sequence on dependencies and risk alone, and state in section 10 that the order is provisional until the work is sized.
No agreed outcome — stop. Report that prioritisation has no objective to optimise for; ordering without one is preference dressed as method.
Conflicting must-be-first demands — place the items by dependency and risk, record each stakeholder's position in section 8 with their name against it, and raise the conflict as a decision someone must make. Do not average them.
A dependency with no owner — list it as owner unknown in section 3 and as blocking in section 10. An unowned external dependency is the most common cause of a missed date.
Scope still open — sequence what is agreed, list the rest as pending scope, and mark the whole plan PROVISIONAL.

Download .md

Estimation & Risk Planning

Puts time, cost and confidence on a plan — and refuses to put a number on work nobody has looked at yet.

Deliverable

One Markdown document, estimate-and-risks.md, in the structure set out under Output below. It takes the output of Roadmapping & Prioritisation.

Required inputs

A work breakdown — the items to estimate. Sections 2 and 3 of release-plan.md are the expected form.
Who will do the work, at least by role. An estimate with nobody behind it is a wish.

Without both, stop. A number produced without the people who would deliver it has no owner and no meaning.

Optional inputs

Sizing from the people named above, in whatever unit they already use
Historical delivery data from comparable work
Rates or a budget ceiling, if cost is wanted and not only time
The review, testing, environment, release and approval process this work must pass through
Known external dependencies and their stated lead times

Where sizing is absent this skill produces the decomposition and the questions that must be answered before a number can exist. It does not produce the number.

Execution

1 — Split understood from unexplored. Every item goes on one of two lists. Work the team can describe end to end is estimable. Work that cannot yet be described is unexplored and receives a resolving action — a spike, a call, a document to read — not a figure.

2 — Decompose until the pieces are comparable. Anything still sized in months is a container for questions nobody has asked. Keep splitting until each piece can be argued about in a single conversation, or move it to unexplored.

3 — Estimate in ranges. For every estimable piece: a low, an expected and a high, all from the people who will do the work. Beside the range, one sentence saying what the distance between low and high is made of. A range with no stated driver is a wider guess, not an estimate.

4 — Add the work that is not writing code. Review, testing, data migration, environments, deployment, documentation, and the waiting — on access, on an approval, on someone else's release. Each gets its own line and its own range. Plans overrun here far more often than on the feature.

5 — Build the risk register. For each risk: what it is, how likely, what it costs if it lands, the early signal that it is starting, the response, and a named owner. A risk with no owner is an observation, and observations do not protect a date.

6 — Place the buffer where it protects the critical path. Buffer sits against the chain that sets the finish, not spread evenly over every task. State the confidence the buffered date carries and what would raise it.

7 — Set the re-forecast checkpoints. The dates or milestones at which estimate is compared with actual and the model — not the narrative — is corrected.

Output

estimate-and-risks.md, in this order:

1. Input and date — which plan is being estimated, by whom, and when
2. Estimable work — per piece: low, expected, high, the unit, who the figures came from, and the driver of the spread
3. Unexplored work — per item: why it cannot be estimated, the resolving action, and who owns it
4. Work that is not code — the same fields as section 2, listed separately so it cannot be quietly cut
5. Totals — the summed range, the confidence it carries, and the assumptions it rests on
6. Cost — only if rates were supplied; otherwise not estimated — no rates provided
7. Risk register — risk, likelihood, impact, early signal, response, owner
8. Critical path and buffer — the path, the buffer against it, and the date that buffer supports
9. Re-forecast checkpoints — when estimate meets actual, and who runs the comparison
10. Missing information — what blocked an estimate, and who can unblock it

Validation

The document is ready when all of these hold:

Every item in the input breakdown appears exactly once, in section 2, 3 or 4
Every range in sections 2 and 4 names the people the figures came from and the driver of the spread
No item appears in section 2 without a source for its numbers
Every risk in section 7 has a named owner and a response, not only a description
Section 5 states a confidence and what it assumes
Section 6 reads not estimated rather than a guess when rates were not supplied

Fail the run if any number has no source, or if a single-point figure appears where a range is required.

Failure handling

No sizing from the team — produce sections 1, 3, 4 as a checklist, 7 and 10. Deliver no totals. Report that the work has not been sized, and name who must size it.
A date is demanded before the work is understood — deliver the range for what is understood, the unexplored list beside it, and the confidence the demanded date actually carries. Never narrow a range to meet a date; narrow it by resolving an unknown.
No rates supplied — estimate time only and mark cost not estimated.
An earlier estimate was missed — record the original, the actual and the difference in section 9, and correct the model that produced it. Replace the estimate rather than defending it.
External lead times unknown — list them in section 10 as blocking and mark the totals EXCLUDES EXTERNAL WAIT. A total that silently omits a vendor's lead time is the most expensive kind of wrong.

Download .md

Stakeholder & Decision Rights Mapping

Establishes who decides, who must be consulted and who is only informed — before the work needs an answer and cannot get one.

Deliverable

One Markdown document, stakeholder-map.md, in the structure set out under Output below. It takes the approver and constraints recorded by Product Discovery & Scoping, and its decision rights are what lets a roadmap resolve a conflict instead of averaging it.

Required inputs

The decisions the work will face — the choices that must be made, even roughly stated. Without them this maps people to nothing.
The people or roles involved, as named by the requester.

If either is absent, stop and report it. Never assign a decision right from a job title alone: a title describes seniority, not authority over a particular choice.

Optional inputs

The organisation chart, and where this work sits in it
Prior decisions on the same subject and who made them
Budget authority and the thresholds attached to it
Regulatory, legal or contractual sign-offs the work requires
Known disagreements between the people involved

Each absent input becomes an entry under Open questions, never an inference.

Execution

1 — List the decisions, not the people. Start from the choices the work will face. A map built from people first produces a list of everyone's interests; a map built from decisions produces a list of who can unblock what.

2 — Assign one accountable person per decision. Exactly one, by name, or by role where the post is unfilled. Two accountable people is the same as none, and the map records that state as contested rather than splitting it.

3 — Separate consulted from informed. Consulted means their input changes the outcome and is sought before the decision. Informed means they are told afterwards. Treating the second as the first is where the schedule goes; treating the first as the second is where the rework comes from.

4 — Record each person's stake and their constraint. What they gain or lose from the decision, and what they cannot accept. A stake nobody has stated is left blank, not assumed from their function.

5 — Set an escalation path per decision. Where it goes when the accountable person cannot decide or is unavailable, and the elapsed time after which it escalates on its own. A path that ends in the team discusses it is not an escalation path.

6 — Find the gaps and the contests. Decisions with nobody accountable, decisions with more than one, people consulted on everything, and approvals whose holder is not in the room. Each is a blocker and is listed as one.

7 — Confirm it with the people on it. A rights map its own participants have not seen is a guess about authority. Record who confirmed their entry and when; unconfirmed entries stay marked as such.

Output

stakeholder-map.md, in this order:

1. Scope and date — which body of work this map covers, and when it was made
2. Decisions — one line each: the decision, who is accountable, who is consulted, who is informed
3. People — one line each: name or role, stake, stated constraint, and whether the entry is confirmed
4. Escalation — per decision: where it goes, to whom, and after how long
5. Approvals required — the sign-offs the work cannot proceed without, and who holds each
6. Contested and unowned — decisions with nobody accountable, or with more than one
7. Open questions — what could not be established, and who can establish it

Validation

The map is ready when all of these hold:

Every decision in section 2 has exactly one accountable person, or appears in section 6
No person is consulted on every decision — that records politeness, not authority
Every approval in section 5 names the person or role that holds it
Every escalation path in section 4 ends at a person or a role, never at a meeting
Every entry in section 3 is marked confirmed or unconfirmed; none is left blank

Fail the run if a decision has two accountable people and is not listed in section 6, or if any right was inferred from a job title rather than stated by someone.

Failure handling

No list of decisions — stop. Report that there is nothing to map rights over, and ask for the choices the work will face.
A decision nobody in the organisation owns — record it in section 6 as unowned and raise it as the first thing the work needs. Do not estimate against a decision that has no owner.
Two people both claim a decision — record both in section 6 with what each claims, and name who is senior to both. Do not resolve it in the document; the document's job is to make it visible.
Participants will not confirm — deliver the map with those entries marked unconfirmed, and state plainly that an unconfirmed right is a prediction about authority rather than a record of it.
Partial material — map the decisions the material supports, list the rest under open questions, and mark the map INCOMPLETE.

Download .md

Build, Buy or Partner Analysis

Decides whether a capability should be built, bought or obtained through a partner — against criteria the requester set, not criteria the analysis chose once it knew the answer.

Deliverable

One Markdown document, build-buy-partner.md, in the structure set out under Output below. It takes a scoped capability from Product Discovery & Scoping, and its recommendation is a decision worth preserving as a decision record.

Required inputs

The capability, scoped — what it must do, for whom, and the outcome it serves.
The criteria that decide it, with their weights, set by the requester: cost, time, control, differentiation, risk, exit — whichever apply here.

Without stated criteria, stop. An analysis that picks its own criteria after seeing the options is a justification, not a decision.

Optional inputs

Candidate vendors or partners already under consideration
Internal capacity and the skills actually available, as stated by the requester
Pricing, quotes or contract terms the requester has obtained
Regulatory, data-residency or procurement constraints
What the capability costs today, if it exists in some form already

Absent inputs are recorded as unknown against the option they affect. No figure is estimated on the requester's behalf.

Execution

1 — Establish whether this is differentiating. A capability customers choose you for is a candidate to build. One they expect to exist and never compare is a candidate to buy. Record which this is and the reasoning: it sets the weight of everything that follows.

2 — Define the three options concretely. Not build but what would be built, by whom, to what scope. Not buy but which class of product, and which named candidates if the requester has any. An option that cannot be described cannot be compared.

3 — Cost each option over its life, not at purchase. Building carries maintenance, support duty and the opportunity cost of the people doing it. Buying carries licence, integration and the price of growth. Partnering carries management overhead and margin. Every figure comes from the requester or a document they supplied; a cost nobody has provided is unknown and the option carries it as a risk, never as a number.

4 — Score against the stated criteria. Use the requester's weights, not a fresh set. Where evidence is missing the cell is unscored and is reported as such; it is never filled with a judgement to complete the table.

5 — Cost the exit. For each option, what leaving it would take: data portability, contract term, switching cost, the code or knowledge that would be lost. The cheapest option to enter is often the most expensive to leave, and that only becomes visible here.

6 — Name what would change the answer. The specific fact that, if it were different, would flip the recommendation. If no such fact exists the decision is robust; if a small one flips it, the decision is close and is recorded as close.

7 — Recommend, with the case against it. One recommendation, its reasoning, and the strongest argument against it stated fairly. A recommendation with no stated downside has not been tested.

Output

build-buy-partner.md, in this order:

1. Capability and date — what is being decided, for whom, and when
2. Differentiation — whether this is something to compete on, and the reasoning
3. Options — each described concretely enough to be costed
4. Criteria and weights — as supplied by the requester, with their source
5. Cost over life — per option, each figure with its source, unknown where none was supplied
6. Scoring — per option per criterion, with the unscored cells listed and what would score them
7. Exit cost — per option: what leaving would take
8. Recommendation — the option, the reasoning, and the strongest case against it
9. What would change this — the facts that would flip the recommendation
10. Missing information — what could not be established, and who can supply it

Validation

The analysis is ready when all of these hold:

Every criterion in section 4 carries a weight, and the weights came from the requester
Every cost figure in section 5 carries a source, or reads unknown
Every option has an exit cost in section 7, including the option to build
Section 8 states a case against its own recommendation
Section 9 is non-empty, or the recommendation is stated as insensitive to any single fact
No vendor, price or capability is asserted that the requester did not supply

Fail the run if a figure appears with no source, or if the criteria were set after the options were known.

Failure handling

No criteria supplied — stop. Report that the decision has no basis yet, and hand back the list of criteria the requester must weight.
No pricing for a bought or partnered option — score every other criterion, mark cost unknown, and state that the recommendation cannot be final until pricing exists. Never model a price.
Only one option is genuinely available — say so plainly, document why the others are closed, and record the decision as forced rather than presenting a comparison that was never real.
The requester wants a particular answer — run the analysis on the stated criteria regardless. Where the result contradicts the preference, record both, and let the decision record carry the difference.
Partial material — analyse what the material supports, mark the rest INCOMPLETE — pending <question>, and deliver.

Download .md