Wider Systems
When I made the jump from engineering to product, my brain itched constantly. Still does pretty often.
As an engineer, I spent years solving systems. Designing automated machinery and robotic manufacturing cells. Writing software that coordinated machines and people on factory floors. The problems were complex, but they had boundaries. Inputs, outputs, constraints, solutions. You could hold the whole thing in your head and reason through it.
Product management felt like someone removed the boundaries and told me to keep going. I found myself wanting to jump straight to architecture to solve problems. My instinct was to hear a problem and start sketching the system that solves it. That instinct isn't wrong, exactly. It's just incomplete.
My big epiphany was that PMs solve systems too. They're just wider systems. The user's needs and constraints are part, but we also need to think about business stakeholders, business strategy, market dynamics, user psychology, cross-functional incentives, opportunity costs, timing, the iron triangle, and a bit of wabi sabi. Engineering gave me the habit of systems thinking. Product taught me where the system actually starts and ends.
Building the Collection
That realization didn't all come from a book (though there are many fantastic product books out there, which I will list in a separate article). It came primarily from getting things wrong, watching things work, and slowly building up a mental library of approaches for different situations. Every framework I internalized, every hard conversation I navigated, every launch that went sideways and taught me something. I started thinking of each one as a tool I was adding to a toolkit.
That metaphor stuck because it captures something important about how product work actually functions. There is rarely a right answer. There are almost always multiple tools that could get the job done. The skill isn't knowing one framework really well. It's having a broad enough collection that you can pattern match a situation to the right approach, and then apply it with enough context to make it useful.
The Real Skill
This is how I frame things when I mentor people who are transitioning into product or leveling up within it. I don't tell them "use this framework." I tell them "here are three tools that could work, here's how I'd think about choosing between them." Because that's the real capability. Not the tool itself, but the judgment to select and wield it.
What This Is
That's what this toolkit is.
It's the collection I've built over years as a manufacturing engineer, full stack developer, and finally product manager across the factories, blockchain platforms, game economies, and now a 3D printing marketplace. Each piece includes not just the framework, but the context around it: when to use it, when not to, and what it looks like in practice.
Who It's For
I wrote it for three groups of people.
- For anyone trying to break into product management who wants to understand how experienced PMs actually think, not just what templates they use.
- For my peers and collaborators, so we can share a common language around frameworks and work together more effectively.
- For fellow product people who enjoy sharpening their thinking the same way I do: by pressure testing ideas and learning from how others approach the same problems.
That last group is part of why I'm writing this publicly. I have a lot of opinions about product craft, and I know the best way to refine them is to put them out there and invite people to push back. So please do. Tell me what resonates, tell me what's wrong, tell me what I'm missing. That's how these ideas get sharper, and how I get better.
I hope it's useful. And I'd genuinely love to hear what you think.