Classify Ideas by Risk, Scope, and Time–Cost Caps

Good to see you again. In Phase 0, you screened an idea for legal and regulatory triggers, foreseeable harm, and pre-existing commitments. That screen may already have forced an idea into Lane L because of regulated data, consequential decisions, safety concerns, or a licence constraint. It may also have marked the run COMMITTED, which changes what later validation can decide but does not remove risk, scope, or quality controls.

This lesson makes the investment boundary explicit. You will learn to assign a run to Lane S, M, or L based on risk and scope, then record a time cap and money cap that make the assignment enforceable. The purpose is not to predict every detail. It is to decide, before work expands, how much uncertainty this particular idea is allowed to consume.

---

Lanes are controlled bets, not labels

A lane answers one operational question:

Given the downside if we are wrong, how much process and investment is justified before a launch decision?

Without lanes, every idea tends toward one of two failures:

• A small improvement receives a full discovery and documentation programme, so people eventually bypass the process.
• A consequential or technically uncertain product is treated as a quick experiment, so its risks are discovered after commitments and costs have grown.

The Product Factory therefore has three lanes:

Lane	Intended use	Required path	Time boundary
Lane S — Spike	Improvement, small feature, obvious fix	Phases 0, 1, 10, 11, and 12–17	One week to launch decision
Lane M — Bet	A standard new product or capability	All phases	Six weeks to launch decision
Lane L — Programme	Regulated, irreversible, or above the organisation’s defined materiality threshold	All phases plus a risk register	Explicitly set in Phase 1; reviewed monthly

A lane is not a claim that an idea will succeed. It is a precommitment about exposure: how much time, money, and process complexity the organisation is willing to spend to find out.

Two distinctions prevent confusion:

1. Lane and commitment status are different fields.
   An idea can be uncommitted and Lane L because it affects employment decisions. It can also be committed and Lane S if a contract obliges a small, low-risk enhancement.

2. Lane L is not the “important ideas” lane.
   It is the lane for a different risk profile: material regulatory exposure, irreversibility, safety implications, high financial stakes, or organisational consequences that cannot responsibly be handled as a short spike.

---

The three inputs to lane assignment

Lane selection depends on risk, scope, and reversibility. Use them together rather than relying on a vague impression that an idea is “big.”

1. Risk: what happens if the product is wrong?

Risk concerns the severity and nature of a bad outcome, not merely the probability that the idea will fail commercially. Ask:

• Could the product affect health, safety, finances, employment, education, housing, legal status, or access to essential services?
• Does it process regulated, sensitive, biometric, children’s, financial, or health-related data?
• Could it create material harm even if it works as designed?
• Does it create a security, legal, contractual, or reputational exposure that requires a formal risk register?
• Would failure impose significant costs on people who did not choose the product?

A Phase 0 trigger is decisive: where the intake screen identifies regulated data, safety-critical decisions, or a relevant licence constraint, the run routes to Lane L before further work. The team should not use a small expected build cost to downgrade a consequential decision.

2. Scope: how much change is actually being proposed?

Scope means more than feature count. A two-screen feature that changes pricing, permissions, data retention, or a core workflow may have broader scope than a ten-screen internal tool.

Consider:

• Affected users: a small, known group or a large and diverse population?
• System surface: one isolated workflow or several systems, integrations, teams, and data sources?
• Operational change: can an existing team support it, or does it require training, policy, new support capacity, or new suppliers?
• Technical uncertainty: is it a familiar implementation, or does it depend on an untested technical capability?
• Financial exposure: can the work fit within the pre-agreed cap, including external tools, research incentives, build, and operating costs?

Scope alone does not automatically produce Lane L. A broad but low-risk opportunity may be Lane M. But scope determines whether the proposed work can genuinely fit the short Lane S boundary.

3. Reversibility: can you safely undo the decision?

Reversibility is the tie-breaker many teams neglect. Ask:

If this goes badly, can we stop it, roll it back, and make affected people whole at modest cost?

A disposable internal report that can be switched off is highly reversible. A public product that changes records, establishes a customer expectation, enters a contract, or trains people around a new workflow is less reversible. Low reversibility pushes an idea toward Lane L, even if the first release seems narrow.

---

The project-constraints triangle captures a basic but important reality: scope, time, and cost are interdependent. In this factory, the lane principally fixes the permissible time and money. Scope is the variable the team must reduce when estimates do not fit.

That is why a lane cap is not merely a target. It is the mechanism that forces the product to become a testable thin slice rather than a full imagined solution.

---

How to choose S, M, or L

Use the following classification logic at Phase 1, after Phase 0 has established whether the idea is admissible.

Lane S: a bounded spike

Choose Lane S when the idea is a small improvement, a contained feature, or an obvious fix with limited consequences. It should have a narrow user group, familiar technology, modest operational change, and a credible way to undo it.

Lane S does not mean “skip thinking.” It preserves the critical safeguards:

