Most engineering leaders would fail miserably as product managers. They'd get fired for shipping features nobody wants, ignoring user feedback, and measuring the wrong things. But here's the thing - your engineering team IS a product. And the techniques you use to build great products are exactly what you need to build a great engineering organization.
In this episode, I break down the Product Thinking Framework: a radically different approach to engineering leadership that will change how you think about your team forever.
In This Episode:
- Why most engineering improvements fail (and the shocking similarity to shipping features nobody asked for)
- The uncomfortable truth: Engineering leaders make decisions about tools and processes without understanding what engineers actually need
- Real story: The team drowning in infrastructure that thought they needed more people (spoiler: they didn't)
- Pillar One - Product Discovery for Engineering: How Engineering Office Hours helps you uncover what your team actually needs
- Pillar Two - Customer Empathy: Why you should spend a full day working as an IC on your own team (quarterly)
- Pillar Three - MVP Approach to Infrastructure: How to cut any project down to a 2-4 week learning experiment
- The microservices migration that would have cost millions (and what we did instead)
- The mindset shift: From manager to product manager - falling in love with problems, not features
- Measuring outcomes (shipping speed, learning, enjoyment) not outputs (story points, commits)
- Common objections: "My engineers don't know what they want," "We need long-term thinking," "I don't have time"
- Real results: The team that went from 3-day deployments to 30 minutes without hiring anyone
Key Takeaways:
1. Set up Engineering Office Hours
- One hour per week, open attendance for any engineer
- Focus on discovery, not problem-solving in the session
- Ask: "What's slowing you down?" and dig deeper with "Tell me more"
- Share action items within 48 hours
2. Shadow your engineers quarterly
- Spend a full day working as an IC on your team
- Use their tools, follow their processes, feel their friction
- Every minute of frustration reveals a system problem to fix
3. Cut infrastructure projects into MVP experiments
- Take your biggest project and cut it in half, then half again
- Find something completable in 2-4 weeks that teaches you something
- Focus on learning what you need, not delivering what you planned
4. Measure outcomes, not outputs
- NOT story points, lines of code, or number of commits
- INSTEAD shipping speed, learning rate, work enjoyment, retention
- Sometimes the best way to improve outcomes is to do less
5. Iterate constantly on your team
- Your team is never "finished" - it's a product requiring ongoing improvement
- Always maintain a backlog of team improvements
- Ship small changes frequently vs. big transformations rarely