The Full Stack PM
I have always believed in the idea of the full stack product manager.
Not because one person should do everyone’s job, but because product work does not respect org charts. Products fail and succeed in the gaps between roles, and when those gaps exist, someone has to step in and own them.
Many organizations like clear distinctions: technical PMs, product owners, delivery PMs, growth PMs. On paper, it looks clean. In practice, it often creates waste. Handoffs. Waiting. Endless alignment meetings. Everyone does their part, but nobody owns the outcome.
For me, product managers should be generalists by design. A jack of many trades. Not experts in everything, but capable enough to step in, understand what is happening, and move things forward when needed.
Where this belief comes from
Part of this mindset comes from my background in industrial engineering.
When I was at university, we did not specialize early. Instead, we were given a wide set of 101-level courses: mechanical engineering, electronics, software development, operations research, statistics, economics, systems design.
The goal was not to turn us into experts in all of these fields. The goal was to give us a shared language.
So that if, later in our careers, we worked in a factory, a software company, a logistics operation, or a hardware organization, we would have enough context to understand the problems, ask better questions, and communicate effectively with specialists.
That idea stuck with me.
Product management, in practice, is exactly that role. You are rarely the deepest expert in the room, but you are the person expected to connect the dots. You need a lingua franca that lets you work with engineers, designers, QA, data, marketing, sales, and leadership without everything being translated for you.
What “full stack” means in product
When people hear “full stack PM”, they sometimes imagine a superhero PM who replaces everyone else. That is not what I mean.
Full stack does not mean doing all the work yourself. It means being able to engage deeply enough in many areas to create momentum, reduce risk, and make good decisions without being blocked.
A product manager should be able to:
- Conduct deep research and synthesize insights
- Write clear product and marketing materials
- Read and write basic code
- Define test plans and execute them
- Manage projects and dependencies
- Design a reasonable UI and user flow
- Sell the product, internally and externally
Not because they will do all of these things all the time, but because they understand them well enough to:
- Know when something does not make sense
- Challenge assumptions
- Unblock teams
- Take responsibility when things fall between roles
If you cannot write the first draft, you usually do not understand the problem well enough.
Why this matters in real life
Product work is ambiguous by nature. Requirements are incomplete. Data is messy. Tradeoffs are constant.
In that environment, strict role separation creates a dangerous pattern: people optimize their own slice and push responsibility elsewhere.
The full stack PM behaves differently. When something is unclear or stuck, they do not ask “who owns this”. They ask “what is the constraint, and what can I do to remove it”.
Sometimes that means writing a spec. Sometimes it means sitting with engineering. Sometimes it means mocking a flow, calling a customer, or running a test yourself.
This is not about heroics. It is about bias toward ownership.
The common objection
The usual response is: “Isn’t this just jack of all trades, master of none?”
It can be, if done badly.
The strong version of this model is simple: Depth in product thinking, breadth across adjacent domains.
You still rely on specialists. You still respect expertise. But you are not helpless without it.
A good rule of thumb is this: a full stack PM should be able to produce a reasonable first version in almost any domain, then work with experts to make it great.
That single capability changes everything. Speed. Trust. Quality of decisions.
How this shapes how I hire
This belief strongly influences how I evaluate product managers.
I tend to prefer people who:
- Have been around and did a thing or two
- Did not start their career in product management
- Show agility of mind rather than narrow optimization
- Are humble enough to know what they do not know
- Are hungry enough to keep learning
Product management is not a title you grow into by staying inside the lines. It is a role you grow into by repeatedly stepping slightly outside your comfort zone.
People who only ever did “PM work” often struggle with this. People who came from other roles tend to understand systems, tradeoffs, and reality better.
A practical takeaway
If you want to apply this mindset, here is a simple starting point.
Pick one area where you want real depth, and deliberately build basic competence in three adjacent ones.
Enough to understand. Enough to challenge. Enough to act.
You do not need permission to learn these things. Most of them are learned by doing: writing, sketching, testing, reading code, talking to users.
Over time, this compounds. You become less dependent, more effective, and more trusted.
Final thought
Product management is responsibility without excuses.
A full stack PM is not defined by a job description, but by their willingness to step in, learn fast, and own outcomes when reality does not fit the org chart.
That is what “full stack” means to me.