• Phase 0 still screens legal, harm, and commitment conditions.
• Phase 1 still requires a problem statement, named sufferer, falsifier, alternatives, and caps.
• Build and real-user validation still occur.
• Launch preparation, observation, product decisions, and calibration still apply.

What Lane S omits is the extended discovery machinery of a standard product bet. Its evidence bar at Phase 3 is three relevant conversations rather than twelve.

Example: An internal operations team already uses a shared spreadsheet to track support escalations. The proposal is an automated reminder for tickets that have had no owner for 48 hours. It affects a known internal group, uses existing ticket data, does not decide anything about customers, can be disabled easily, and can be built within the agreed one-week boundary. This is a credible Lane S candidate.

A warning: “small feature” is not the same as “small risk.” An automated reminder about overdue invoices may be small; an automated system that blocks a customer’s service because of an overdue invoice is not necessarily small, because the consequence changes.

Lane M: the default product bet

Choose Lane M for a standard new product or capability that is meaningful enough to require deliberate evidence but does not have the risk or irreversibility of a programme.

Lane M is usually appropriate when:

• the problem and customer are plausible but not yet validated;
• the solution requires a defined MVP rather than a tiny change;
• some technical, commercial, or distribution uncertainty exists;
• the product can be tested, released, and potentially retired without disproportionate harm;
• no Phase 0 condition requires Lane L.

The Lane M default gives the run a total six-week time-box to the launch decision, divided in the standard process as follows:

Period	Main purpose	Default allocation
Phase 0	Intake screen	2 hours
Phases 1–2	Frame problem, alternatives, falsifier, lane	1 day
Phases 3–6	Validate problem and test the hardest uncertainty	5 days
Phases 7–9	Define strategy, MVP, measurement, and design	3 days
Phases 10–11	Build and validate a working MVP	3 weeks
Phases 12–13	Prepare and make the launch decision	Remainder of the six-week cap

These allocations are starting assumptions, not universal laws. The important rule is that a Lane M run has one bounded end date established at the start, rather than a sequence of individually reasonable extensions.

Lane L: a governed programme

Choose Lane L if Phase 0 revealed a relevant regulatory, data, safety, licence, or serious-harm trigger. Also choose it when the proposed bet exceeds the organisation’s pre-defined materiality threshold or has consequences that are difficult to reverse.

Lane L adds a risk register and requires an explicit time and money cap in Phase 1, with monthly review. It is not unbounded. “Programme” must never become a polite word for “we have stopped counting.”

Typical Lane L signals include:

Signal	Why it matters
Health, financial, biometric, children’s, or similarly regulated data	The product may be subject to heightened legal, security, and governance obligations
Safety-critical recommendation or action	A failure may injure people or create a serious physical risk
Consequential decision affecting people’s opportunities	Errors, bias, opacity, and recourse mechanisms can be material
Irreversible change to critical records or infrastructure	Rollback may be expensive, incomplete, or impossible
Material contractual, financial, or reputational exposure	A bad decision may create liabilities beyond the delivery team
Work over the organisation’s Lane L threshold	The cost or strategic commitment justifies programme-level governance

Example: A product that recommends which employees receive leadership-development opportunities may initially be a modest prototype. Yet it uses employee data and influences access to career opportunities. The appropriate classification is Lane L, because the risk profile, not prototype size, determines the governance level.

---

Time-boxing is a decision boundary

The timebox image below contains the principle in its starkest form: work ends when the box ends. In product work, this does not mean pretending that the desired scope is complete. It means facing the evidence that the scope did not fit.

A time cap has three jobs:

1. It prevents endless discovery. There is always one more competitor to study, interview to run, or hypothesis to investigate.
2. It exposes untested assumptions early. If essential evidence cannot be gathered within the lane, the bet may be too broad or too weakly framed.
3. It protects capacity for other opportunities. A portfolio learns by running multiple bounded bets, including bets that stop cheaply.

Watch this short section of Product Pathways’ How to Kick Off Product Discovery Like a Pro. It explains why discovery needs a visible time boundary and why uncertainty and risk should influence the amount of discovery effort.

The video’s core diagnosis aligns with the factory: risk and confidence should shape effort, and a weak idea may be stopped before the time expires. The factory is intentionally stricter about overruns, however. Rather than granting more research by default after a cap expires, it requires one of three explicit moves:

• Reduce scope so the work fits the existing lane.
• Stop the run and log why it did not clear its gate.
• Begin a new run only if something materially changed, with new caps and a new record.

This difference matters. A new time-box can be reasonable in ordinary discovery practice; in this Product Factory, it must be a new decision, not an automatic continuation that hides an overrun.

---

Money caps make the lane real

A time cap without a money cap can still permit uncontrolled investment through contractors, tools, incentives, cloud consumption, or internal opportunity cost. Conversely, a money cap without a time cap can let a project consume scarce attention indefinitely.

The standard specifies the structure of caps, but it does not provide universal currency values. Your organisation must supply them before work begins. Do not write “within budget”; write an amount, a currency, what it includes, and who may approve spend.

For each lane, establish a policy such as:

