Topic 3 — How tech products are built

Goal: Understand the teams that build tech products and how they work together.

Lesson 3.1 — Who actually builds the thing

Teo Vrabie spent eight years in front of a classroom. When she opens the careers page at Brightwell — the 40-person edtech startup whose study-planner app she's hoping to join — she sees a wall of job titles she can't tell apart. Product Manager. Frontend Engineer. UX Designer. QA. Data Analyst. Her first thought is the same one she had grading a stack of unfamiliar essays: where would I even fit in this?

So she does what she'd tell a student to do. She asks for help. Bao Trinh, a senior PM at Brightwell, agrees to a half-hour call, and Teo writes down the core build team — the small group of people who turn an idea into working software.

• Product Manager (PM) — owns what to build and why: the priorities, the roadmap, the case for spending the team's time on this and not that.
• UX/UI Designer — owns how it looks and works: the screens, the flow, whether a stressed student can find the "add assignment" button without thinking.
• Engineers / Developers — build it in code. They split into two camps: frontend (what the user sees and clicks) and backend (the behind-the-scenes logic and data that make it actually do something).
• QA / Testers — catch bugs before users do, by trying to break the thing on purpose so a real student never hits the broken bit.
• Data Analyst — measures how it's doing: who's using the feature, who quietly drops off, whether the numbers moved.

Six roles, one product. No one of them ships it alone — that's the whole point of the topic.

Bao draws a circle around those six on Teo's notepad. "That's the engine," he says. "Now let me show you the rest of the car."

Lesson 3.2 — The ring around the build team

Brightwell has 40 people, and Teo just accounted for six of them. So who are the other 34?

They're the go-to-market and support ring — the roles that get the product into the world and keep customers happy once it's there. A beautifully built app that nobody hears about, can't buy, and can't get help with is a hobby, not a business.

• Marketing — creates demand and awareness so schools and students even know Brightwell exists.
• Sales — closes customers, especially the school-district deals that pay the bills.
• Customer Success / Support — keeps and helps the customers you already have, so a frustrated teacher gets answered instead of cancelling.
• People / Recruiting — hires everyone above. This is Renske Aldous, the in-house recruiter who will eventually read Teo's resume.

Teo notices something on the call. Bao keeps saying "we." When the team shipped a new calendar sync last quarter, we did it — and "we" meant the designer, two engineers, a tester, the analyst who flagged the problem, plus marketing and support who carried it the last mile.

A product is a team sport. The reason this matters for a career-changer is plain: you don't have to be the engineer to belong here. Every one of these roles is a real job, and most of them (each has its own track on this platform) don't require you to write code.

Lesson 3.3 — How modern teams work: agile

Teo asks Bao the question that's been nagging her: so does someone plan the whole app, then everyone goes and builds it for a year?

Bao laughs, kindly. "That's how it used to work. It went badly."

The old way — plan everything up front, disappear for a year, unveil the finished product — kept failing because by the time the product appeared, customers wanted something else. Markets move. Needs shift. A study app that made sense in September might be wrong by the next school year.

So teams switched to agile: build in small steps, get feedback often, and adapt. Instead of one giant reveal, the team ships a little, learns from real users, and adjusts — over and over.

In practice at Brightwell, that looks like three habits:

• Work runs in short, fixed cycles — one to four weeks, most commonly two — where the team commits to a small chunk of work. These cycles are called sprints.
• The team releases small improvements frequently rather than saving everything for one rare, terrifying launch.
• They continuously learn from real users — what they clicked, what they ignored, what they complained about — and feed it back in.

Agile is a habit, not a tool you install: build in small loops so you can change your mind when reality says you should.

Marisol Ferreira, Brightwell's founder and a former teacher herself, puts it to investors in one line: "We'd rather be roughly right every two weeks than perfectly wrong once a year." For a company burning Series A money, guessing wrong for twelve months is the thing that kills you.

Lesson 3.4 — Scrum, in plain words

