Product Vision Needs Boundaries: Write Non-Goals That Help Decisions

A team building an appointment-recovery product receives a request for staff payroll. The customer is important, the request is understandable and the sales team can explain why it would help close a contract. The product vision says the team will make service businesses more efficient. Payroll fits that sentence just as easily as appointment recovery does.

The vision provides no useful boundary. The team now has to negotiate scope from scratch, using the latest request as its starting point.

This fictional case illustrates why a product vision needs a clear user, a problem and a future condition that the product is meant to create. Explicit non-goals help the team apply that direction. They should also say what evidence would justify revisiting it.

Start with the problem the user is trying to solve

For the appointment product, suppose research finds that customers struggle to change a booking without calling during working hours. Reception staff then spend time resolving requests across email, phone and a scheduling system. These are assumptions in this example, not findings from a real business.

A more useful vision would be: customers can change an eligible appointment and understand the result without needing a staff member to coordinate the change manually. That sentence identifies a user outcome and leaves room to discover how to achieve it.

GOV.UK's user-research guidance asks teams to learn what users need to do and the problems they encounter, rather than beginning with a preferred solution. It is public-service guidance, but the distinction is useful here: a request for a new screen is evidence to investigate, not a complete account of the underlying need. GOV.UK: start by learning user needs

The word “eligible” also needs explanation. It could depend on the business's booking policy or the remaining time before an appointment. A vision statement does not settle those rules. It gives the team a reason to investigate them.

Keep vision, strategy and the delivery plan distinct

Vision describes the future condition the team wants to make possible. Strategy chooses where to focus and which approach to test. A roadmap communicates intended progression as the team learns. A quarterly measure helps judge whether a particular change is working.

If these are collapsed into one list, a missed feature date can look like a failed vision, while an unchanged vision can be used to defend an ineffective solution. GOV.UK describes a roadmap as connecting a product vision to the work that moves towards it, and distinguishes that view from a detailed backlog. GOV.UK: developing a roadmap

For this example, self-service rescheduling might be an approach to test. It is possible to retain the vision while discovering that some appointment types still need a staff decision. The team should examine the exception instead of disguising it as a completed self-service journey.

Write non-goals around decisions you expect to face

A non-goal should identify a tempting adjacent area and explain the current boundary. “No scope creep” is too vague to help a product manager answer a customer. “We will not build a general payroll system in this product” is concrete, but it becomes more useful when paired with the user problem and a revisit condition.

These are proposed decisions, not universal product rules. Accessibility, mandatory obligations and existing contractual commitments cannot be dismissed by writing them in a non-goals section. Identify and address those obligations through the appropriate owners.

Make the boundary reviewable

My open product-vision worksheet separates the future state, intended users, reason to act, measures and non-goals. It is my own template, not independent evidence that a particular product approach succeeds. The useful discipline is writing these fields together so that another person can challenge their consistency. PMOS vision worksheet at a pinned revision

For each boundary, record the decision owner and the evidence that would reopen it. For payroll, that might be evidence of a separate user problem worth investigating as another product. It need not mean adding payroll to the appointment product. For staff availability, new evidence may show that a small integration is required to complete the original task.

Avoid impossible revisit conditions such as “when every customer asks.” They protect a document from challenge instead of helping a team learn. Use an observable change in the problem, constraint or dependency, and record the uncertainty that remains.

Evaluate a request without rewriting the vision in the meeting

Check whether the vision changes a real decision

Give two colleagues the appointment-recovery vision and several recent requests. Ask them to explain which requests need discovery, which are outside the boundary and which reveal an unclear obligation. If they reach different conclusions, examine the wording and evidence before adding more slogans.

Then trace a real user task. The journey-mapping guide helps expose waiting and handoffs hidden between screens. If research disagrees, use the conflicting-evidence guide to retain the context of each observation rather than averaging away the disagreement.

A useful vision should make the payroll conversation easier to resolve while leaving the appointment problem open to learning. It should be possible to explain a decision, name the evidence behind it and say what would change your mind.