Relay: product brief and hypotheses

Fictional teaching artefact. All audience and outcome claims are hypotheses until tested with real people and market evidence.

Problem statement

Maintenance issues in small multi-site operations teams may arrive through email, messages and informal conversations. The working hypothesis is that requests are lost, duplicated or left without a clear owner. Coordinators waste time asking which issues are open and who is acting on them.

Proposed audience

• Primary user: site coordinator handling issues across multiple buildings.
• Secondary user: staff member reporting a broken fixture or device.
• Buyer or sponsor: operations manager who wants visibility without adopting a heavyweight facilities platform.

These personas are assumptions, not research findings.

Product outcome

A reporter can submit a request; a coordinator can see it, assign an owner and understand its status; the reporter can see that somebody has taken responsibility.

This deliberately avoids assuming that automated classification, prediction or scheduling is necessary.

Initial positioning hypothesis

Relay offers small operations teams a simple request ownership workflow, with less setup and cognitive overhead than a broad facilities-management suite.

“Less setup” and “better ownership” are claims to validate, not facts established by the brief.

First product hypotheses

ID	Hypothesis	Evidence that would challenge it
H1	Lost ownership is a higher-priority problem than misclassified urgency	Users consistently prefer urgency automation over ownership clarity
H2	The team will adopt a simple request-and-assignment view	Users revert to email/spreadsheets or cannot complete the task
H3	A small, stable request model can support early experiments	Each experiment requires disruptive schema changes
H4	Automated priority would make the initial product stronger	It introduces friction, low trust or no useful decision support

Candidate capabilities (initial, not committed)

• Submit a request with site and short description.
• Ensure a repeated delivery of one submission does not create duplicates.
• Assign the request to an owner and show status.
• Show an audit trail of meaningful changes.
• Notify participants when ownership changes.
• Candidate for evaluation only: automatic urgency classification.

Quality and risk considerations

• Prevent silent data loss on retries and conflicting duplicates.
• Respect site/tenant boundaries; no cross-tenant visibility.
• Preserve an auditable record of assignment changes.
• Avoid integrating with external messaging before delivery/consent requirements are understood.

Initial product boundary

Not in the first evaluated slice: workforce scheduling, asset inventories, automated dispatch, predictive maintenance, sophisticated severity models or a replacement for enterprise facilities management.

What would justify continuing

Evidence from real users that the product reliably solves the ownership problem, plus an engineering path to a supportable release. The first set of experiments should be able to reject H1–H4, not simply produce a feature demo.