When Teo shadows a Brightwell standup over video, she hears a vocabulary she half-recognizes from agile but not quite. The team has a specific flavor of agile with a name: Scrum, the most popular way teams put agile into practice. Scrum gives the loose idea of agile a set of named roles and meetings so everyone knows the routine.

Four words carry most of it:

• Product Owner — owns and prioritizes the backlog. Decides what the team works on next. (At a small company this is often the same person as the PM.)
• Scrum Master — keeps the process healthy and removes blockers so the team can move. Often described as a servant-leader: their job is to clear the road, not to boss people. If an engineer is stuck waiting on access to a database, the Scrum Master is the one chasing it down.
• Backlog — the prioritized list of work, top to bottom. The team pulls from the top.
• Daily standup — a roughly 15-minute check-in, usually each morning. Each person answers three things: what I did, what I'm doing next, and what's blocking me. It's short on purpose; the long debates happen afterward, with only the people who need them.

That's it. That's most of what people mean when they say "we run Scrum." Teo notices the standup she watched lasted eleven minutes and nobody sat down. When Davor Halász — a fellow career-changer, an ex-accountant now a junior data analyst one step ahead of her — texts her "how was the standup?", she can answer like an insider: short, three questions each, one person flagged a blocker, done.

You don't need to memorize a certification. You need to walk into a room, hear "what's blocking you?", and know exactly what's being asked.

Lesson 3.5 — The lifecycle loop, and where you plug in

Teo wants the one picture that ties it all together. Bao gives her the product lifecycle — the path every product and feature travels, again and again.

1. Idea / Problem — a problem shows up, from a user complaint, a number, or the business.
2. Discovery — is this a real problem worth solving, and for whom? (Plenty of "great ideas" die here, cheaply, which is the point.)
3. Build — designers and engineers make it, in small pieces.
4. Launch — it goes out to real users.
5. Learn — measure what happened, gather feedback…

…and the learning becomes the next idea. It's a loop, not a straight line. Good products are never "finished" — they keep circling this cycle, getting a little better each lap.

This is also where the MVP (Minimum Viable Product) lives. An MVP is the smallest version you can release to learn whether an idea actually works. Brightwell didn't build a full parent-dashboard before testing demand; they shipped a bare version to a handful of schools to see if anyone cared. They didn't. Three months saved. The whole reason MVPs exist is to learn fast and avoid spending months building the wrong thing.

Now the payoff for Teo. Every role she wrote down plugs into this same loop somewhere. A Data Analyst lives mostly in Learn. A Designer lives mostly in Build. A PM rides across the whole loop. Marketing and Sales cluster around Launch. Once you can see the loop, you can answer the question that started this topic — where would I fit? — and you can also see how your work hands off to the person beside you. That's what makes someone a useful teammate on day one, before they know anything else.

Worked example — One feature through the whole machine

Brightwell decides to add reminder notifications so students get a nudge the night before an assignment is due. Watch the team and the loop work together.

It starts in Idea / Problem: the Data Analyst, living in Learn from the last cycle, spots that students who miss one deadline tend to stop opening the app entirely. Bao, the PM, takes that to Discovery — he talks to a dozen students and confirms the real problem is forgetfulness, not laziness. Worth solving.

Now the build. Rather than ship a full notification center, Bao scopes an MVP: one plain "you have an assignment due tomorrow" push, nothing more, just enough to test whether nudges actually bring students back. The Designer mocks up the message and timing. In the next two-week sprint, the team pulls the work off the top of the backlog. A backend engineer builds the logic that knows when to send; a frontend engineer builds what the student taps. At the daily standup, the backend engineer flags a blocker — she's waiting on a third-party push service — and the Scrum Master spends the afternoon getting it unblocked. QA tries to break it: what if two assignments are due the same night? They find that bug before any student does.

It launches to a slice of schools. Then Learn: the Data Analyst measures whether nudged students return, while Support watches for "stop spamming me" complaints. The numbers come back positive, so the result feeds the next idea — maybe let students choose their reminder time. Around the loop again.

One feature. The whole build team, the support ring, the agile cycle, and the lifecycle loop — all in one trip. That's how tech products actually get built.