You have a Product Manager. Great experience, certifications, impressive CV. Yet the backlog keeps growing, the team doesn't know what to do, and stakeholders are pulling in different directions.
The problem? Your PM might be a theory PM.
What's the difference between a theory PM and a hands-on PM?
It's not about competence. Many theory PMs are smarter, better educated, and more articulate. The problem is they talk instead of doing.
| Situation | Theory PM | Hands-On PM |
|---|---|---|
| Backlog is growing | "We need a prioritization framework" | Sits down, sorts, deletes, plans the sprint |
| Stakeholders are fighting | "Let's do an alignment workshop in Q2" | Calls a meeting NOW, walks out with decisions |
| No user stories | "The team should write stories" | Writes 2–4 exemplary stories, shows how it's done |
| Sprint is stalling | "We need a retro" | Identifies the blocker, removes it, sprint moves |
| New feature | 40-slide presentation | 1-pager + prototype + feedback in 3 days |
Difference #1: Documents vs Deliverables
A theory PM produces documents: roadmaps, strategy decks, vision documents. They're beautiful. And they sit in Confluence where nobody reads them.
A hands-on PM produces deliverables: a cleaned-up backlog, written user stories, a running sprint, aligned stakeholders.
Difference #2: "We need to discuss" vs "Let's do it now"
A theory PM wants consensus. Every question gets the same answer: "Sure, let's discuss this at the next meeting."
A hands-on PM makes decisions. Sometimes wrong ones — but a bad decision today > a good decision in 3 months.
Difference #3: "Not my scope" vs Ownership
A theory PM has a clearly defined scope. User stories? "That's the PO." Marketing? "That's the marketing team." Pricing? "That's the CEO." They do strategy.
A hands-on PM does whatever it takes. No user stories — writes them. Backlog is chaos — cleans it up. Stakeholders are fighting — mediates. Ownership means: "if the product isn't delivering, that's MY problem."
Difference #4: Perfection vs "Done is better than perfect"
A theory PM won't ship anything that isn't perfect. The roadmap must be "complete." The user story needs "full specification." The landing page must be "tested."
A hands-on PM knows that 80% shipped > 100% in your head. MVP in 2 weeks. Feedback. Iterate. Repeat.
Difference #5: Reports vs Delivers
A theory PM reports: what's happening, what we're planning, what the risks are. Status updates. Dashboards. KPI reviews.
A hands-on PM delivers — and then reports what was shipped. The difference? One talks about what they WILL do. The other talks about what they DID.
"Fresh positive energy, new ways of working. Kind but direct feedback, navigating difficult situations. Invaluable member of any product team." — Mateusz Gostanski, Tech Lead
How to spot a theory PM in an interview?
- Question: "Describe your last sprint from A to Z" — A theory PM talks about process. A hands-on PM talks about deliverables.
- Question: "What did you do when the backlog grew to 300 tickets?" — Theory PM: "I designed a framework." Hands-on PM: "I sat down, deleted 200, and kicked off the sprint."
- Question: "When did you last write a user story?" — Theory PM: silence. Hands-on PM: "last week, here's an example."
Need a PM who DOES, not just plans?
PM Hands-On Sprint: 2 weeks full-time with your team. Backlog cleaned up, sprint launched, processes in place.
See how it works →