In this chapter
We'll follow one real feature — seat selection — from an idea to production, meeting the product manager, business analyst, designer, developers, QA, DevOps and engineering manager along the way.
The Problem in Real Life
Late in the afternoon, Anna asks the question she's been holding all day: "How does anything actually get built here, with so many people?"
John opens the app and taps an event. A map of the venue appears, and you can pick your exact seat. "Two years ago, this didn't exist. You just got 'any seat.' Let me show you how this one feature got from Samantha's head to your phone."
Nobody here builds a feature alone. Every feature is a team sport.
John
"A Developer Builds It" vs. How a Feature Really Ships
A feature has a journey
Between an idea and a working button there are many steps, and each one has an owner.
Non-engineers matter too
Product managers, analysts and designers shape what gets built before any code exists.
Done means in users' hands
A feature isn't finished when the code is written — it's finished when customers can use it.
How a Software Team Delivers a Product
John walks through the journey of seat selection, one role at a time.
- Founder / business — Samantha noticed fans complaining: "I paid, but I got a terrible seat." A problem worth solving.
- Product manager (PM) — decided what to build and why: "Let fans choose their seat before paying." Set the priority against everything else.
- Business analyst (BA) — worked out the detailed rules: seats are held for 10 minutes, accessible seats are marked, prices differ by section.
- Designer — drew how it should look and feel: the venue map, the colours for free and taken seats, the checkout flow.
- Developers — built it: frontend developers built the map; backend developers built seat holding and pricing.
- QA engineer — tested it on many phones and browsers, and tried to break it — two people picking the same seat, a hold that expires mid-payment.
- DevOps engineer — released it safely to production and watched the system after launch.
- Engineering manager (EM) — kept the team unblocked, healthy and on track; looks after people more than code.
| Step | Role | What they produced |
|---|---|---|
| 1 | Founder | The problem: fans unhappy with random seats |
| 2 | Product manager | The decision and priority: build seat selection |
| 3 | Business analyst | The rules: 10-minute hold, sections, accessibility |
| 4 | Designer | Screens for the venue map and checkout |
| 5 | Developers | Working frontend and backend code |
| 6 | QA engineer | Test results and bugs found before release |
| 7 | DevOps engineer | The release to production, and monitoring |
Then the loop starts again: users give feedback, support reports issues, and the PM decides what to improve next. Software is never "finished" — it is delivered, used and improved, again and again.
Key Takeaway
A product is delivered by a chain of roles — problem, decision, rules, design, build, test, release — and every link has an owner. Developers are one essential link, not the whole chain.
Why This Matters
This chain is the backbone of the rest of the course. Later, Anna will meet each link up close — the code (Part 2), the systems it runs on (Parts 3–4), and the process that ties it together (Act 18) — and on Sale Day the whole chain gets tested at once.
Anna's first day ends with her notebook full and one line underlined: "BlueTicket = a team that turns ideas into running software." Before she moves on, it's time to check she can map that team on her own.