In short
This track is for anyone who owns a product and has talked to customers. You will turn interview notes into two to four personas. You will mark every line as known or a guess. You will list each touch point, where a person meets your product. Then you will draw a user journey and a customer journey. You will find where the journey breaks. Each break can become an epic candidate for your roadmap. You decide who you serve, and who you do not.
Agents can tidy your notes. They must not invent people, quotes or journey steps. You keep personas, journeys and breaks as files in git.
Key words
- Persona: A short profile of a typical person, built from real interviews.
- Touch point: Any place where a person meets your product.
- Journey (user or customer): The steps a person takes to reach a goal, with thoughts and feelings.
- User: The person who uses the product.
- Customer: The person who pays. Often not the user.
- Epic: A whole-product outcome across several repos. Weeks to months. Written by a human.
A persona is a promise to your team: “This is who we are building for.” A journey is a second promise: “This is what their day looks like when they meet us.” Together they make sure that the people who build your product, whether people or AI agents, build it for a real human and not for an average that does not exist.
Who this track is for
This track is for anyone who owns a product and has already talked to a few customers, or is about to. It follows the product discovery track, and it assumes you have interview notes or a plan to collect them. If you have not interviewed anyone yet, start there. A persona written without evidence is fiction.
What you will be able to do
After this track you will be able to:
- Separate the user (the person who uses the product) from the customer (the person who pays) and from other people who influence the decision.
- Write personas with demographics and real needs, using the labels K (known, with a source) and G (guess) on every line.
- List every touch point: each place a person meets your product, from a poster to an invoice.
- Draw a user journey and a customer journey that differ where they should.
- Find the breaks: the steps where people struggle, give up or are not served at all.
- Link each break to the parts of your product that must change, so it can become an epic candidate in the next track.
How the four lessons build
- Users, customers and the jobs they hire you for. You decide who is who, who the main people are and who you will not serve.
- Write personas from evidence. You turn interview notes into short, honest personas and a list of what you still do not know.
- Touch points and journey maps. You draw what people do, think and feel at each step, and where they meet your product.
- Find the breaks and hand over. You compare journeys with your product map, rank the breaks and write them as epic candidates, ready for week 3.
Each lesson has the same shape: why it matters, key ideas, a step-by-step method, a worked example with the fictional product TrailMug, how to work with AI agents, common mistakes, a practice exercise that ends in a file in your git repo, a checklist and links to free outside material.
The 2030 Product Development Manager at work
You decide who the product is for and what their experience should be. That is a judgment about people, so it stays with you. Agents can help around it, for example by turning your notes into tidy tables, drawing a first diagram from a table you wrote, or reading hundreds of support messages to suggest themes for you to check. They can also help you test a journey: you can ask an agent to walk through your signup page as a first-time visitor and list where it gets confused, which is a quick check that you then confirm with a real person.
What an agent must not do is invent the people. In the Dojo, no AI-generated personas, no invented quotes and no made-up journey steps. A persona that came from a model describes the average of what people have written online. A persona that came from five conversations describes five people you met. Only the second one tells you something new.
Other disciplines sit around this work. Design shows how the journey feels on screen. Marketing and sales know how people arrive and why they buy. Support knows where people get stuck. Finance knows who actually pays. Operations knows what the product does behind the scenes. Bring each of them into the room at least once.
How it maps to the Dojo
- Developer, week 2: Know the people. This track is the long form of week 2. It covers the 60-minute workshop, the persona sheets, the touch-point list and the two journeys, and it ends with the coach checkpoint question: “where does the journey break today?”
- Developer, week 3. The break list from lesson 4 is the input to your first epics.
- Master Developer. Personas and journeys appear in your Product Package as evidence that the roadmap serves real people.
Time needed
Each lesson takes about two to three hours of reading and exercises. Allow extra time for the second round of conversations, because personas almost always raise new questions. Finish the whole track in about two weeks alongside your other Dojo work.
What you will keep
By the end you will have a folder in your git repo with personas, a touch-point list, two journey maps and a ranked list of breaks. These files are the clearest evidence that your roadmap comes from people, not from preferences.
