Decision Framework: Signal → Standard → Speed

“One path for everything is no path at all.”

Every idea, request, or problem that reaches the product team needs an answer to one question: what’s the right path for this work?

Not everything needs an RFC. Not everything is a quick win. Match the path to the size and risk. Don’t force everything through the same process.

Three Paths

	Quick Win	Lightweight	Full Spec
Size	≤ half a day of engineering	Half a day – 2 weeks	> 2 weeks
Process	Flag with Tech Lead/PM, then ship	1-page brief	Full RFC
Approval	Tech Lead/PM alignment	PM + Tech Lead	Head of Product sign-off
Documentation	Changelog if UX. Support notification always.	Problem, Solution, Acceptance Criteria, Metrics, Persona	RFC (template), RICE score
Feature flag	Optional	Yes	Yes
Post-launch review	No	2-week check-in	2wk / 30d / 90d reviews

The Decision Tree

Start here when any work arrives, whether from customer feedback, an engineer’s idea, a sales request, or your own discovery.

Step 1: Signal

This “Signal” (a reason to build) is distinct from an outcome’s Signal in the Product Vision and Product Spec, which is the metric that tells you a named outcome is holding. Here it means demand and evidence; there it means the measurable driver of the North Star.

Does this work have a reason to exist right now?

Strategy-aligned? Does it connect to a current strategic lever?
Validated need? Is there evidence beyond one person’s opinion? (Customer feedback, usage data, support tickets, competitive gap)
What happens if we don’t? If the answer is “nothing,” question whether this is the right use of engineering time.

If Signal is weak, park it. Capture the idea in your issue tracker with context. Don’t invest further until the evidence strengthens.

Step 2: Standard

Does the proposed approach pass each of your product principles? Run the check questions for each principle against the proposed solution.

If Standard fails, redesign the approach before you spend engineering time. A fast solution that breaks the principles just creates more work later.

Step 3: Speed

How big is the work? This determines the path.

≤ half a day → Quick Win Flag it with your Tech Lead or PM. If it aligns with the team’s current priorities, get on with it. No RFC needed, but use judgement: each team has a limited budget for Quick Wins per sprint so we stay focused on strategic work. Changelog if it changes UX. Always notify support. Tag it quick-win in your tracker.

Half a day – 2 weeks → Lightweight Write a 1-page brief (see template below). Get PM + Tech Lead sign-off. Ship behind a feature flag. Do a 2-week check-in after launch.

> 2 weeks → Full Spec Write a full RFC with a RICE score. Get Head of Product sign-off. Follow the full delivery process. The RFC references the relevant Job Spec, the durable outcome contract that outlives this initiative.

Lightweight Brief Template

Use this for work between half a day and 2 weeks. One page. No fluff.

## [Title]

**Persona:** User / Admin / Sponsor
**Size:** [estimated days]
**Approved by:** [PM name] + [Tech Lead name]

### Problem
[2-3 sentences. Who has this problem? When? What's the evidence?]

### Solution
[What we're building. Keep it concrete.]

### Acceptance Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]

### Metrics
[How we'll know it worked. 1-2 metrics with baselines.]

### Vision Check
How does this move a named outcome (and its signal) from the [product vision](../anchors/product-vision.md)?

Examples

Generic illustrations: the shape of each path, not a specification of yours.

Quick Win: Clearer error message on a common failure

Signal: 12 support tickets in the last month. Customers see a generic failure message with no actionable explanation. Standard: Passes all principles. The current error message violates the “self-teaching” standard. Speed: 3 hours of engineering. One error string and a link to a relevant settings page. Path: Quick Win. Ship it. Changelog entry. Support notified.

Lightweight: Template gallery for a common setup

Signal: Admins spend 2–3 hours setting up patterns every team needs. 5 customer interviews confirm this. Strategy lever: Acquisition / faster time-to-first-value. Standard: Batteries included: templates should give admins a running start. Speed: ~1 week of engineering. New UI surface with 5–10 curated templates. Path: Lightweight brief. PM + Tech Lead approve. Ship behind flag. 2-week check-in.

Full Spec: New native capability replacing a third-party tool

Signal: Top-3 deal blocker. 15 deal opportunities waiting on the native capability. Strategy lever: Expansion. RICE Grade B. Standard: Must feel like part of the core product, not a bolted-on module. Speed: ~2 months of engineering. New data flow, UI surfaces, API endpoints. Path: Full Spec. RICE scored. Head of Product approval. RFC. Full delivery process.

Common Questions

What if I’m not sure about the size? Talk to your Tech Lead in the weekly scoping session. Sizing is a 5-minute conversation, not a week of analysis. If the Tech Lead says “I’m not sure,” it’s usually bigger than a lightweight, so write the RFC.

What about urgent customer issues? Urgent doesn’t change the path, it changes the priority. A 3-day fix for a churning customer is still a Lightweight brief, it just goes to the top of the queue. The PM + Tech Lead approve same-day. Escalate to the Head of Product if needed.

What about platform/infrastructure work? Same three paths. Tech debt, reliability improvements, and dependency upgrades run through the same decision tree. The evidence is different (incidents, performance data, security advisories instead of customer interviews), but Signal → Standard → Speed still applies.

Can a Quick Win grow into a Lightweight? Yes. If you start a Quick Win and realise it’s bigger than expected, stop and write the brief. Don’t scope-creep a Quick Win into an undocumented 5-day project.

Who decides which path? The PM, informed by the Tech Lead’s sizing. If there’s disagreement, the PM decides the path. It’s a process decision, not a technical one. If the Tech Lead thinks the PM is under-sizing, have that conversation before committing.

Product Loop: The 6-phase operating model (this framework is Phase 2: DECIDE)
Product Vision: Vision and personas
Product Spec: Where the outcomes and their Signals live, the success measures a Vision Check reads against
RFC Guide: Full Spec path guidance (writing a ship-coupled RFC)
RICE Assessment: Scoring for Full Spec path
Product Analytics: expressing impact in Signal terms

Strategic Buckets

Strategy decides which buckets get capacity. RICE decides priority within those buckets. Strategy drives allocation, not RICE gaming.

Each bucket gets a capacity allocation (e.g., 40% Growth, 30% Enterprise, 20% Platform, 10% DX). Buckets and allocations come from your annual strategy document, revisited at least yearly.

RICE Scoring

RICE = (Reach + Impact + Confidence) / Effort. Score 1–4 for value dimensions, 1–5 for effort. Grades A through D. See RICE Assessment for scoring details.

Key rules:

Update RICE after scoping: effort estimates change. Re-score.
Don’t optimise for RICE: optimise for strategy, then let RICE rank within it.
Kill low-confidence work: if Confidence is 1, do more discovery first.
Revisit deferred items quarterly: priorities move.

Full guide: RICE Prioritisation