Lane	Time cap	Money cap	Who may change it?
S	1 week to launch decision	A pre-set small-spend amount	Named gate-decider; only through a new run or explicit policy exception
M	6 weeks to launch decision	A pre-set bet amount	Named gate-decider; no extension through informal approval
L	Explicit end date, reviewed monthly	Explicit programme budget with review points	Designated programme authority under risk governance

The specific amounts depend on context. For an independent maker, a Lane S cap might cover a limited number of research incentives and basic infrastructure. For an enterprise, it may include allocated staff days, procurement, security review, and external expertise. What does not vary is the requirement that the figure is known before the work judged by it begins.

A usable money cap should include:

• direct spending, such as software, cloud usage, research incentives, contractors, and external advice;
• internal effort, whether recorded as person-days, a cost estimate, or both;
• a statement of exclusions, if any;
• the spending authority;
• the action if the cap would be exceeded.

If internal effort is excluded from the financial figure, record it separately. Otherwise a team can report that a project cost little while consuming hundreds of hours.

The cap rule

When the build estimate exceeds the lane cap, do not stretch the lane merely to preserve the original concept. Cut scope and reassess.

For example, suppose a Lane M product concept includes five workflows, three integrations, role-based permissions, billing, a mobile interface, and an analytics dashboard. The estimate exceeds the Lane M cap. The correct response is not “this is really a seven-week Lane M.” The team should identify the smallest core journey and remove or defer the rest. If no credible thin slice fits, the run either belongs in Lane L with an explicitly renewed mandate, or it should stop.

---

Record the decision so it can be challenged later

A lane assignment should fit in the Idea Record and be reflected in the append-only Decision Log. The record needs to preserve what was known at the time, including assumptions, rather than retrospectively making the decision look inevitable.

Idea Record: lane section

Lane assignment

Proposed lane: S / M / L

Risk basis:
- Phase 0 triggers: [source or assumption tag]
- Harm and reversibility: [source or assumption tag]
- Regulatory or contractual considerations: [source or assumption tag]

Scope basis:
- Affected users:
- Systems and integrations:
- Operational change:
- Hardest unknown:
- Build estimate basis:

Time cap:
- Start date:
- Launch-decision date:
- Phase allocations, if applicable:

Money cap:
- Currency and maximum amount:
- Includes:
- Internal effort recorded as:
- Exclusions:
- Spend authority:

Overrun action:
- Reduce scope / STOP / initiate a new run under an approved lane

Decision rationale:
Owner:
Challenger:
Gate-decider:
Date:

Decision Log: one append-only entry

The Decision Log captures not merely the selected lane but the competing reasoning. The Challenger’s STOP case comes first.

Field	Example
Gate	Phase 1, lane assigned
Threshold	Lane M permitted only when no Phase 0 Lane L trigger exists and work fits stated caps
Actual figures	6-week cap; £X cap; estimated build effort Y; 0 regulated-data triggers identified
STOP case	The integrations may make a thin slice impossible inside the cap
PROCEED case	One workflow and one integration can test the core hypothesis within the cap
Decision	Lane M, subject to reduced MVP scope
Decider	Named person
Date	Decision date
Provenance	Tags for each material claim

This record lets Phase 17 eventually ask whether lane assignment was predictive. If Lane M work routinely exceeds its cap because integrations were systematically underestimated, the problem may not be individual estimation discipline. It may be that the factory’s lane policy or intake questions need revision.

---

A concise decision protocol

When assigning a lane, work through these questions in order:

1. Did Phase 0 force Lane L?
   If there is a regulated-data, safety, serious-harm, licence, or similarly material trigger, assign Lane L. Do not downgrade because the proposed first release seems small.

2. Can the product be safely tested as a small, reversible change?
   If yes, and it fits the organisation’s Lane S time and money caps, assign Lane S.

3. Is this a standard but meaningful product bet?
   If it needs structured validation and an MVP but remains reversible and within standard caps, assign Lane M.

4. Does the scope or financial exposure exceed the policy threshold?
   If yes, assign Lane L and set explicit programme caps and review points.

5. Can the team state a credible cap today?
   If no, the lane assignment is incomplete. The uncertainty may itself be the hardest unknown to test. Do not disguise an unknown cap with an optimistic number.

6. What happens if the cap is reached?
   Record the answer now: scope reduction, stop, or a genuinely new run. “Ask for more time” is not a default outcome.

---

The key idea is simple: the lane fixes the size of the bet; scope must earn its place within it. Lane S is for contained and reversible spikes, Lane M for bounded standard product bets, and Lane L for consequential, regulated, irreversible, or materially large programmes. A Phase 0 risk trigger automatically routes an idea to Lane L, while commitment status remains a separate classification.

Record both time and money caps before substantive work begins, including what they cover and what happens on overrun. That record turns a lane from a descriptive label into an enforceable decision boundary.

Next, you will define the people who make this discipline credible: the Owner, Challenger, Factory Keeper, and gate-decider, including the safeguards needed when you are working solo.