Should We Build This? — Decision Worksheet

A team proposes an ordering app because customers keep calling about stock and delivery. The proposed interface is clear; the reason for the calls is not. Are customers unable to place an order, unable to trust the stock shown, or unable to learn what happens after ordering? Each explanation points to a different first move.

What this worksheet helps you decide

Use it before committing substantial time or money to a feature, app or business system. It helps a founder, product owner or leadership team distinguish an observed difficulty from a preferred solution, compare responses and choose the next piece of evidence. Bring examples from actual customers or operators. If you have none, collecting them is your first task.

Work through six prompts

Complete the fields below in plain language. Mark each statement as observed, reported or assumed. A customer request is evidence of a request; it is not automatically evidence that a particular product will solve the underlying problem.

Before agreeing to build

• Observed problem: Describe the person, task, failure point and consequence.
• People and frequency: Identify who experiences it and how often, using a defined period where possible.
• Evidence: Separate directly observed cases from reports and assumptions.
• Without building: Consider a process change or an existing tool as a credible first response.
• What changes your mind: State an observation that would make you revise the preferred solution.
• Next commitment: Choose a small action that answers the leading uncertainty, then name its owner and review date.

A worked example: the proposed ordering app

Fictional teaching example. A distributor hears frequent calls asking whether stock is available and when orders will arrive. The sales team suggests an app. A sample of recent calls might instead show that existing stock figures are stale and delivery promises vary by representative. The question is now whether a customer interface would expose reliable information or simply make unreliable information easier to find.

The team records call reasons for two weeks, checks when stock data changes, and tests a clearer confirmation message with a small group of repeat customers. It compares three options: repair update ownership and messages, configure the current ordering system, or commission a new interface. The decision owner reviews call reasons, accuracy and customer feedback before scoping a build. Those observations would guide the next step; a small test would not prove wider demand or future savings.

Where this tool stops

A completed worksheet is a record of reasoning, not a score or approval. It does not estimate cost, validate a market or settle regulatory, security or accessibility requirements. If the decision is consequential, involve the relevant specialists and people who will run the service.

Continue with the Before You Build series for a step-by-step path, or read the open guide for the connected argument.

Method reference: the UK Government Service Manual’s discovery guidance describes reframing a proposed solution as a problem and learning about users and constraints before a build. This worksheet is Parikh Advisory’s editorial application of that discipline, not a government-endorsed tool.