Product Owner

Curriculum

Every chapter is listed here. You enrol in the whole course, not one chapter.

1. Module 1

   The owner seat

   Why the role exists, and what this course will ask you to do.

   • What you will be able to doName the next slice, and the reason it is next.
   • Why this role existsSomeone has to choose. If nobody does, the loudest ticket wins.
   • What the four weeks coverThe seat, the backlog, the team, and a capstone on a product you know.

2. Module 2

   Who owns the product

   The accountabilities, and how this seat differs from the agile analyst.

   • Who the product owner isThe person accountable for the value of what the team builds.
   • What the seat is responsible forThe goal, the order of the work, and whether it was worth building.
   • Owner and agile analystThe analyst can write the story. The owner decides if it should be built.
   • The core accountabilitiesValue, the backlog, and a team that understands the goal.
   • A simple way to see the workCustomer, team, delivery, and the value you can point at.

3. Module 3

   Vision, roadmap, and the backlog

   From a direction, to a release, to a list you can put in order.

   • Product visionWho it is for, and what will be true if the product works.
   • Roadmap and release planningNow, next, and the release you can actually staff.
   • From vision to roadmapYou draft both for the product you brought.
   • Putting the work in orderMust, should, could, and the item that waits. A reason for each.
   • Story and backlog refinementA story small enough to finish, with the guess taken out.
   • Build a backlog and order itYou leave with a short list a team could start.

4. Module 4

   How a product owner works

   Stay close to the customer, deliver often, and judge the work by value.

   • The basics, used on a real productGoal, slice, and the person who benefits.
   • Stay close to the customerYou can say what they do today, not what the ticket claims.
   • Bring the whole team inDesign, engineering, and the analyst hear the goal before the sprint starts.
   • Make an impactThe change a user would notice, named before the build.
   • Deliver oftenA small release beats a perfect plan that never ships.
   • Learn fastWhat you will watch after the slice, and what would change your mind.
   • Obsess about valueIf you cannot say who benefits, it is not next.
   • Map the practices to a weekWhich one you use on Monday, and which one can wait.

5. Module 5

   The tools

   A backlog, a page, and a wireframe. Enough to run the work.

   • A backlog toolThe list, the order, and the status. Not a tour of every button.
   • A page for the decisionThe vision and the release, where a sponsor can read them.
   • A wireframeEnough of the screen to see if the story is real.
   • Draft a small releaseYou put one release into the backlog tool before you leave.

6. Module 6

   Techniques that earn their place

   The methods you will actually reach for, not a list to memorise.

   • Backlog refinementMake the next stories small, and leave the rest alone.
   • Business caseThe need and the cost, without inventing a return you cannot defend.
   • Collaborative gamesA way to get the quiet person into the decision.
   • Customer journey mapWhere the person is today, and where they stop.
   • Decision modellingWho decides, and which choice is not yours.
   • Ready, delivery, and doneThree lines the team can use without asking you again.
   • Empathy mapWhat the user says, does, and worries about.
   • Focus groupsSeveral voices, and a note that does not belong to the loudest one.
   • Human-centred designStart from the person, not from the feature list.
   • Job storiesWhen this happens, the person wants to, so that.
   • Kano analysisWhat must be there, what delights, and what nobody will miss.
   • Metrics and indicatorsThe number that would change the order of the backlog.
   • The smallest versionThe least you can ship and still learn.
   • Non-functional requirementsSpeed, privacy, and the rule that is not a button.
   • PersonasA person with a job to do, not a stock photo.
   • Problem definitionThe problem, before the solution is named.
   • Backlog managementOne list, one order, and a reason a new item has to earn its place.
   • Product-market fitThe sign that the right people want this, not that a demo went well.
   • Product roadmapA sequence of outcomes, not a catalogue of features.
   • Real optionsThe choice you can delay until you know more.
   • ReviewsShow the slice to the person who will use it.
   • RiskWhat could make this slice fail, and what you will do about it.
   • SpikesA short investigation when the team cannot estimate honestly.
   • Stakeholder mapsWho decides, who uses it, and who can block it.
   • Story mappingThe journey across the top, the slices underneath.
   • Value modellingWho gains, and how you would know.
   • Value propositionThe promise, the pain it replaces, and the gain.
   • Value streamThe wait between the request and the thing the user gets.
   • VisioningA picture of the product the team can repeat.

7. Module 7

   Capstone

   One product, from the problem to a backlog you can defend.

   • The problem and the visionWho it is for, and what will be true if this works.
   • Objectives and the number you will watchOne result, and the measure that would change your mind.
   • Order the backlogWhat is next, what waits, and the conflict you had to settle.
   • The smallest release and the roadmapYou present it. The room tells you what is still a guess.