Product · Decision guide
Compare keeping the roadmap, a narrow improvement to one measured problem, a broader capability, and a reversible prototype — in design and engineering hours, calendar weeks, maintenance and what each commits you to.
Every path against today — select one to see exactly what changes
The broader capability needs roughly four times the engineering hours and more than twice the calendar time of the narrow improvement under the default inputs, and it keeps costing more in maintenance afterwards. Neither number says which creates more value — that depends on evidence the prototype path is designed to collect.
Who this is for Product leads and founders deciding where a small team's next quarter of design and engineering goes.
Optional. Answers decide which paths meet your hard constraints; "not sure" keeps a requirement unresolved instead of guessing.
Your current approach, the alternatives and a smaller reversible pilot — all with the same inputs and horizon.
Current approach
No new investment; the team continues the work already planned.
Main uncertainty: The cost of waiting is not modelled.
Alternative
Pick one measured problem, frame it, interview a few customers, design and ship the smallest fix, and measure it.
Main uncertainty: Whether the chosen metric moves; other changes can move it too.
Alternative
Research, design and build a larger capability over most of the quarter, with a beta before general release.
Main uncertainty: Demand for the capability and the accuracy of the estimate.
Smaller reversible pilot
Build a throwaway prototype of the broad idea's riskiest part and test it with customers before committing the quarter.
Main uncertainty: How well reactions to a prototype predict real use.
Person-hours are everyone's effort added up, not calendar time. Valued staff time is hours × the value of an hour: an economic cost, not a bill.
| Path | Setup effort | Ongoing effort per week | Setup cash | Ongoing cash per month | Cash over the horizon | Incl. valued staff time | Weeks to go live |
|---|---|---|---|---|---|---|---|
| Keep the current roadmap | 0 h | 1 h | $0 | $0 | $0 | $2,160 | now |
| Narrow improvement to one measured problem | 168 h | 1.92 h | $0 | $0 | $0 | $16,206 | 9 |
| Broader new capability | 648 h | 3.68 h | $0 | $0 | $0 | $53,902 | 20 |
| Pilot: a reversible prototype test | 57 h | 0 h | $0 | $0 | $0 | $4,560 | 5 |
Horizon: 6 months. Change the assumptions, compare any path with your current approach, combine steps and export a plan with the interactive tool (JavaScript).
Product · every week from week 1 · 1 h / week
Gains: No disruption; Commitments kept
Sacrifices: The new opportunity waits; Problems you already know about persist
Must be true: The roadmap still reflects what customers need most
Product · weeks 1–1 · 6 h
Product · weeks 1–2 · 12 h
Design · weeks 3–4 · 24 h
Engineering · weeks 5–8 · 120 h
Engineering · weeks 9–9 · 6 h
Product · every week from week 10 · 1 h / week
Engineering · every week from week 10 · 0.92 h / week
Gains: Fast to ship and to learn from; Low maintenance; Clear before / after metric
Sacrifices: Bigger opportunities wait; Gains may be small
Must be true: The metric reflects something customers value; The fix is small enough for one cycle
Product · weeks 1–1 · 12 h
Product · weeks 1–2 · 24 h
Design · weeks 3–6 · 80 h
Engineering · weeks 3–4 · 24 h
Engineering · weeks 7–18 · 480 h
Product · weeks 19–20 · 16 h
Support · weeks 19–19 · 12 h
Engineering · every week from week 21 · 3.68 h / week
Gains: Can open a new use or segment; Bigger change for customers
Sacrifices: Most of the quarter's engineering; Higher maintenance for good; Late feedback
Must be true: The engineering estimate holds within the range; Customers adopt it once released
Product · weeks 1–1 · 3 h
Design · weeks 2–3 · 40 h
Product · weeks 4–4 · 12 h
Product · weeks 5–5 · 2 h
Gains: Evidence in five weeks; Small cost; Nothing to maintain
Sacrifices: A prototype is not the product; Delays the full build by a few weeks
Must be true: Test participants resemble the target customers
This comparison is deliberately mostly qualitative. It counts what can be counted — design, engineering and research hours, weeks to release, and maintenance after launch — and lists everything else as trade-offs, requirements and things that must be true.
It does not assign revenue, retention or speed gains to either option. If you have evidence of value (customer requests, usage data, lost deals), record it in the assumptions and in your Decision Passport; the tool keeps it separate from the calculated effort.
The Company plan is where this decision usually matters most: a broad build often collides with engineering hours already committed to pricing, billing or support work in the same quarter.
If the team cannot name the customer problem or the metric either option should move, spend the time on discovery instead. If key engineers are already overcommitted, no new investment is realistic until something else stops.
Specific, dated practices — not whole-company models. Paths marked as an adaptation are WeCaseStudy's adaptation for your context, not a claim that the company used this exact workflow.
Calculations: formula family steps, version 1. Decision version 1. How the numbers are made
