Which tool approach fits our needs, and where is a useful product gap?
Start with a lightweight decision workspace for the two-hub launch. Its supplied scores favour exceptions, learning and coordination at moderate operating burden. Keep a separately checked schedule alongside it: a forecast score of 3 is a material weakness for a 12-week launch. If strong forecasting must live in the primary tool, the scheduling specialist is the better admissible starting point under the default burden ceiling.
The useful product hypothesis is a small bridge between schedule changes, accountable decisions and reusable evidence. These five fictional archetypes suggest a tension; they do not prove a market gap or demand for a new product.
Fictional what-if workspace. Changes stay in this tab and reset on reload; no record is saved and no external system is changed.
1. Compare the same evidence
The six supplied dimensions are authored 1–5 scores. Higher is better for the five capabilities; lower is better for operating burden. “Integration” means broad coordination capability here, not a demonstrated connector or API. “Cadence” is interpreted as support for recurring operating review; the fixture does not define either dimension more precisely.
Benchmark v1.0 · taskFixtures.toolArchetypes · all five records, unchanged
Approach and trade-off
Integration
Forecast
Exceptions
Learning
Cadence
Burden ↓
Task boardLowest burden; weak forecasting and learning. Useful for action visibility, insufficient as the sole launch control.
2
1
3
1
4
1
Scheduling specialistStrongest forecast; weak learning and cadence. Good schedule core, with decision evidence kept separately.
3
5
3
1
2
3
Integrated project suiteBroad capabilities; highest burden. Attractive only if administration and adoption capacity are available.
5
4
4
3
4
5
Knowledge libraryStrongest learning; weak forecasting and exception handling. A supporting source store, not a launch-control centre.
2
1
2
5
2
2
Lightweight decision workspaceStrong exceptions and learning at moderate burden; forecast depth remains unproven.
4
3
5
4
4
3
Scores are neither measured outcomes nor prices. No vendor products, licensing, security, interoperability or implementation costs were supplied. Combining two archetypes would add handoff and administration costs; their scores cannot simply be added.
2. Make the trade-off explicit
Choose a working emphasis, then change its priorities. Capability floors and a burden ceiling screen approaches before scoring. A high weighted score cannot override those requirements.
Simulated fit · no procurement or approval
Calculation, assumptions and interpretation
Eligibility: burden ≤ selected ceiling AND forecast ≥ selected floor.
Weighted capability = Σ(priority × capability score) / Σ(priorities).
Capability index = 100 × (weighted capability − 1) / 4.
Preference score = capability index − penalty × (burden − 1).
Ties within 0.05 points are reported as ties; no automatic winner is forced.
The index treats the supplied ordinal scores as equally spaced, and lets one capability compensate for another. Those are decision-aid assumptions, not facts about tools. Preference scores can be negative and are not percentages of success. The bars show only non-negative points, with exact values alongside.
Default priorities 3 / 3 / 4 / 2 / 2 and a burden ceiling of 3 reflect a small six-person launch team sharing equipment, safety assurance and supplier dependencies. They are authored assumptions. The £240,000 launch cap does not establish a tooling allowance; no licence or labour cost is inferred from a burden score.
Before selection, demonstrate shared-staff and equipment constraints, dependency changes, decision authority, evidence provenance, exports and recovery from an interrupted update. Safety approval remains with the responsible person, regardless of the tool score. Agree one owner for the schedule, one source of decision status and a reconciliation routine if separate tools are used.
3. Three product hypotheses worth testing
Each hypothesis addresses the same launch, with a distinct user job. All targets below are proposed pilot criteria; there are no measured user results in the fixtures. Start with the decision receipt bridge, which needs less speculative scheduling capability. Stop if existing tools complete the job equally well at lower total effort.
H1 · First experiment
Decision receipt bridge
User story: As the hub lead, when a supplier change affects both hubs, I want one decision tied to its evidence, owner and authority so the next review can understand what changed and why.
Hypothesis: A small decision layer can preserve provenance and a find/reopen/correct path without the suite’s operating burden. The workspace scores exceptions 5 and learning 4; the task board scores 3 and 1.
Test: Ten seeded supplier-change decisions across both hubs. A successful case creates a complete receipt, is found after reload, and is corrected without concealing history.
At least 9/10 complete cases.
Zero simulated approvals misrepresented as authorised.
Median complete-loop time ≤3 minutes.
Include a rejected approval, stale evidence and interrupted-save/retry case. Stop if users still need a parallel decision log.
H2 · Forecast connection
Constraint-to-decision handoff
User story: As the launch planner, when one hub slips, I want a checked impact on shared staff and equipment beside the decision options so I can propose a feasible response.
Hypothesis: A thin handoff to a schedule engine can close the workspace’s forecast weakness. The specialist scores forecast 5 but learning 1; the workspace scores 3 and 4.
Test: Ten perturbations independently calculated from a resource-constrained reference schedule. A successful case identifies changed dates, conflicts, assumptions and affected decisions.
At least 9/10 reference-matching cases.
Zero infeasible plans marked feasible.
Median complete-loop time ≤5 minutes.
Include overallocated staff, late equipment and an unavailable source. Stop if duplicate schedules drift or assumptions are hidden.
H3 · Learning in context
Evidence-linked lesson recall
User story: As a South hub reviewer, I want a relevant North hub lesson with its original context and outcome so I can judge whether to reuse it in the next decision.
Hypothesis: Contextual recall inside the review may outperform opening a separate library. The library scores learning 5 but exceptions 2 and cadence 2.
Test: Ten decisions with a blind relevance key, including three with no applicable lesson. A successful case retrieves the right source or correctly abstains, states the context mismatch, and links the reuse rationale.
At least 8/10 correctly handled cases.
Zero fabricated or misattributed sources.
Median complete-loop time ≤4 minutes.
Include a superseded lesson and conflicting outcomes. Stop if irrelevant recall slows the review or users cannot inspect sources.
How to evaluate usefulness, rather than just feature presence
Run each candidate against the team’s current method on the same synthetic cases, counterbalance the order, and count setup, maintenance and correction effort as well as task time. Record time by role, completions, critical errors, failures to reopen and participant explanations. A technical pass permits a bounded usability trial; it does not establish willingness to adopt, value for money, security suitability or a market gap. Interview both hub leads and an assurance owner about missing decisions and duplicate work before committing to build.
4. Rehearse a pilot decision
Enter imagined results to see how the proposed rules behave. This checker does not run a product trial and cannot verify entered evidence. A “meets criteria” result is only a scenario verdict.
No pilot scenario assessed
Choose a hypothesis and enter imagined results. Nothing has been tested, saved or approved.
Evidence and boundaries
The case is Repair & Reuse: two-hub launch, benchmark 1.0.0: two hubs, six cross-trained staff, 12 weeks and £240,000. The only comparative evidence is the five toolArchetypes records reproduced above. There are no supplier quotes, field observations, connector tests or customer interviews. Detailed archetype trade-offs are interpretations of the scores.
Selection controls reveal how preferences change the shortlist. They cannot establish tool availability, schedule feasibility, safety compliance, an approved purchase or product-market fit. The three hypotheses add proposed workflows and measurable acceptance criteria; their target thresholds have not been validated.
Author verification: 16 focused local DOM/calculation checks passed, covering the default arithmetic, forecast and administration presets, no qualifying approach, invalid inputs, ties, negative scores, pilot gate boundaries, correction, reset and reload. These are local interaction checks, not browser visual QA or a user trial. Separate browser/release review remains with the parent run; no measured performance improvement is claimed.