Defining the Problem

Before any building begins, the team needs a clear understanding of what problem they are trying to solve. But in Build First, this stage is intentionally lightweight. The goal isn’t to write a perfect spec or map every detail—it’s to establish enough clarity to start building the first slice.

Define just enough to move, not enough to stall.

This is a sharp break from traditional methodologies, which often front-load weeks of research, stakeholder interviews, requirements documents, feature lists, and detailed flows. Build First keeps the problem definition phase short on ceremony and long on practicality.

1. Focus on the user outcome, not the feature

The team should start by articulating the outcome the user needs, not the feature the team imagines.

Instead of:

• “We need a dashboard with filters and charts”

Define something like:

• “Users need to quickly understand their emissions hotspots so they know where to act”

Outcomes are flexible.

Features are rigid.

Outcomes create space to explore.

Features prematurely narrow the solution.

2. Keep problem statements simple

A Build First problem statement should be short—one or two sentences. Clear. Grounded. Easy to remember. Useful.

Examples:

• “Help people compare plumes in a way that feels immediate and intuitive.”
• “Let users import a document and instantly see it structured into editable fragments.”
• “Make it easy for a museum curator to find an object by photo, tag, or number.”

If the problem takes paragraphs to explain, you’re defining a solution, not a problem.

3. Identify constraints early, but lightly

Constraints steer the first build. They’re not meant to freeze scope; they simply help shape the smallest viable starting point.

Ask:

• What data do we actually have today?
• What’s the simplest interaction the user must be able to perform?
• What technical or design decisions are already fixed?
• What assumptions do we need to validate quickly?

The goal isn’t to catalog every constraint—it’s to surface the ones that change the shape of the initial build.

4. Avoid solutions disguised as problems

Teams often jump straight to solutions and label them “problems.”

Examples:

• “We need a sidebar with filters.”
• “We need a multi-step wizard.”
• “We need to add a new onboarding flow.”

These are solutions, not problems.

The real problem might be:

• “Users feel overwhelmed by too much data.”
• “Users aren’t sure what the next step is.”
• “New users don’t know where to start.”

Build First always returns to the underlying need—and then builds the smallest version of something that addresses it.

5. Define the problem together

Fragmentation leads to misalignment. Build First avoids this by defining the problem collaboratively:

• Designers
• Engineers
• Product
• Anyone who understands user needs

Because all of these roles will shape the solution inside the build, they should all help shape the problem.

A problem defined together is a problem everyone feels ownership over.

6. Stop as soon as the team is aligned

You don’t need:

• a 10-page document
• a polished deck
• a huge research report
• a complete design flow

You need a shared understanding of what you’re trying to learn.

The litmus test:

Can every person on the team explain the problem the same way in their own words?

If yes, stop. Enough is enough.

Start building.

A clear problem unlocks fast progress

Good problem definition doesn’t slow the team down—it enables speed. It narrows the focus just enough to guide the first build, but stays loose enough to allow iteration and discovery.

Build First treats problem definition as the start of motion, not a gating requirement.

You define the problem so you can begin the loop:

Build → Show → Refine

The point is not to perfect the problem definition.

The point is to start learning from real software as quickly as possible.