Module 1, Lesson 2: Understanding the Process

Where We Are in the Course

We're on Module 1, Lesson 2. Here's where we've been:

• Module 1, Lesson 1: What You'll Need — we covered who this course is for, what you should already know, and got all your tools installed and ready.

In this lesson, I'm not touching any tools yet. This one is all mindset and process — I want to show you the full pipeline we're going to work through before we start running. Trust me, this is worth the few minutes it takes.

Before We Start

From previous lessons:

• You should have all your tools installed and accounts set up from Module 1, Lesson 1 — Claude Pro, Figma (desktop), YouTrack, your code editor, and GitHub.

Tools / setup you'll need:

• Nothing to open for this lesson. It's conceptual — no live demo, no tools. Just us talking through the approach.

By the end of this lesson, you'll:

• Understand why jumping straight to code is a trap — even (especially) with AI
• Know the full seven-step pipeline we're using throughout this course
• See how each phase feeds directly into the next
• Have a mental model for why we front-load the thinking

About This Lesson

Duration: ~9 minutes video + no hands-on practice required
Skill Level: Beginner
What You'll Build: Nothing yet — but you'll have a clear map of everything we're going to build together.

This lesson exists because I've seen too many people — smart, motivated people — blow up their projects before they've really started. AI has made it feel like you can skip the planning. You can't. I want to explain exactly why, and show you the system we're using instead.

Watch the Lesson

What We're Covering

Here's what I'm walking you through in this lesson:

• Why speed to code is a trap — and why AI makes this worse, not better
• The cooking analogy — a mental model for how I think about this process
• The seven-step pipeline — the full sequence we're working through in this course, from market research to shipping code
• Why the phases are in this order — each one sets up the next, and skipping steps costs you later

1. Let's Set the Scene (~0:00)

You've got your tools installed. You're ready to go. And yeah — you're probably itching to open up Claude and start building something.

I get it. I've been there.

But before we do that, I want to spend a bit of time talking about why the process matters — and why you want to slow down, take a breath, and understand why we're approaching this the way we are.

Because there's a big problem with just jumping in. Whether you're opening Claude, Cursor, or whatever tool someone on Twitter told you to use — jumping straight to code creates more problems than it solves. And in this lesson, I want to show you exactly why.

2. The Core Idea

2.1 Speed to Code ≠ Speed to Ship

Here's the thing most people don't say out loud: AI has made it very, very fast to build the wrong things.

You can sit down, write a prompt, and have something that looks fantastic running in minutes. That feels like progress. But if you haven't done any thinking upfront — if you don't know why you're building it, who it's for, or what problem it actually solves — then you're just building fast in the wrong direction.

Speed to code does not equal speed to shipping something people actually use.

And this matters more now, not less, because AI has removed the friction that used to slow people down and force them to think. You used to have to plan a bit just to write the code. Now you don't. So you have to make the choice to plan yourself.

2.2 The Cooking Analogy

I use cooking analogies a lot — fair warning. Here's one that I think nails this perfectly.

If you're going to make a good meal, you don't just walk into the kitchen and start throwing things into a pot hoping it turns out okay. You'll end up with something awful. What every good chef does is prep their ingredients first. Get everything ready. Understand what you're making. Then you start cooking.

That's exactly what we're doing here.

AI doesn't help us skip our thinking — it helps us reproduce things faster once we've done the thinking. The thinking still has to happen. We're just doing it first, where it's cheap, instead of later, where it's painful.

2.3 The "Vibe Coding" Trap

You're here because you want to build something meaningful. Not "slop" — not another thing that got half-assembled in an afternoon because someone said you could make money with a prompt. You want to build something that actually ships and that people actually use.

The people who end up with apps that matter plan like product managers and build like founders. That's what this course teaches you to do.

3. The Pipeline (~4:07)

Okay — enough of the why. Here's the what.

We're going through seven distinct steps in this course. Not because I want to make your life complicated, but because each one feeds directly into the next. Skip one, and the thing downstream wobbles.

Here's the full pipeline:

Step 1: Market Research

Every good founder does this first. You have an idea — great. Every idea sounds good in your own head. But does anyone actually care? Will anyone pay for this?

This is where we figure out: should we build this at all? Where's our angle? Where's the opportunity? What's already out there, and what gap can we fill?

Step 2: Documentation

Once the research is done, we document what we found. We're going to produce a research summary, a PRD (product requirements document), and a go-to-market summary — all grounded in real data from the research, not assumptions.

This matters even if you're building solo. If you ever need to explain your product to an investor, a co-founder, or a new team member, having this written down is invaluable. And it keeps you honest about what you're building and why.

Step 3: User Journey Mapping

Now we put on our product design hat for a bit. Before we write a single spec, we map out what the journey of a user actually looks like — from the moment they first hit the product through to when they get value from it.

We'll use FigJam for this (which is why you need the Figma desktop app — more on that when we get there). This is also where you'll get your first look at something I'll be using a lot: model context protocol, or MCP. Claude will be writing directly into FigJam for us.

Step 4: Feature Requirements & RICE Scoring

Now we get specific about what we're building. We write user stories, score them using the RICE framework (Reach, Impact, Confidence, Effort), and prioritise which features to tackle first.

