Back to Playbook

Operating model

Sketch

Decide whether the idea deserves a build.

Contents · 06
  1. 01 - Context
  2. 02 - Model
  3. 03 - How it works
  4. 04 - What good looks like
  5. 05 - Artifacts
  6. 06 - Keep reading
01Context

Why this idea deserves a build.

Sketch is where I earn the right to build. It is tempting, especially with AI, to jump straight into screens, routes, components, or database tables. But the first risk is usually not technical. It is whether the problem, customer, wedge, and value exchange are clear enough to deserve implementation.

A good Sketch does not need to become a strategy deck. It should make the idea smaller, sharper, and more falsifiable: who is this for, what progress do they need, why now, why this approach, and what would make me stop before writing code.

02Model

The business question before the build.

The model is the part of the article where the idea becomes usable: a sequence of decisions, artifacts, or checks that can guide real product work.

Problem

Name the painful situation.

Who is struggling, what are they trying to accomplish, and why do current alternatives fail at the moment that matters?

Wedge

Choose the narrow entry point.

The first version should not serve everyone. It should make one high-value workflow meaningfully better for a clear user.

Risk

Write down why this might be wrong.

A risk matrix protects the builder from falling in love with the idea before the evidence is strong enough.

Fig. 01 - Process mapSketch

The model moves from question to artifact to evidence.

  1. ProblemName the painful situation.
  2. WedgeChoose the narrow entry point.
  3. RiskWrite down why this might be wrong.
03How it works

Sketch validates the business, not only the feature.

The model forces business validation before implementation. The work should answer whether the problem is urgent, the buyer or adopter is clear, the value exchange is plausible, and the first scope is simple enough to test.

Sketch starts from something concrete: a user problem, customer request, founder-created screenshot, existing repository, regulatory obligation, business thesis, visual example, or production failure. The key is to capture the raw evidence without forcing premature structure.

This stage is especially useful for AI-assisted building because AI will happily build the wrong thing if the human has not clarified what deserves to exist.

04What good looks like

A good Sketch makes the next step smaller.

The output does not need to be long. It needs to make choices: user, job, wedge, promise, alternatives, risks, and what evidence would change the plan.

The report’s framing questions are useful here: who has the problem, what are they trying to accomplish, what happens today, why is that insufficient, what outcome would be meaningfully better, and what should remain explicitly out of scope.

A strong Sketch also names the riskiest assumption. Sometimes that risk is technical feasibility. Sometimes it is customer comprehension, provider quality, legal interpretation, output fidelity, or willingness to pay. The next artifact should target the assumption most capable of changing the plan.

Scope by uncertainty, not by fixed time promises.

From this essay
05Artifacts

What this leaves behind.

I use artifacts as evidence of thinking. They make product judgment reviewable, reusable, and easier to connect back to the work.

Problem thesis

The compressed statement of user, situation, current alternative, and desired progress.

Customer wedge

The smallest user segment where urgency, access, and product value are plausible.

Opportunity map

A view of alternatives, willingness to pay, differentiation, timing, and route to first use.

Risk matrix

The honest list of value, usability, feasibility, viability, trust, and go-to-market risks.

Next in the Playbook - 02HelmSet enough direction that the work can be built without drifting from the product intent.Continue reading ->