Playbook 2 of 10, Build
Design the product
Turn a validated problem into a version-one design: the shortest path to value, a written cut line and the decisions you will defer.
What you will have at the end
- A list of customer jobs in the customer's own words
- A path to first value, drawn from first visit to first result
- Annotated screen sketches
- A written cut line for version one
- A log of deferred decisions
- Acceptance criteria for every item above the line
The steps
-
List the jobs the customer is hiring you to do
Write each job as a sentence from the customer's side, using the words they used in your interviews. These sentences, not a feature wish list, are the brief for the design.
-
Map the shortest path to value
Draw the single route from first visit to the moment the customer gets what they came for. Remove every step that is not on that route.
-
Sketch the key screens and test them on paper
Show low-detail sketches to people from your interviews and ask what they expect to happen next. Fix the confusion now, while a fix costs a pencil line.
-
Draw the cut line
Sort every idea into three groups, which are must exist for the first customer to get value, can wait, and will not build. Version one is everything above the line and nothing below it.
-
Choose well-understood components
Use proven parts for sign-in, billing and email unless one of them is your product. Keep a short log of the choices you are deliberately deferring and the trigger that would reopen each.
-
Write acceptance criteria for what is above the line
For each item, write the observable result that means it is done. A person who did not design it should be able to check it.
The playbook at a glance
A cover, one public figure that frames the question this playbook answers, and the steps drawn as one path.
Show the figures as a table
| Years since opening | All private industries | Information, including software |
|---|---|---|
| 0 | 100% | 100% |
| 1 | 79.6% | 80.8% |
| 2 | 69.1% | 70% |
| 3 | 61.4% | 60.8% |
| 4 | 55.4% | 53.3% |
| 5 | 50.2% | 46.8% |
| 6 | 46.4% | 42.6% |
| 7 | 43.6% | 38.6% |
| 8 | 40.3% | 35.4% |
| 9 | 37.4% | 33% |
| 10 | 34.7% | 30% |
Establishments with at least one employee, opened in the year to March 2015. A closure is not always a failure: it includes sales and mergers. Information includes software publishing; it is not software alone.
Source: U.S. Bureau of Labor Statistics, Business Employment Dynamics, Table 7 , March 2025 release
These figures describe all new U.S. businesses, not WE's results.
The steps, in order
- List the jobs the customer is hiring you to do
- Map the shortest path to value
- Sketch the key screens and test them on paper
- Draw the cut line
- Choose well-understood components
- Write acceptance criteria for what is above the line
What good looks like
A good design is specific enough that a team can build from it without guessing, and small enough that the first customer can reach the result in one sitting. It does not have to be finished or beautiful.
- Every item above the cut line traces back to a job a customer described in their own words.
- The path to first value fits on one page, and there is no step on it that a customer would call optional.
- The cut line is written down, and the items below it have a stated reason for waiting.
- Each item above the line has an acceptance criterion that someone who did not design it could check.
- Choices you are deferring sit in a log with the trigger that would reopen each one.
Decision aid: above the line or below it
Run each candidate feature through these questions in order. The first question you answer no to decides where the feature goes.
| Question | If the answer is yes | If the answer is no |
|---|---|---|
| Did a customer describe the job this feature does, in their own words? | Keep it on the list and ask the next question. | Below the line. Write down which interview would change your mind. |
| Is the path to first value broken without it? | Above the line. | Ask the next question. |
| Can the job be done by hand for the first customers? | Below the line. Do it by hand and watch what happens. | Ask the next question. |
| Can a proven component do the job, such as sign-in, billing or email? | Buy or adopt it, and place the choice in the deferred-decisions log. | Above the line, with an acceptance criterion. |
| Would you be embarrassed to release without it? | Check whether the embarrassment is about the customer or about you. Only the first belongs above the line. | Below the line. |
Common mistakes
| Mistake | Why it costs you | Do this instead |
|---|---|---|
| Designing for everyone | A product with no first customer in mind has no first path to value. | Name one kind of customer from your interviews and design for that person. |
| Copying a competitor feature list | You inherit years of someone else's decisions without their reasons. | Start from the jobs you heard in interviews and add only what a job needs. |
| Polishing visuals before the flow works | Beautiful screens hide a path that confuses people. | Test the flow with sketches first and add polish once the path holds. |
| Leaving the cut line unwritten | Scope grows quietly and the release date moves with it. | Write the line down and change it only through a recorded decision. |
| Building sign-in or billing from scratch | You spend weeks on parts that are not your product. | Use proven components and note what would make you revisit the choice. |
| Writing acceptance criteria as intentions | A line such as "easy to use" cannot be checked, so every review becomes an argument. | Write what a person can observe, in the customer's words. |
Evidence to check before you move on
Move to Set up the company when you can show each of these. The company setup comes before you build because the people who write code for you will be asked who owns it.
- Every item above the cut line traces back to a customer job.
- The path to first value fits on one page and has no step that a customer would call optional.
- Someone outside your team has read the acceptance criteria and could tell whether a feature passes.
- Deferred decisions are listed with the trigger that would bring each one back.
The design does not have to be finished or beautiful. It has to be specific enough that a team can build from it without guessing.
Where WE can help
WE’s Product and IT Development line covers architecture, an agile build in short cycles and a pilot environment where your first customers can use the product. It does not run your live service or promise that a product will pass a particular audit. The service line page lists the full scope.
Sources
The steps and the decision aid draw on the articles and templates below. Each article names the public sources it read.
Start a readiness review
Tell WE where the company stands. WE replies to arrange a conversation and a written read of your company's timeline.
A short PDF of the charts and sources, sent by email to the address you give.
Talk to WE : A question that does not fit a form.