Exercise
Non-Functional Requirements Workshop
A cross-functional workshop for agreeing how a product or system must behave — then turning words such as secure, reliable and scalable into ranked, measurable requirements.
Use this before a major build, platform decision, vendor selection or enterprise commitment. Bring technical, product and commercial decision-makers; add security, operations, support or legal when their constraints could change the answer.
The ranking is the conversation. "Enterprise-ready" might mean auditability to commercial, uptime to customers and maintainability to engineering. Do not average those differences away — make the trade-offs explicit before architecture turns them into expensive facts.
A 90-minute workshop
Frame the decision · 10 min
Name what you are choosing, who it must work for and the 12–18 month horizon. Capture known commitments and constraints without debating solutions yet.
“Decision: the architecture for the next enterprise release. Context: regulated customers, tenfold usage growth and a small engineering team.”
Generate the qualities · 10 min
Working silently, each person writes the qualities and constraints that could make the decision succeed or fail. Seed only if needed: security, reliability, usability, performance, scalability, adaptability, maintainability, vendor independence, cost, time to market and hiring.
Make the words concrete · 20 min
Cluster duplicates, then ask what each label means here. Replace broad claims with observable scenarios: under what conditions, what must the system do, and how will you know?
“Replace "reliable" with "during a single-region outage, checkout recovers within 15 minutes with no confirmed order lost."”
Build one priority spectrum · 20 min
Place every item from lower to higher importance. Start with individual positions, then discuss the largest disagreements. The aim is shared judgement, not a mathematically tidy average.
Force the trade-offs · 15 min
Choose three to five non-negotiables. For each, name what you are willing to optimise less — speed, cost, flexibility or another quality. If everything is critical, nothing has been prioritised.
Write the contract · 15 min
Turn the priorities into thresholds, owners and evidence. Record assumptions, open questions and the event that should trigger a review, then carry the agreed constraints into architecture, procurement and roadmap decisions.
Example spectrum — not a default answer
Leave with a decision record
| Capture | What good looks like |
|---|---|
| Priority | One agreed spectrum, with three to five qualities marked non-negotiable. |
| Requirement | A measurable threshold or quality scenario rather than a one-word aspiration. |
| Trade-off | What the team will optimise less, and why that choice fits the current horizon. |
| Evidence | How the team will test, monitor or verify the requirement. |
| Ownership | One owner plus a date or event that triggers review. |
Related capabilities
Related tools
Work with Ben
Want help installing this?
Outstride OS is the system behind Ben's founder coaching — pre-seed to Series C. If this page names something you are living right now, start a conversation.