Relay / fictional worked example
Product learning: remove a feature, don't just add more
On this page
Illustrative scenario only. The following trial notes are invented to show how a product might change; they are not real user research or empirical evidence.
Before evaluation
Relay’s initial candidate scope includes automatic urgency classification. The product team believes it might reduce coordination effort. At the same time, its core product hypothesis is that unclear ownership is the most immediate problem.
The team first builds enough request intake, assignment and status visibility to let target users experience that workflow. The stable mechanics are designed so the urgency experiment is optional rather than embedded into every request and contract.
Invented trial observation
In the fictional trial, participants complete request submission readily but repeatedly ask “who is dealing with this?” They pay little attention to predicted urgency and sometimes disagree with its labels. The additional controls appear to make the interface harder to scan.
These notes would not be sufficient alone to prove broader market demand. In a real project, the team would need participant context, sample size, task protocol, raw observations and follow-up validation.
Product decision
Decision (illustrative): remove automatic urgency classification from the next release candidate. Strengthen clear ownership, assignment and status visibility instead.
This is not “defer the feature forever.” It means the current evidence does not justify building or carrying it. Future validated need could reopen the question.
Changes propagated
| Artefact | Change |
|---|---|
| Product brief | Mark H4 as unsupported in this scenario; refocus on H1/H2 |
| Positioning | Emphasise clarity of ownership rather than predictive triage |
| Delivery plan | Remove urgency-classification work; add task validation for assignment visibility |
| Architecture | Keep stable request store and audit contract; do not introduce a model-scoring dependency |
| Tests | Concentrate on assignment status, permissions, replay and audit; no orphaned classification requirement |
| Roadmap | Show removal and its rationale, rather than hiding it in an abandoned backlog |
Why the architecture matters
If urgency classification had been embedded in the request store, assignment workflow and public contract, removing it would trigger cross-cutting rework. Because mechanics are neutral and orchestration owns product-specific behaviour, the product can become simpler while retaining reusable foundations.
This is not a guarantee that every experiment is cheap. It is the advantage of an architecture designed around stable capabilities and explicit boundaries, without prematurely implementing all possible product ideas.