Relay / fictional worked example
Market comparison and product discovery
On this page
Example research plan, not completed research. No competitor features, prices, market sizes or real customer findings are asserted here.
Compare alternatives by user job
Relay’s working job-to-be-done is: capture a maintenance request, identify an owner and communicate status without unnecessary administration.
Instead of copying a competitor feature list, compare the kinds of tools customers might already use:
| Alternative category | Questions to investigate | Possible differentiation hypothesis |
|---|---|---|
| Shared email/chat | How is ownership tracked? What is missed? | A durable owner and state might add value |
| General helpdesk | How much setup is needed for sites and users? | A narrower workflow may be easier to adopt |
| Facilities-management suite | Which capabilities are necessary at this scale? | Simplicity may beat broad feature coverage |
| Spreadsheet + manual process | What breaks as work volume grows? | Consistent audit and status may help |
These are research questions, not verified competitive claims.
Test sequence
- Problem interviews: understand current request-handling behaviours without pitching the proposed solution.
- Workflow observation: ask participants to show a recent issue from report to resolution; note handoffs and ambiguity.
- Clickable or working prototype: test whether reporting, assigning and checking status are understandable.
- Comparative task trial: evaluate the same tasks against the participant’s existing method or a relevant alternative.
- Small operational pilot: measure usage and failure cases with explicit consent and appropriate security controls.
Example task outcomes (to define, not claim)
- Can a reporter submit a request without help?
- Can a coordinator identify all currently unowned requests?
- Can an owner and reporter tell whether work is underway?
- Does the product create more administrative work than it removes?
Avoid publishing numerical thresholds as universal benchmarks. Set provisional targets with the team and refine them from evidence.
Feed research into the product
Store the current position, assumptions, questions and decisions near the product implementation, with the date and provenance of each observation. Distinguish observed feedback from interpreted conclusions.
When an experiment changes strategy, update the brief and design before issuing more implementation work. An old proposed feature should not silently become a requirement because it exists in an abandoned plan.
Why this is part of development
Rapid engineering makes a credible experiment easier to construct, but a fast implementation is only useful if it answers the right question. Product research sets the question; architecture and delivery create a safe way to test it; feedback changes what to build next.
Continue to the decision log and worked scope revision.