Got Framework FOMO? Here’s Why You Should Stop Searching for the Perfect Process
Exploring why popular product management frameworks and processes can fail and how to find what actually works for your team.
Most of us begin our product careers by learning the biblical frameworks and processes—story mapping, Jobs-to-Be-Done, Scrumban, the list goes on... Before I made the move into product management, I'd anxiously swotted up on all of them with books and short courses, keen not to look like an idiot whilst leading my first meetings, but excited to share my ideas and create value.
It wouldn’t be spoiling it to say that those first few meetings were far from what I’d dreamed they’d be! I thought I’d said all the right things (with the immaculate Miro boards to back it up) but I stumbled at the first few curveballs that didn’t fit my neatly pre-prepared vision. Instead of revealing a yellow brick road to valuable outcomes, the path forward became muddier and murkier.
I soon realised my safety blanket of structure wasn’t aligning with my reality. A tumultuous market, tight timelines, and everchanging team dynamics meant my documents and tickets were out of date before I even hit save. So, as time went on I adapted, removing the crutch of frameworks and processes I’d been clinging to.
My confidence has waivered significantly each time I’ve moved jobs, projects, and products — each time I would discover that processes that would supercharge one team’s clarity and productivity would totally flop in another. So I thought I’d explore the reasons why frameworks and processes can fail, why we should think of them as tools rather than a checklist, and share a mental toolkit I’ve used to find what actually works for your team.
Why Frameworks Can Fail in Practice
At a high level, frameworks are often applied too rigidly and can’t cater for the nuances of an organisation. Taking a course or reading a book is great for learning the basics or opening your mind to new methods, but it can’t match practical experience when you must bend (or break) the rules. Teams can quickly get frustrated when a PM sticks to a rigid process without hearing them out and adapting to their reality. For example...
They Can’t Account for Organisational Culture and Constraints
A framework that thrives in a product-led organisation (our textbook theory haven) might falter in a sales-driven or operations-heavy company. Taking lean principles as an example, if you’re in a risk-averse or heavily regulated industry, lengthy approval processes are probably the norm and you’ll struggle to apply them as you expected.
They Can’t Align Your Stakeholders
Different teams—engineering, marketing, sales, and leadership—often have conflicting priorities. Product Managers are all too familiar with this, but a theoretically sound framework we might use to guide us can’t account for the power dynamics and decision-making structures that can really sway the outcome of a decision.
They Can’t Provide You with Good Customer Insights
Many frameworks assume that product teams have direct, continuous access to customers. In reality, a fair few product teams find themselves relying on fragmented, outdated, or second-hand insights. We want to be data-led but end up injecting a healthy dose of 'gut feel’ that can be tricky to defend.
In my experience this is exacerbated in larger organisations, where the distance to the customer grows larger, and retail companies, where customers have brief, transactional interactions with your product.
How to Find Out What Sticks
This isn’t to say we should do away with frameworks entirely, but to draw attention to the dangers of putting the blinkers and failing to recognise where processes just aren’t working. There’s a wealth of product management resources out there, but few can guide us through their application in messy and unprecedented real-world scenarios.
Trial and error across start-ups, consulting, and government has helped me develop a flexible approach to frameworks and a healthy dose of scepticism on what sticks.
1. Start with the Problem, Not the Framework
Before adopting a methodology on a new project, build individual relationships with your team members—they should feel comfortable discussing their worries with you. No framework can compensate for poor communication.
Don’t feel like you need to rush through a checklist of ‘product tasks’ when you’re getting up to speed. Take the time to deeply understand the problems you’re solving with your product and facing within your organisation. Note them down and observe where things splutter, providing a ‘finger in the air’ gauge for the extent of the issue.
Once you’re confident there’s a process you need to improve:
Be strict enough with yourself to tackle just the most impactful one. Make sure you’re confident it’s something you can actually move the needle on.
Be kind enough to give yourself wiggle room to figure it out. Help your team keep momentum on what's gone well to demonstrate impact, but keep a buffer to go all tackling the root cause of an issue that can accelerate that.
Be realistic about what you can change, don’t attempt to tackle everything at once, and don’t be afraid to choose your battles!
2. Continuously Experiment and Iterate
Once you’ve got a deeper understanding of the problems you’re facing, think about what frameworks might help. These can accelerate things that’re going well—giving your team clarity on how to keep momentum, but can also transform the areas you’re faltering.
Just as we iterate on products, we should iterate on our processes and team activities. Don’t get attached to a methodology just because it’s your initiative. Regularly reflect on what isn’t working and be willing to abandon frameworks that don’t fit.
Consider team maturity, strategic goals, and company structure. A startup with a small, cross-functional team will operate very differently from a large enterprise with multiple departments
They’re toolkits not blueprints, so adapt them from the ‘best practice’ context they’re presented in to pick and choose the elements that your team thinks are helping.
3. Align on Outcomes, Not Just Outputs
Your team will feel your reaction to failures. Keep it simple for everyone and shift the focus to customer value and business impact over sprint velocity and feature releases. Don’t sweat the outputs. If a process fails to deliver the expected results, this shift will help the team remain adaptable with their eyes on the goal.
Without teaching you to suck eggs, you’re there to build great products that help real people. Stay close to the customer, validate your assumptions often, and don’t get bogged down in a product rulebook. In the end, no one cares if you used Agile, Waterfall, or winged it—they care that it worked.
To Wrap Up
The frameworks and theories in books or courses provide valuable guidance, challenge your thinking, and share intriguing new approaches—but product management is ultimately an exercise in adaptability and nothing beats hands-on experience. Focus on the problem, draw on your framework toolkit to fix it, and continuously adapt your approach to navigate curveballs with confidence. Remember why you’re there and don’t take your eyes off the prize!
 | A guest post by
|