Define: What "Good" Looks Like
Every evaluation judges a system against some idea of "good", so that idea is the yardstick everything else depends on. While most product owners have some notion of what "good" looks like, it might be vague, incomplete or hard to communicate, leading to complications down further when designing and executing their evaluations.
This chapter aims to turn that vague notion into an explicit, agreed list of specifications: the requirements your product must meet. It sets the foundation for the rest of the evaluation; every chapter after this one hinges on it, so take your time to get it right.
We recommend a three-step process to help ensure relevance, coverage, and agreement in your definition of "good":
- Improve the system
- Compare products
- Support a decision
- Mission
- Intended users
- Existing requirements
- Functionality
- Safety
- Robustness
- Reliability
- End-to-end
- Subsystem
- Component
- Business
- System
- Operational
Without a clear, shared definition of what "good" looks like, you risk your evaluation becoming:
- Unfocused: Ambiguity leads to measuring what is convenient rather than what actually matters.
- Inefficient: Evolving expectations force unnecessary revisions, leading to wasted time and resources.
- Ineffective: Lack of agreement can render strong evaluation results invalid, because stakeholders may not accept the criteria you used to judge the system.
How this chapter is organised
We will first cover the three steps in great detail, and then provide worked examples to show you how the process is applied in practice.
- The three-step processHow do you get from a vague notion of “good” to a concrete list?
- Worked examplesWhat does the process produce on two real products?
What you will have by the end
- An agreed definition of "good"A short written list of the specifications that matter for your product, agreed with your stakeholders
Was this page helpful?