Project & Product Management

Welcome to Project & Product Management at Kaern Schools. I'm Iris, your tutor. I've spent years shipping real products at cycleX — from the first scribbled idea to the version customers actually pay for — and that scar tissue is what this course is built on. Theory is cheap; shipping is hard.

Who this is for: You're founders building Kaern startups. Not someday — now. You have a company, a team (some of whom are AI agents), and customers who don't care about your roadmap unless it solves their problem.

Outcomes: By the end, you'll be able to translate a fuzzy idea into a prioritized roadmap, run sprints that actually finish, direct AI agents like a real team, keep stakeholders aligned, and ship with metrics that tell you whether you're winning. You'll graduate with a capstone: a real product plan you could execute Monday morning.

This is a workshop, not a lecture hall. I'll talk, you'll build, we'll critique each other's work out loud. Bring something you're actually working on. Let's get to it.

Module 1: Product Thinking & Roadmaps

Learning objectives

• Distinguish between outputs (features) and outcomes (customer problems solved).
• Write a product vision and a one-line problem statement.
• Build a roadmap organized around outcomes, not a feature checklist.
• Explain why a roadmap is a hypothesis, not a promise.

Lessons

Lesson 1.1 — Outputs vs. Outcomes

Teaching script: Let me tell you about the cycleX dashboard nobody asked for. Early on, our team was proud of a beautiful analytics screen — twelve charts, real-time everything. We shipped it. Usage: near zero. Why? Because customers didn't have a "I lack charts" problem. They had a "did my order ship?" problem. We built an output when we should have chased an outcome.

Think of it like a drill and a hole. Nobody wants a drill. They want a hole in the wall — actually, they want a shelf, actually they want a tidy room. Features are drills. Outcomes are the tidy room. When you describe your product as a list of features, you're selling drills to people who want shelves.

The discipline of product thinking is constantly asking "and then what does the customer get?" until you hit something they'd genuinely pay for. Every feature on your roadmap should trace back to a customer outcome. If it can't, it's a drill looking for a wall.

So here's my question to you: take the last feature you built or wanted to build — can you name the customer outcome it serves in one sentence, without using the feature's name?

Lesson 1.2 — Vision and the Roadmap as Hypothesis

Teaching script: A roadmap feels like a contract — dates, deliverables, signatures in spirit. But treat it that way and it becomes a prison. At cycleX, our first roadmap was a Gantt chart twelve months deep. Month three, the market shifted, and we spent more energy defending the chart than serving customers. Painful lesson.

A better mental model: the roadmap is a series of bets. "We believe that if we solve X for segment Y, they'll do Z." Each item is a hypothesis with a confidence level, not a guarantee carved in granite. Near-term items are high-confidence; far-term items are blurry on purpose, because you don't yet have the learning to sharpen them.

This is why I organize roadmaps by themes and outcomes — "reduce time-to-first-order" — rather than features with fixed dates. It keeps the team pointed at the problem while staying free to change the solution. The vision is the fixed star; the roadmap is the route, and routes get rerouted.

Here's what I want you to sit with: if a competitor shipped your entire roadmap tomorrow, would your customers' lives actually be better — or would you just have more features? What does that tell you?

Worked example

cycleX wanted to "add a referral feature." We reframed it as an outcome: grow new signups from existing happy users by 15% per quarter. That reframing changed everything. Instead of jumping to "build a referral code system," we mapped three hypotheses: (a) happy users will refer if asked at the right moment, (b) the right moment is just after first successful order, (c) a small reward beats no reward. The roadmap entry became "Outcome: referral-driven growth — Q2 bet: post-order referral prompt." We shipped a dead-simple email ask first (no code system), validated hypothesis (a), and only then built the full feature. We saved six weeks by testing the cheapest version of the bet first.

Hands-on exercise

Take your current product or idea. Write: (1) a one-sentence vision, (2) a one-line problem statement in the form "[customer] struggles to [outcome] because [obstacle]," and (3) three roadmap items expressed as outcomes, each with a confidence level (high/medium/low) and the single riskiest assumption behind it. Bring it to share.

Common mistakes

1. Feature-list roadmaps. A column of features with dates is a to-do list, not a strategy. It hides the why.
2. Treating the roadmap as a promise. Defending the plan instead of serving the customer when reality changes.
3. Skipping the problem statement. Jumping to solutions before you can articulate, in one sentence, whose pain you're removing.

Check for understanding

1. Rewrite "add dark mode" as an outcome statement. What customer problem might it actually serve — and how would you check?
2. Why do I describe far-term roadmap items as deliberately blurry?
3. What's the difference between a vision and a roadmap?