From vague requests to testable releases

1. Start with the request, not the feature

Consider a fictional operations team whose manager says: “We need a dashboard so I can see everything in one place.” A dashboard may eventually be useful, but it is not yet a reliable product requirement. “Everything” has no agreed boundary. The manager may be trying to answer one recurring question, such as which submitted documents are at risk of missing a review deadline.

My first step would be to ask for a recent example: What happened? Who noticed the problem? Which decision was delayed? What did people do instead? When did they finally have enough information to act? An answer anchored to a real workflow is usually more useful than a list of preferred charts.

Then distinguish three kinds of statements: an observation (“the team checks four spreadsheets”), an interpretation (“the handoffs are slow”) and a proposed solution (“build a dashboard”). Treating those as different prevents an early design suggestion from becoming an unquestioned fact.

2. Draw the existing workflow

A useful workflow map is less about elegant boxes than about revealing decisions. For the fictional document-review example, map the work from submission through assignment, review, clarification, approval and archive. For each step, capture the actor, information needed, decision made and what can go wrong.

• Submit: a requester provides a document and identifies the review category.
• Assign: a coordinator selects a reviewer based on queue and expertise.
• Review: the reviewer accepts, requests clarification or rejects.
• Escalate: unresolved requests move to a responsible person before a deadline.
• Close: the decision, date and rationale remain discoverable.

Notice that none of these steps requires a dashboard by itself. The critical feature might instead be an exception queue with owner, age and next action. The mapping exercise can reveal that a simpler interface would solve the urgent problem better.

Also document where the work happens today. If the source information is incomplete or late, putting it in a polished interface will not make it trustworthy. Data ownership must be considered before visualisation.

3. Make requirements observable

“Show pending reviews” sounds precise but still leaves room for disagreement. Does pending include an item returned for clarification? What if the reviewer is absent? How quickly must the data update? Who may see a sensitive submission?

Acceptance criteria should describe observable behaviour and important boundaries. For example:

Given an authenticated coordinator with permission to view a queue, when a submitted item is past its agreed review date and has no final decision, then the queue labels it overdue, identifies its current owner and provides a route to the item history.

This criterion does not prescribe a chart or database implementation. It specifies the business condition, the role and the result. Follow it with negative cases: hidden records for unauthorised users, missing owner assignments and items closed after escalation.

A lightweight specification also needs a glossary. “Submitted,” “in review,” “blocked,” “overdue” and “closed” should have a single agreed meaning. Small differences in vocabulary can create large differences in what developers implement.

4. Scope the first useful release

Suppose the team asks for analytics, exports, notifications, role management, custom filters and integration with several other systems. Delivering everything at once makes it harder to isolate why a release succeeds or fails.

A better first release might have four capabilities: a reliable status model, a queue filtered by status and owner, a visible next action and an audit trail of status changes. Add advanced reporting only after the basic task works. This is not a universal minimum viable product template; it follows from this particular workflow's highest-risk question: can the coordinator find and act on the cases that need attention?

Write the exclusions as carefully as the inclusions. For the first release, explicitly defer bulk export, automatic assignment and predictive deadlines. Explain what would cause each deferred feature to be reconsidered. A clear exclusion prevents an assumption from silently returning as a defect at acceptance testing.

Before development, review the flow with someone who performs the work, a developer and whoever owns access permissions. The person experiencing the problem can catch a workflow mistake; the developer can expose technical dependencies; the permission owner can prevent sensitive data from appearing in the wrong place.

5. Measure the task after shipping

Shipping a screen is a milestone, not proof of value. In this example, measure whether a coordinator can identify an overdue item, understand its owner and take the next action without consulting a separate spreadsheet. Record a baseline before launch if possible. Then look at successful task completion, time to resolution, incorrectly classified cases and support requests.

A simple comparison might be: before release, a coordinator manually reconciles four exports to build a review queue; after release, the same user should be able to identify the queue within the product. Verify the task using representative records and difficult exceptions. Do not present an invented “hours saved” figure unless time was actually measured.

Metrics also need context. A decline in overdue cases could be good news, or it could result from a new status definition that hides cases. Pair quantitative signals with sampled workflow reviews and user interviews. Check whether the product is changing behaviour or merely changing what gets counted.

A release-readiness checklist

• Can a new team member explain the user's goal in one sentence?
• Are the current workflow, handoffs and known exceptions documented?
• Does every important status have an unambiguous definition?
• Have permission and privacy boundaries been reviewed?
• Can acceptance criteria be demonstrated with a representative example?
• Are deferred requirements and release boundaries explicit?
• Is there a baseline or practical plan to evaluate the outcome?

These questions create a shared product contract without freezing the implementation. The objective is not perfect documentation. It is to make the next decision easier and prevent a team from spending a sprint solving an assumption rather than a problem.