A methodology or framework does not guarantee a great product — far from it.
“What framework should we use to ensure our product’s success?” — A common request by organizations starting their product journey
Product development is complex and uncertain. Yet, many often put all their faith in methodological frameworks to find their path in the dark. As a result, they fail to reach their product’s full potential.
The goal of product management is to deliver the right product in the right way and at the right time. And all products are unique endeavors, never repeated. No two products have the same customers, needs, technologies, or teams to deliver them.
As such, product teams should not follow a methodological framework without modification. Yet, this is what many consistently choose to do. The result? Products crash and burn.
In this article, we will explore the pitfalls of putting blind faith in frameworks. But first, we should understand the common ones in play today.
Your product journey has started. You must first face a framework smorgasbord and find an apt approach.
It is no easy feat to navigate the various options. The available frameworks never quite seem to hit the mark. Yet, either through inexperience or exasperation, you select one framework and follow it. With the best intent, you put misguided hope in the framework to lead you to product success.
Let’s understand the most common frameworks in the wild and some of their merits and traps:
Scrum is a lightweight framework. It is purpose-built for the complexity and uncertainty of product development. Scrum has a foundation of transparency, inspection, and adaptation. In most cases, scrum works best when a single team is focused on a production solution. But it can also work in a multi-team situation.
This framework organizes work into feedback-centric, fixed-length sprints. Each sprint has a standard set of events within that time box. Teams use this construct to create small increments of value with high quality.
Scrum is often criticized for focusing teams on outputs rather than outcomes. It also does not include guidance around ensuring technical excellence. But nothing in the framework excludes having an outcome orientation or high-quality practices.
XP is known for its extreme aspects, hence the name. It excels at driving internal quality and technical excellence. Working in close, daily contact with the customer is central to the XP method.
XP is iterative in nature. And it includes innovative techniques that have withstood the test of time. Some of these techniques include:
XP has never gained the mainstream support it deserves. But it is an excellent choice for keeping technical debt in check. Its close engagement with the customer assures solutions that customers love. Many pair XP with scrum to address scrum’s lack of engineering and quality guidance.
Kanban has its origins in lean circles. It was developed by Toyota to ease just-in-time manufacturing. Kanban helps to keep inventories low and optimize the flow of value by minimizing waste.
This approach has gained popularity in software and product development. Support teams or other teams handling transactional, complicated work will often use Kanban. Kanban is frequently used for work that does not need as much iteration to arrive at the right solution.
Kanban focuses on:
This framework is attractive to many because it meets organizations where they are. It allows them to start with their existing process and incrementally improve it.
LeSS is a scaling framework based on scrum. This framework’s approach to scale is unique. It focuses on scaling with minimally sufficient processes and by descaling first.
LeSS recommends simplifying organizational structures and removing bureaucracy before attempting to add scale. Descaling increases an organization’s ability to deliver value with agility despite its size.
Most of the LeSS framework is focused on a cross-functional feature team. This team can control and own the end-to-end delivery of value to its customer. It utilizes many aspects of the scrum framework at its core.
LeSS has not gained broad mainstream adoption. But it remains a solid framework choice for scale. When many teams need to develop a product with minimal process overhead, LeSS works.
SAFe is the most popular scaling framework. It appeals to large organizations who need a non-invasive solution to handle scale. SAFe fits this bill as it does not require them to restructure their entire organization.
SAFe attempts to merge all other frameworks into one, giant framework. It includes explicit, recipe-like guidance every step of the way. The framework uses many levels of planning intake to feed quarterly work to teams to deliver.
Many have criticized SAFe for being a melting pot of framework processes. It has been equally blamed for not creating agility in organizations. SAFe’s heavy process complexity often splits teams from customers, propagating a factory mindset.
Waterfall took hold of the software development industry in the 1970s and never let go.
The other frameworks above are part of the 2001 agile software development movement. Agile arose to move away from the waterfall approach.
Waterfall is a phase-gate, linear, big-batch, planning-driven approach to software development. It assumes minimal learning during the lifecycle of a product. Waterfall is not suited for the complex, uncertain nature of product development.
But this has not stopped many from trying to fit this square peg into the round hole of product creation. It has led to frequent budget overruns, late delivery, and, frequently, failure.
Many pick one of the aforementioned frameworks and start running. They hope the framework will apply sanity to product development efforts. Unbeknownst to the ins and outs of the framework, they hit snags along the way.
Each framework, on its own, has blind spots and areas where it does not excel in a product context. Despite this, the application of the framework is usually where things go awry. There are many ways to go down the wrong path with a framework.
Let’s explore four common framework pitfalls you might run into and should avoid:
Picking a framework that’s not appropriate for the way you’re working is a common wrong turn. Many select the wrong tool for the task at hand.
Here are a few common ways the wrong framework gets applied:
Product development is complex and uncertain. Using a framework that does not respect this leads to the wrong product in the end. Even if a framework supports empiricism, one can ignore this and reach a poor outcome.
To illustrate, many choose waterfall with a belief they can predict upfront what to build. Some select Kanban and get perfect at finishing what they start, but they finish the wrong thing. And others incorrectly use scrum by delivering incrementally without iteration.
Product creation requires an emergent, learning-forward approach. Ideally, you should use a framework that supports this. But if you are using one that does not, you must adapt the framework to embrace learning.
Learning early and often must be your technique, regardless of your chosen framework. This is how you chart your unique path to success.
When many teams focus on the same product problem, the question of scaling enters the picture. Yet, typically, the framework selected is not meant for scale.
Scrum, Kanban, and XP are not native scaling frameworks. They can be used at scale. But much of how you scale with them will rely on your scaling expertise and experience level when you use them.
Scaling frameworks may be more appropriate alternatives. But, you should take caution here, too. A scaling framework can at times overcompensate with too much process overhead.
For instance, SAFe can easily lead down a path where process overhead can get out of control. LeSS implementations are also not immune to runaway process complexity. Using LeSS without descaling first is often the cause.
In short, moving to scale is a tricky endeavor regardless of the framework chosen.
An organization with a complexity tendency will carry this to the framework — it fits like a glove.
When a large, traditional organization jumps into a scaling framework, many traps await. If they don’t first descale their complexity, product development reliably slows to a crawl. Scaling an already unwieldy organization only adds extra, unbearable weight.
To illustrate, many bureaucratic companies select the SAFe framework and change very little. All the structures and policies remain but with different names. What results is what can only be described as renaming the deck chairs on the Titanic.
LeSS might serve these companies better. It includes many methods for descaling an organization’s structure and process. And LeSS recommends doing this first as the path to operate at scale.
Scale requires simplicity first.
To state it simply, most organizations have a predisposition for focusing on output. They approach their product sequentially. They generate ideas, create a detailed plan and budget, build the ideas, and launch the ideas.
This leads to products nobody loves, except maybe the builders. And often, not even the builders love them in the end. Learning along the way is absent, avoided, and feared.
When these same companies select a framework, they apply their output-focused mindset. This happens even if the framework focuses on achieving value through learning. As a result, they incorrectly apply a factory mindset to product development.
Factory behavior turns teams into assembly line workers. The teams are cranking out unintegrated increments of work off a backlog. They are not connected to their customers or their stakeholders.
Experimentation and learning are absent in this mode. What results is the monotonous, incremental production output of one thing after another. Innovation and adaptation die here.
I’ve seen countless organizations and product teams fall into the factory model trap. It happens even when using the more empirical frameworks of Scrum, Kanban, LeSS, and XP. And to no surprise, SAFe and waterfall take the factory mindset to the extreme.
Cranking out more output sooner with quality does not matter if it is not what is needed. Learning along the way is a crucial but often ignored aspect in the use of most frameworks.
By not embracing learning, product value becomes elusive, and no framework will help.
Many continue to obey the rules of their chosen framework even when the rules are no longer relevant.
When learning something new, everyone benefits from step-by-step guidance. But once new habits solidify, rules are no longer necessary. Improvisation outside the initial rules becomes more beneficial.
Yet, I have seen many organizations chained to their baseline framework for years. They follow the same rules they started with to the letter of the law. Continuous process improvement is non-existent; they are stagnating in their status quo.
Here are a few examples:
Product development is complex and uncertain. It requires a continuously adapted process to address its ever-evolving context. Following the same thing repeatedly is no better than the monotony of a broken record, but many do it anyway.
Learn your way to the right process in the same way you learn your way to the right product. Adapt it continuously to your ever-evolving context.
Organizations tend to keep tight control over who can and cannot decide — a costly mistake.
Most organizations with at least a handful of employees have a hierarchy in place. And once a hierarchy is in play, decisions become complicated and take longer. Only certain levels can make decisions, elongating and complicating the decision-making process.
The tendency is to centralize important decisions to a select few. And this behavior pattern carries over to product development. SAFe and waterfall in particular embrace this; team autonomy suffers as a result.
Other frameworks are not immune to the tendency to centralize all decisions. I have seen this behavior sink its teeth into scrum, XP, Kanban, and LeSS implementations. It is an invasive, difficult-to-eradicate, anti-pattern.
Instead of centralizing decision-making to a select few, it should be democratized. This will use the wisdom of the crowd to its full effect. Getting those doing the work involved will lead to better decisions and engagement.
All hearts and minds making decisions will improve the effectiveness of any framework.
There are many methodological frameworks to choose from for a given product context. These include:
The application of these frameworks is where many often falter. Either the wrong framework is selected, or the wrong thinking is applied to the framework. Common pitfalls include:
So, instead of picking a framework and hoping for the best, we should be more mindful of our context. We should select simple techniques that support a whole team approach to emergent innovation based on evidence. Then, we must change our own behavior to ensure we don’t misapply the framework.
Product success does depend on the framework you pick. But more importantly, it relies on your ability to adapt to your ever-changing context.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Keep the reasoning behind product decisions within reach. Build a clear system to track customer feedback, priorities, and project progress.
Discover how Meilisearch uses LogRocket’s MCP and Galileo to improve free trial conversion and adoption of newly shipped features across its Cloud product.
Resolve cross-functional conflict in AI product development with a 3-step framework to clarify risks, assign owners, and align teams to act.
Learn when prompt-first UX adds friction and how product managers can choose AI interfaces that balance flexibility, structure, and control.
Learn more →
