Build Your Own PM Toolbox (Learning Without Burnout)
Learn from execution, self-retrospect, deep-dive one skill gap at a time, and keep only what works for you.
- Difficulty
- Easy
- Time to result
- ~ongoing to results
- Steps
- 4
- Confidence
- 88%
Faced with endless PM content, Perri's antidote to overwhelm is to learn primarily from doing. Execute the job, run a retrospective on yourself to find what's working and what isn't, then deep-dive one skill gap at a time driven by real problems. Treat every process and framework as adaptable — keep what serves you, discard what doesn't, and assemble a personal toolbox.
Origin
Melissa Perri's personal learning method, exemplified by her deep-dive into the origins of Agile and Scrum to solve a real problem she encountered.
Core principles
- 01You learn the most from execution, not from consuming more content.
- 02Let real problems drive what you go deep on next.
- 03Every framework is meant to be iterated and adapted; dogmatic processes that don't serve you should be dropped.
- 04There's a shared core (talk to users, run tests, build iteratively, measure) but how you do each part is yours to tune.
How to run it
- 1
Focus on doing the job
Prioritize execution first — actually doing the work of product management is where most learning comes from.
- 2
Run a retrospective on yourself
Analyze your own job: what's working, what's not. Ask whether a given practice is helping you get better as a PM.
Pro tip Do this on a real cadence, the way a team runs a retro on its process.
- 3
Deep-dive one skill gap at a time
Pick a specific weakness (e.g. user research, data analytics) or a problem you hit, and go down a focused rabbit hole to understand and fix it.
Pro tip Perri interviewed the people who wrote the Agile Manifesto to understand why teams were writing thousands of pointless user stories.
- 4
Keep what works, drop what doesn't
If a process or framework doesn't serve you, change it or abandon it; if it works, keep it in your toolbox. Build your own toolbox over time.
Pro tip This applies especially to dogmatic Agile/Scrum practices — adapt or move on.
Watch out Don't keep following a dogmatic process out of obligation; nothing has to stay if it isn't helping.
In the wild
Perri found people new to product ownership writing thousands of user stories for tiny features. To understand why, she went down a rabbit hole interviewing everyone who wrote the Agile Manifesto and taught Scrum.
→ Understanding the origin let her figure out how to fix the dysfunction rather than blindly follow the practice.
Common mistakes
Trying to consume all the content
Books, newsletters, tweets and podcasts pour in endlessly; treating consumption as the path to mastery leads to burnout and little actual skill gain.
Following a process dogmatically
Sticking with Scrum or any framework because it's 'the rule' rather than because it serves you wastes effort — everything is meant to be iterated and adapted.
Is it for you?
Best for
Product managers at any level feeling burnt out by the firehose of PM advice and unsure how to actually improve.
Not ideal for
Someone who genuinely lacks the fundamentals and first needs structured grounding before self-directed deep dives.
From the transcript
“the way that you're going to learn the most usually is from execution”
“i just run into problems and i'm like i need to learn more about like why that problem is causing this”
“sit down do a retrospective with yourself and say is this helping me get better at being a product manager and if it's not change…”
“create your own toolbox”
From the episode
How to create a winning product strategy
Melissa Perri