Topic 4 — How tech companies and teams work

Goal: Understand the kinds of tech companies and where the PM sits inside a team.

Lesson 4.1 — Two very different kinds of "tech company"

In her first week, Maya assumed every tech company looked basically like Lumi: a small crew building one app, arguing about a loading screen, shipping it to the world. Then a friend told her about her job, also "in tech," and it sounded nothing alike. Her friend's company got hired by a bank to build the bank's app, handed it over, took the fee, and moved on to the next client.

Same industry, two different animals.

Lumi is a product company. It builds and owns its own product, the budgeting app, and lives or dies by whether people keep using it. Maya's friend works at a services company (also called outsourcing): they build software for other companies for a fee, then move on.

The difference matters to you for a simple reason. A PM's job is to own a product over time — to learn what users need, decide what comes next, and watch it grow. That mostly exists in product companies. A services shop is usually steering toward whatever the paying client asked for, so there's less of a long-running product to own.

Most PMs live in product companies, because that's where there's a product to own.

When you read a job ad later, this is the first thing to spot: is this team building their own thing, or building other people's things for hire?

Lesson 4.2 — Startup, scale-up, Big Tech: same title, different day

Lumi has twelve people. The CEO sometimes pings Maya with a half-formed idea about an "AI assistant" before anyone's checked whether users even want it. Maya does a little of everything: she writes the spec, chases the bug, sits in on a sales call. Some days that's thrilling and some days it's chaos.

That feeling has a name. Lumi is a startup — small, still searching for what actually works, lots of uncertainty, and PMs wearing many hats because there aren't enough hands for narrow roles.

Picture the next chapter. The budgeting app catches on, money comes in, the team jumps to eighty people. Now it's a scale-up: someone found something that works, and the whole company is racing to grow it before a competitor copies it.

Then there's Big Tech — the large, established giants. Hundreds or thousands of people, roles sliced thin (a PM might own only the sign-up flow), and a lot more process before anything ships.

None of these is the "best" place to be. They suit different people at different moments. For a career-changer like Maya, smaller companies are often the more open door — a scrappy startup tends to care more about whether you can think clearly than about which university you attended.

Lesson 4.3 — Who's the customer? B2B vs. B2C

Dan from sales bursts into the room: "I just lost a deal because we don't have an Excel export. We need it this quarter." Maya nods, then catches herself wondering — one customer killed a whole deal over that? At Lumi, where thousands of individuals each pay a few dollars, no single person has ever blocked anything.

The gap she's sensing is who the product sells to, and it quietly reshapes the entire job.

B2C means business-to-consumer — selling straight to individuals. A music streaming app. Lumi's budgeting app. There are millions of users and no single one of them can make or break you, so decisions get driven by data, design, and behavior at scale. A B2C PM leans on analytics and experiments (you'll meet those in Topics 9–10) more than on any one conversation, because the truth lives in the patterns.

B2B means business-to-business — selling to other companies. Think of software a hospital buys for its whole staff. Here there are fewer, much larger customers, the sale is long and built on relationships, and the buyer keeps asking one question: will this give us a return on our investment? A B2B PM talks often to a handful of important clients, and constantly weighs what one big customer demands against what's good for everyone else.

A few companies are B2B2C: they sell to a business, and that business serves the consumers. Either way, knowing which world a product lives in tells you how to do discovery and which numbers to trust. Always pin it down first.

Lesson 4.4 — Maya doesn't decide alone: the product trio

When the CEO's "AI assistant" idea landed, Maya's instinct was to go figure it out and come back with a plan. Sam, a senior engineer, stopped her: "Before you spec anything, let's all look at this together." Priya, the designer, pulled up a sketch. Sam pulled up what the system could and couldn't actually do. Maya brought the question of whether users would pay for it.

That little huddle is the heart of how good product teams work. It's called the product trio:

• Product Manager — what to build and why it's worth doing (value and viability).
• Designer — how it looks, feels, and whether real people can use it (UX).
• Tech Lead / Engineer — how it gets built and whether it's even feasible (the technology).

Remember the three lenses from Topic 1 — valuable, usable, feasible? The trio is those lenses with faces on them. Maya champions valuable, Priya champions usable, Sam champions feasible, and the important calls get made by the three of them together rather than handed down by Maya.

Around that core sits the wider team: more engineers, a QA tester who hunts for what's broken, and partners in marketing, sales, support, and data. But the trio is where the big decisions get shaped.

Lesson 4.5 — Where the PM actually sits: the hub

Maya can't order Sam to build anything. She can't tell Priya how to design. She can't command sales or leadership. And yet, if the budgeting app misses its goal this quarter, the question lands on her desk. That gap surprises almost everyone new to the role.

A PM is a hub — connected to almost everyone, in charge of almost no one.

• Up to leadership, the executives who set the company's direction and expect results.
• Across to design, engineering, marketing, sales, support, and data.
• Out to customers and the users actually living inside the product.

The phrase people reach for is "CEO of the product." It's a useful half-truth. In terms of responsibility, Maya really is the CEO of the budgeting app: she owns whether it succeeds. In terms of power, she's nothing of the kind. She can't make anyone do anything.

You own the outcome, but you can't command a soul. So you lead through communication, not authority.

That's why, of every skill in this course, communication is the one that decides whether you're good at this. Your real job is to make it easy for a room full of people you don't manage to do their best work toward the same goal.

Worked example — Same feature, opposite priority

A customer writes in asking for "single sign-on (SSO) login" — the option to log in using an existing account, like signing in with Google instead of making a fresh password. Should the PM build it? Watch how the answer flips depending on the company.

At a B2C music app with millions of users, the PM reaches for data. How many people abandon sign-up at the login step? Would SSO measurably lift the number who finish (the kind of question Topic 9 is all about)? If only a sliver of users drop off there, SSO is nice-to-have and sits low on the list. The crowd decides.

At a B2B company selling to large enterprises, the same request can be a deal-blocker. One major client's security team requires SSO before they'll sign — no SSO, no contract, possibly a six-figure one. So it leaps to the top of the roadmap even though it technically helps "only one" customer.

Same feature. Opposite priority. Nothing about the feature changed — the company and customer type changed what "valuable" even means. Reading that context, before touching the roadmap, is the PM's job.