Many technical and product-driven founders (especially engineers) have a weird blind spot. While they can build and instrument the hell out of their product, they strangely tend to manage their people with vibes, casual check-ins, and gut feelings.
If you’re a product person or an engineer moving into leadership, here’s a framing that makes it much clearer how you should manage and succeed at it.
Your team is now your product.
I don’t mean this as a metaphor but as a management strategy.
I was talking with a CEO about one of his engineering leaders who is smart and capable with good intentions, but hit that classic wall. He was saying:
- “I don’t know if I should be director of engineering.”
- “Two people are frustrated, and I feel like I’m failing.”
- “I just want to go back to coding.”
I gave him the same advice I got from my manager at Airbnb when I was put in charge of managing eight PMs. It was to stop thinking about “managing people” and keep thinking like a product builder.
Why This Works
We all have experience with:
- Systems.
- Feedback loops.
- Metrics.
- Experiments.
- Iteration.
- Clear definitions of “working” versus “not working.”
This is easy with products, but people are messy. Why not treat people in a similar way as we treat products? Meaning:
Design → Instrument → Observe → Iterate.
What That Means, Practically
If your team is the product, you naturally start asking better questions.
1) What does “great” look like?
A product team starts with a spec; so does a leader.
- What kind of team are we trying to build?
- What behaviors do we want?
- What’s our bar for talent and attitude?
- What do we tolerate? What do we not tolerate?
This is where many leaders accidentally fall flat. They treat team shape as something that happens to them; they accept what was already there.
2) What are the core metrics?
Product builders track usage, retention, satisfaction, and conversion.
For teams, the equivalent categories are similar:
- Satisfaction: Do people actually like working here?
- Adoption: Have they bought into the direction, the standards, the operating cadence?
- Effectiveness: Are we shipping? Are we solving real problems and moving metrics? Are we getting better?
- Energy: Do people come in hot or dragged? Yes, energy is a metric. It’s just one you measure with eyes and ears instead of Mixpanel.
3) How do we instrument it?
Product people and engineers track everything. But they often have no idea what’s happening inside their team. You can instrument the human system:
- Regular check-ins that aren’t just status updates.
- One-on-ones that include “What’s working?” and “What’s not working?”
- Clear expectations in writing.
- Visible goals and ownership.
- Team health pulse (simple, repeatable).
Not because you want bureaucracy or to be a micromanager, but think of it as data or signal.
4) What experiments are we running?
To improve a product, you run experiments. It’s the same with teams. For example:
- Try a new meeting cadence for two weeks.
- Change how decisions are made (i.e., who decides what).
- Redefine roles or ownership boundaries.
- Adjust hiring bar and interview loop.
- Coach hard or cut fast based on data and standards.
Iteration is not a bad thing. If you’re not learning, you’re not doing enough.
Gut-check Questions
If you’re leading people, ask yourself:
- Do I have a clear picture of the team I’m building?
- Do I know how I’ll notice if it’s working?
- Do I have a feedback loop that gives me signal early?
- Am I running experiments, or just reacting?
If the answers are fuzzy, you don’t have a people problem; you have a product management problem. Or, even more harshly, you are the problem.
Make your people your product.
Design it. Measure it. Iterate it. Ship a better version every month.
Because, in the end, your code isn’t your company. Your team is.