Understand the teams that build tech products and how they work together.
Goal: Understand the teams that build tech products and how they work together.
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.
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."
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.
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.
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:
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.
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:
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.
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.
…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.
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.
Pick any app you used today and walk it once around the loop in your head. What problem does it solve, and for whom (Discovery)? Name one tiny feature that looks like it was added later, after launch (a sign of the loop in action). Then guess which role you'd most enjoy on its build team — PM, Designer, Engineer, QA, or Analyst — and write one sentence on why. That last sentence is the seed of your own pivot story, the same move Davor used to talk his way from accounting into data.
Preparing your quiz…