This is a well-established product management approach — and it's not as complicated as it sounds. When you know the framework, you know exactly what questions to ask the AI, and let it do the heavy lifting on the scoring. That's the pattern you'll see throughout this course.

Step 5: Implementation Roadmap

Once we know what to build and in what order, we turn that into a phased delivery plan. This is how engineering teams work every day — batches of work, done step by step, delivered incrementally.

This isn't about slowing you down. It's about making sure that when you're building, you always know what "done" looks like for each piece. That's what makes you able to actually ship.

Step 6: Project Planning in YouTrack

We take everything we've built — the research, the docs, the specs, the roadmap — and we structure it into a project management board. Epics, stories, acceptance criteria, testing criteria.

This is where it all becomes a proper backlog that you (or anyone you're working with) can actually execute against. And it's what sets us up for the coding phase.

Step 7: Coding the Project

Now we build. Issue by issue, story by story. Claude Code does the writing — you're the QA. You know what "done" looks like for each issue because you defined it in Step 6. So your job is to walk through what got built, test it against the criteria, and confirm it's right before moving on.

This is why this isn't a beginner course. You need enough background to know what good looks like — because you're the one who decides if it ships.

4. Why This Order Matters

These steps aren't arbitrary. Each one is the input for the next:

• Research → informs Documentation
• Documentation → informs the User Journey
• User Journey → informs Feature Requirements
• Feature Requirements → informs the Implementation Roadmap
• Roadmap → populates the Project Board
• Project Board → drives the Coding phase

If you skip or rush any of these, the downstream steps get weaker. And by the time you're coding, you're guessing. We don't want to be guessing.

5. The Goal

When we follow this process, here's what it gives you:

You plan like a product manager. You build like a founder. You ship like you mean it.

Not another half-finished side project. Not another thing that runs on localhost and never sees the real world. Something that gets out the door, makes sense to real users, and you can actually stand behind.

That's what this pipeline is built to produce.

The Short Version

Here's what I want you to take from this lesson:

• Speed to code ≠ speed to ship. AI has made it fast to build the wrong things. Planning upfront is how you avoid that.
• Prep before you cook. Every phase we go through is an ingredient. We prep it all before we start coding.
• The seven steps are sequential for a reason. Each one feeds the next. Don't skip ahead.
• What you can do now: You know the full map. When we start Module 2, you'll know exactly where we are in the process and why.

Quick Reference

The Seven-Step Pipeline

1. Market Research        — validate the idea before you invest in it
2. Documentation          — turn research into foundational product docs
3. User Journey Mapping   — map the user experience before writing specs
4. Feature Requirements   — write user stories, score with RICE, prioritise
5. Implementation Roadmap — phase the work into a delivery plan
6. Project Planning       — build the board in YouTrack, ready to execute
7. Coding                 — build issue by issue, you're the QA

Key Mental Models

• Speed to code ≠ speed to ship — AI makes it fast to build wrong things
• Prep before you cook — front-load your thinking, not your code
• Each phase feeds the next — the output of one step is the input of the next

Resources

Frameworks & Tools Referenced

• RICE Scoring — Reach, Impact, Confidence, Effort — product prioritisation framework (we'll go deep on this in Module 3)
• FigJam — used for user journey mapping in Module 2, Lesson 3
• YouTrack — project board we set up in later Module 3

Questions I Get Asked

Q: Do I really need to do all seven steps? Can't I just start with a rough idea and iterate?

I hear this one all the time. You can skip steps — plenty of people do. But the reason we're here is to build something that actually ships and matters. The research and planning phases are precisely what separates things that ship from things that stay on localhost forever. The investment upfront is small compared to the rework you avoid later.

Q: This feels like a lot of process for a solo founder. Is this really necessary?

It scales down fine. You're not writing hundred-page PRDs — we're using AI to do the heavy lifting on all of this. What we're doing is making sure you think through the right questions before you start building. Even solo, that discipline pays off. Especially solo, actually — because there's no one else to catch your blind spots.

Q: How do I know I'm ready for the next lesson?

If you understand the seven steps and why they're in that order, you're good. Module 2, Lesson 1 is where we get into Market Research — the first step in the pipeline. That's where the over-the-shoulder work begins.

💬 Stuck? Come Talk to Us

Glossary

RICE Scoring: A product prioritisation framework — stands for Reach, Impact, Confidence, and Effort. Used to score features against each other so you can make data-driven decisions about what to build first. (we go deep on this in Module 3, Lesson 6 — Feature Requirements & Implementation Roadmap)

MCP (Model Context Protocol): A way of extending Claude's capabilities so it can interact directly with other tools — like writing into FigJam or your project repo. (first used in Module 2, Lesson 3 — User Journey Mapping)

User Story: A way of writing a feature requirement from the user's perspective — "As a [type of user], I want to [do something] so that [I get this outcome]." (introduced in Module 3, Lesson 6)

PRD (Product Requirements Document): A foundational document that describes what the product is, who it's for, and what it needs to do. (we produce this in Module 2, Lesson 2 — Documentation)

Vibe coding: Building an app by prompting an AI without any upfront planning or thinking — going purely on instinct and iteration. Fast, but usually produces things that don't ship or don't matter.