Building a Product Team

You don't ship the product. Your team does. Sure, you'll get your hands dirty now and then, a spec here, a flow sketched on a whiteboard, a fix pushed late at night. But the real thing gets built by the people you lead. So the most important thing a product leader builds isn't a feature, a spec, or a roadmap. It's the team that builds everything else.

The best thing I ever built was a team. I grew one from five people to twenty-six and within a few months we were running the largest digital initiatives the company had on that continent. Product managers, strategists, designers, tech leads, engineers, data scientists. We didn't pull that off because I was the smartest person in any room. I wasn't. We did it because the team was built on a purpose.

That team had a purpose. Own its outcomes instead of its output. Do the research. Get on the road and meet with Customers and Stakeholders. We didn't sit around waiting for someone upstairs to hand off a solution to go build.

None of that happens on its own. Because that's not the way most organizations are set up. Sometimes you get lucky and they are. But when you're the one building a team, it comes down to 4 crucial components: who's on the team, why they're there, how much room you give them, and whether they ever actually become a team. Take them in order.

Right people, right seat

Jim Collins said it best in Good to Great: first who, then what. Get the right people on the bus, and the right people in the right seats, before you decide where you're driving. Most leaders do it backwards. They lock the destination first, then staff toward it, and end up dragging the wrong people somewhere none of them believe in.

The right people are the ones who embody what the team stands for. The ones you actually want in the room. The ones who share the values and clear the bar you've set, and who make the people around them better just by being there. The right seat is the other half of it: each person working from their strengths, in a role that fits them, instead of grinding against one that doesn't. A brilliant engineer you've shoved into running a roadmap isn't a bad hire. They're a good person in the wrong seat, and that's on you to fix.

One honest caveat Collins glosses over: you almost never get to build a team from scratch. Most of the time you inherit one, with its history, its habits, and its existing seats. So "right people, right seat" isn't a hiring event you run once and forget. It's a constant adjustment. You move people toward their strengths. You keep raising the bar. And yes, sometimes you have to cut someone. A truly toxic person is a cancer on a team. Leave them alone out of politeness and they spread, until your best people are the ones eyeing the door. Cut them out before they turn the rest of the team. Do it with respect. But do it.

Hire on the why, not the what

When I built that team, I didn't sell the people I hired on the job. I sold them on the mission.

The company existed to help farmers grow more food on less land, safely and sustainably. My own why sat right on top of that: I build great teams and culture so my teammates can build the tools that help farmers feed the planet. That was the pitch. If a candidate lit up at it, I kept talking. If they didn't care about the mission, they weren't going to care about the work either, no matter how good the resume looked. So I moved on.

People don't commit to a what. They commit to a why. Simon Sinek built a whole book, Start With Why, around exactly that idea, and hiring is the place I've watched it matter most.

Here's the clearest version of it I know. Picture a help-wanted ad for a job at McDonald's. You could write it the honest, literal way: flip burgers, run a register, mop the lobby. All true, and nobody you want walks through the door. Or you could write the same job as what it actually is. You help families make memories. The birthday party in the corner booth. The stop on the road trip. An ice cream cone with someone special. Early Sunday breakfast with your grandparents. Same flattop griddle. Same wage. Same job, down to the task list. But one version gets you a person already counting down to their break, and the other gets you someone who cares. You didn't change the work. You changed the why, and the why changes who shows up for it.

Give them room, then get out of the way

Hiring the right people is the easy half. Here's where most managers quietly undo all of it. They bring in great people and then micromanage them into mediocrity. They hire someone for their judgment, then never once let them use it.

So when someone joined my team, I told them the same thing on day one. You have the autonomy to do your job. I hired you for your judgment, so use it. We run as a data-driven team, which means if you push back on an idea without data, the data wins, every time. But the data can come from anyone. A brand-new hire who shows up with evidence can change how the whole team works, mine included. That's the deal.

Then I cleared their path so they could actually do the work. I called it snowplowing. I killed the useless meetings before they ever hit a calendar. I kept my people off the low-value projects that would have eaten their week. I made sure their managers and peers knew exactly how much value they were adding, and I funded whatever they needed to do the job right. These days that means AI. I require it on my teams now, every new hire reads my guide during onboarding, we run a real usage policy, and we hold each other accountable to our individual growth and understanding of how AI works. My job, all of it, was to remove what stood in the way of them doing great work.

Then came the hardest part: I let them own the call, even when I would have made a different one. They got the credit when it went well. I took the hit when it didn't. One of my tech leads said something on my last day that I still think about. "For months I couldn't tell if you were lazy or if you just had ultimate trust in me. Either way, I did more in six months working for you than I did in three years at my last company." That is what room does to a person. I wasn't lazy. I just knew how smart he was and I wanted to let him shine.

None of this works without safety underneath it. If people believe one failure will cost them their job, they stop taking risks, and a team that won't take risks will never build anything new. Most teams that struggle with agile don't actually have a tools problem or a process problem. They have a fear problem. So I didn't punish failure. I asked for experiments. The faster a team is allowed to try something, learn from it, and adjust, the better the work gets. Fear is the thing that quietly kills a product team, and it's the leader who lets it in the door.

Make it a team, not a group of coworkers

Do all of that and you'll have a group of talented, productive people. That still isn't a team. People who only work alongside each other stay a group of coworkers. The teams that do the best work of their lives actually care about each other. You build that on purpose, too.

The way we built it was something we called Appreciation Friday. I stole the idea from Amy Poehler, by way of Parks and Recreation. Every Friday, at the beginning of standup, we went around the room and everyone shared something specific someone else on the team did for them that week. Not a vague "good job, everyone." A real, named, here-is-exactly-what-you-did thank-you. It sounds small. It wasn't. People would dial in on their day off just to be part of it.

On my last day with that team, I sat there and watched them run it without me, and I teared up. Not because of what we'd shipped, though we shipped plenty. Because I knew I'd built the exact thing I set out to build: a team that felt trusted, cared for, and genuinely inspired to do work they were proud of. That was the real product. Everything we shipped was just the evidence it was working.

The team is the work

Build the team this way and everything downstream gets easier. The right people, in the right seats, hired on a mission they believe in, trusted with real autonomy, safe enough to take a risk, and close enough to fight for each other. A team like that will out-think and out-build any group of individuals you bolt onto a project and call a team.

That is the job. Not being the best product manager in the building. Building the team that makes the best product, and then trusting it to.

Growing each person on that team, coaching them, stretching them, multiplying what they're capable of, is its own discipline, and it's big enough to have its own page. Coaching & Multiplying gets into it. But all of it starts here, with the team you choose to build.