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 checkins and gut feel.
If you’re a product person or an engineer moving into leadership, here’s a framing that makes it much more clear how you should manage and how to be successful 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, capable, 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 8 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” vs “not working”
This is easy with products. But people are messy. Why not treat people like 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 a lot of 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, conversion.
For teams, the equivalent categories are similar:
- Satisfaction: Do people actually like working here?
- Adoption: Are 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 will track everything. But often are have no idea what’s happening inside their team. You can instrument the human system:
- Regular check-ins that aren’t just status updates
- 1:1s that include “what’s working / what’s not”
- Clear expectations in writing
- Visible goals and ownership
- Team health pulse (simple, repeatable)
Not because you want bureaucracy or to be a micro-manager, but think of it as data or signal.
4) What experiments are we running?
To improve a product you run experiments. Same with teams.
Examples:
- Try a new meeting cadence for 2 weeks
- Change how decisions are made (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 harsher, 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.
