The Product Thinking Framework

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 needReal 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 needsPillar 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 experimentThe 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 featuresMeasuring 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 anyoneKey Takeaways:1. Set up Engineering Office HoursOne hour per week, open attendance for any engineerFocus on discovery, not problem-solving in the sessionAsk: "What's slowing you down?" and dig deeper with "Tell me more"Share action items within 48 hours2. Shadow your engineers quarterlySpend a full day working as an IC on your teamUse their tools, follow their processes, feel their frictionEvery minute of frustration reveals a system problem to fix3. Cut infrastructure projects into MVP experimentsTake your biggest project and cut it in half, then half againFind something completable in 2-4 weeks that teaches you somethingFocus on learning what you need, not delivering what you planned4. Measure outcomes, not outputsNOT story points, lines of code, or number of commitsINSTEAD shipping speed, learning rate, work enjoyment, retentionSometimes the best way to improve outcomes is to do less5. Iterate constantly on your teamYour team is never "finished" - it's a product requiring ongoing improvementAlways maintain a backlog of team improvementsShip small changes frequently vs. big transformations rarely(00:00) - Intro (01:03) - Title (01:45) - Engineering Teams as Products (05:32) - Product Discovery for Engineering (11:11) - MVP Approach to Infrastructure (16:55) - Iterative Improvement in Engineering (22:32) - Addressing Common Objections

There are no comments yet.

Please log in to write the first comment.