Starting My Transition to Product
For a while, I was convinced my next move was into software development. I’d spent years building internal tools and shipping MVPs alongside engineering teams, and it felt like a natural step to go deeper on the technical side. I started reading around engineering culture and delivery performance - books like Accelerate by Gene Kim, Nicole Forsgren, and Jez Humble, and The Phoenix Project by Gene Kim, Kevin Behr, and Bill Kim. Both gave me a much richer understanding of how high-performing engineering teams operate, and I’d recommend them to anyone working in or around software delivery.
But the more I read and reflected, the more I realised that what energised me wasn’t writing the code itself - it was the full picture. Identifying the problem, understanding the users, shaping the solution, and then seeing it through to delivery. I didn’t just want to build what was in the backlog. I wanted to own why it was there in the first place.
That’s what redirected me toward product.
Going Deeper on Product
Once I made that shift, I started working through some of the foundational product texts. Inspired by Marty Cagan was the first one that really clicked - it laid out clearly what good product management looks like and how empowered product teams differ from feature factories. I followed that with The Hard Thing About Hard Things by Ben Horowitz, which is less about frameworks and more about the reality of making difficult decisions under pressure. A different kind of useful.
The book I’m reading now - Continuous Discovery Habits by Teresa Torres - is the one that’s had the biggest impact so far. The structured approach to discovery, from outcome-driven thinking through to opportunity mapping and assumption testing, has genuinely changed how I think about problem-solving. It’s given me a practical toolkit that connects directly to the kind of work I want to be doing: understanding user needs deeply and making sure what gets built actually addresses them.
Bringing It Together
What excites me most is how well discovery techniques complement the delivery experience I already have. I’ve spent years running sprints, managing backlogs in Azure DevOps, and shipping iteratively through Scrum. That delivery muscle isn’t going anywhere - but pairing it with a disciplined discovery practice feels like the missing piece. The ability to move confidently from “we think this is a problem” through to “here’s the evidence, here’s the opportunity, and here’s what we’re building” is exactly where I want to operate.
I’m looking forward to applying all of this in a dedicated product or delivery leadership role, and I’ll be sharing more of what I learn along the way here on the blog.
