Start a project

What Happens Before We Write Code: Product Discovery

What Happens Before We Write Code: Product Discovery

The cheapest week on a project is the one where you still have not opened the repo.

/ Table of contents:

What discovery is for

Discovery is not a workshop to make slides. It is a short, paid phase to name the user, the first release, and the risks. You leave with a scope you can estimate, not a vision deck. If everyone still disagrees on who the product is for, you are not ready to staff a team.

Most overruns are not engineering problems. They are unanswered product questions that showed up in sprint three.

/ Dimitriy Caliber

What we actually do

We map the current process, list the jobs to be done, and cut a v1 that can be demoed. We flag third-party dependencies, data you do not have yet, and decisions only the founder can make. The output is a backlog with priorities, a clickable or documented flow, and a delivery plan with assumptions written down.

  • Primary user and success metric
  • In-scope / out-of-scope for v1
  • Open questions with owners

Why skipping it feels faster

Skipping discovery feels like momentum. Then week four arrives and the “simple admin” needs five roles, the API you counted on is invite-only, and design is still arguing about the home screen. You will do discovery anyway. You can do it cheaply at the start, or expensively in production.

How long it should take

For most products, one to three weeks is enough. Longer than that usually means the brief is still a company strategy, not a product. Keep the room small: founder, one operator who knows the pain, and the delivery lead. Too many voices and you will design a compromise nobody wanted.

Have a project in mind?

Leave your name and a way to reach you. We will get back with a clear next step.

More on topic