Track · Product skills

Product discovery

Learn what to build, and for whom, before anyone writes a line of code. Frame the problem, interview real customers, map the whole product and decide with evidence.

In short

This track is for people who want to own a product. You do not need to code. Discovery means learning what to build before you build it. You will frame an idea: a problem, a person, a measure and a date. You will run five customer interviews and keep notes you can trust. You will draw the whole product on one page. Then you decide what to do next: build, change, test further or stop. You keep your decision in a short record in git. Never ask an AI to invent customers or quotes.

AI agents can build almost anything you ask for. Your skill is to know what to ask for, and why.

Key words

  • Discovery: Learning what to build, and who it is for, before you build it.
  • Customer: The person who pays. Often not the user.
  • User: The person who uses the product.
  • Assumption: Something you believe is true but have not yet checked.
  • Decision record: A short file for one decision: the options, the choice and the reasons. It also names the day to look again.

Most products fail for a boring reason: someone built the wrong thing very well. Discovery is the work you do to avoid that. It is the first and most valuable skill of a Product Development Manager, because when AI agents can build almost anything you ask for, the scarce skill is knowing what to ask for and why.

Who this track is for

This track is for you if you want to own a product, not only a part of it. You may be a junior developer, a career changer, a designer who wants to lead, or an experienced engineer who now steers AI agents. You do not need to know how to code to start. You do need to be willing to talk to strangers, write plain sentences and change your mind when the evidence says so.

What you will be able to do

By the end of the track you will be able to:

  • Write a one-paragraph product idea that names a user, a problem, one success number and a date.
  • Plan and run five customer interviews, take notes without leading the person, and keep private details out of git.
  • Draw your product on one page, including the repos, the integrations and the people who will touch it.
  • Separate what people said, what you saw and what you guess, and mark each one.
  • Run cheap tests of your riskiest assumptions before you commit months of work.
  • Write a short decision record that says what you will build first, what you will not build and what would change your mind.

How the four lessons build

  1. Frame the problem and the idea. You turn a loose idea into a short brief, and you list the assumptions that must be true for it to work.
  2. Talk to customers. You learn to interview well, recruit the right people and capture evidence.
  3. Map the whole product. You draw every part of the product and every system it depends on, so you see the work an agent never sees.
  4. Make sense of the evidence and decide. You synthesise what you learned, test the riskiest assumptions and write a decision you can defend.

Each lesson follows the same shape: why it matters, the key ideas, a step-by-step method, a worked example with the fictional product TrailMug (reusable cups for cafés), how to work with AI agents on the task, common mistakes, a practice exercise that ends in a file in your git repo, and a checklist. Every lesson also points you to free outside material from respected publishers, so you can go deeper wherever you need to.

What the 2030 Product Development Manager does here

In discovery you do four things no agent can do for you:

  • Decide what is worth learning. You choose which questions matter and which can wait.
  • Talk to real people. You sit with customers, partners and colleagues and notice what they do not say.
  • Judge evidence. You decide what counts as proof and what is a polite opinion.
  • Own the decision. You say, in writing, what you will build and what you will not.

Agents are useful helpers. They can draft interview guides for you to rewrite, tidy your notes after you have taken them, search public sources for competitors, and build a quick prototype for a test. You check every result. In the Dojo you also disclose how you used AI, and you never ask an AI to invent customers, quotes or findings. Those must come from real conversations.

Discovery touches other disciplines too. Finance asks whether the numbers can work. Operations asks whether you can deliver. Legal and privacy ask whether you may collect what you collect. Design asks what the customer actually does. A strong manager brings these voices in early, while changes are still cheap.

How it maps to the Dojo

  • Developer, week 1: See the whole product. Lessons 1 and 3 support the one-paragraph idea, the repository map and the integrations register. Lesson 2 supports the five interviews you book in week 1.
  • Developer, week 2: Know the people. Lessons 2 and 4 feed the persona and journey work in the Personas and journeys track.
  • Master Developer. The decision record from lesson 4 becomes the evidence behind your epic roadmap, and the base of your final Product Package.

Time needed

Plan about four to six hours of reading and exercises per lesson, spread over a week or two, plus the time to book and hold five real conversations. Interviews are the slow part, because other people set the schedule. Start booking them on day one.

Before you begin

Create an empty git repository for your product (or use the one you made in week 1). Every practice exercise in this track ends with a file saved there. By the end you will have a folder of honest, dated evidence that anyone can read, which is the best proof that your decisions are your own.

Lessons

Lessons in order

You mark a lesson done at the end of the lesson. This is saved only in this browser, on this device. It is not a grade and not a certificate.

  1. Frame the problem and the ideaFoundation90 min

    Turn a loose idea into a short written brief with a user, a problem, a measure and a date, and list the assumptions that must be true before you spend months building.

  2. Talk to customersFoundation2 hours plus the interviews

    Recruit the right people, run five short interviews that ask about the past, and capture evidence you can trust without leaking anyone's private details.

  3. Map the whole productFoundation2 hours

    Draw your product on one page: every part, every rented system, every partner and every competitor or workaround, with a clear mark for what exists today and what does not.

  4. Make sense of the evidence and decideCore2 hours

    Cluster what you learned, grade the strength of your evidence, test your riskiest assumption cheaply and write a decision record that says what you will build, what you will not and what would change your mind.

All tracks · Learning resources