The real reasons product managers complain about SAFe®
Delivering better software at scale is a constant challenge — especially for large organizations with multiple products and sprawling teams. Enter the Scaled Agile Framework® (SAFe®), which promises to align strategy, improve productivity, and help enterprises deliver more value, faster. But plenty of product managers who follow SAFe will tell you this is not so. There are countless discussion threads (and even entire websites) dedicated to people's hatred of the framework. Folks question its overcomplicated processes and diminishing returns, feeling that SAFe is more about checking boxes than delivering meaningful progress.
So even though SAFe might be necessary for some, the question remains: Is it really the best way to build better products?
For a framework built around agility, it is ironic how often SAFe is described as being anti agile. Bloated processes via multiple layers of planning, excessive ceremonies, and rigid roles introduce bureaucracy and inefficiency — making workflows resemble waterfall more than agile. The freedom to iterate and explore new ideas is replaced by a focus on compliance, stifling the creative thinking that agile methodologies are meant to encourage.
So why continue to follow SAFe? Discipline and predictability are desirable. Very large organizations need a structured way to coordinate complex efforts and maintain visibility across teams. Leaders seek clear reporting and governance mechanisms to align work with strategic objectives and track progress.
This makes sense. However, when it comes to SAFe in practice, there are more tales of frustration than success stories. Our Product Success team at Aha! speaks with product leaders every day who really struggle with SAFe (or, as they call it, "Soul-Crushing Agile for Enterprises"). They spend more time in meetings and managing dependencies than actually delivering value to customers.
Despite its promise of structure, many product managers feel trapped by SAFe. They navigate red tape and attend meetings more than driving innovation.
Based on these conversations, here are the most salient problems product managers who use SAFe experience:
Strategy gets lost
SAFe tries to connect business and product strategy to tangible work. But this often breaks down when goals and initiatives get overlooked amid all the complexity. Teams are tasked with completing work, and metrics like ticket burndown look good — but this does not necessarily correspond to creating business and customer value.
Customers are overlooked
When teammates are overly concerned with adhering to internal processes, customers lose out. Every layer of hierarchy dilutes the team's understanding of customer pain points. Between business leaders, product owners, release train engineers, solution managers, system architects and engineers, and more, customer feedback can easily be mistranslated or misinterpreted.
Process overwhelms
SAFe depends on role rigidity and lots of upfront planning. When teams are focused on endless meetings, multiday program increment or planning interval (PI) sessions, and perfunctory tickets, there is less time and energy to actually build what customers want. Plus, it is difficult to move quickly and iterate when multiple levels of management and approvals are needed.
Alignment is forced
PI planning sessions can be grueling. Although it is important to align on a shared vision and map out upcoming work, these multiday sessions are notorious for drawn-out discussions and excessive rounds of feedback. By the time the confidence vote rolls around, plenty of folks in the agile release train are ready to be done. For teams doing fist to five confidence voting, it can be tempting to raise three or more fingers just to end the discussion and get back to work — regardless of how confident they actually are in the PI planning objectives.
Joy dissipates
Team members who follow SAFe often say they feel like cogs in a machine — mindlessly churning out tickets and delivering new features that customers do not actually care about. Individuality, creative thinking, and autonomy tend to shrivel up in favor of top-down directives. Ultimately, teams deliver a sanitized, commoditized product that does not bring joy to its audience.
No matter what framework you use, the process of building lovable products should be energizing and meaningful.
No product methodology is perfect, but teams deserve a framework that empowers them. If the above challenges sound familiar, it might be time to explore alternatives. The Aha! Framework for product development, which is grounded in strategic planning and continuous delivery, can enhance or complement your current approach. With the Frameworks functionality in Aha! Roadmaps, you can customize workflows to suit your team’s needs — so the focus stays on meaningful work rather than process details.
Product development software your entire team will love. Try Aha! software for 30 days.