This article is part of a series aiming at demystifying the Product Operating Model (a.k.a ‘the Product Model’).
You’ve adopted agile practices. You’ve highlighted your company core values about “Taking initiative”, “Being proactive”, or “One team”. You’ve even told your teams that they’re empowered to make decisions. Yet, somehow, your teams are still hesitant to take initiative, constantly seeking approvals, waiting for decisions, and struggling to deliver meaningful results. Sounds familiar?
The hard truth is that most companies claiming to have empowered teams are actually running glorified feature factories. Their teams might have the freedom to decide how to implement features, but they’re still being handed solutions rather than problems to solve. The empowerment that delivers meaningful results isn’t about letting teams “figure out the details” – it’s about trusting them to discover the right solutions to meaningful business and customer problems.
ln this article we’ll dig deeper into what ‘empowering a team‘ means in practice by answering some important questions: What actually empowers a team? Who does the empowering? When and how does it happen?
Empower by giving problems to solve
In his books, “Empowered” and “Transformed”, Marty Cagan tells us: teams become empowered when they’re given meaningful customer or business problems to solve (or opportunities to realize), and are trusted to discover and deliver effective solutions.
As seen in the previous article, this stands in stark contrast from the common practice of handing teams stakeholder-driven roadmaps filled with pre-defined features.
What do we mean with ‘meaningful’ problems?
When we talk about giving meaningful problems, we mean customer or business issues/challenges that – when solved – contribute directly to product goals or company business objectives.
OK, Let’s double-click on that!
John Cutler‘s mandate-levels is a good illustration of different classes of problems usually given to teams in a tech-powered company. The way these different problems are stated gives us a good idea on the mandate effectively given to a team. It is a progression that goes like this:
- “Build exactly this” (to a predetermined specification)
- “Build something that does X” (specific behavior, input-output, interaction)
- “Build something that lets customers do Y” (complete some task, activity, goal)
- “Solve this customer problem” (more open-ended)
- “Improve the experience for this user segment” (explore challenges and opportunities)
- “Move this specific metric” (known to influence business outcomes)
- “Explore leverage points and run experiments to influence business outcomes”
- “Generate short-term business outcomes”
- “Generate long-term business outcomes”
The first three mandates focus primarily on implementing features to specification. While these features might solve important customer problems, the team isn’t really involved in that consideration – the solution has been determined elsewhere by someone else. The message is: “just do it!“. This covers most teams I meet at clients. These teams, called ‘delivery teams’ or ‘feature teams’, focus on the tech implementation where they have some freedom on the details.
Mandates 4-6 shift the focus to creating outcomes for customers and users. Importantly, the solution isn’t pre-determined; instead, the team needs to invest time in discovering ways to make it work. These mandates grants autonomy and agency: leaders trust the team to solve the problem while expecting them to work within the business constraints (legal, security, financial, etc.). These mandates enable true empowerment. These teams, called ‘product teams’, focus first on finding the right solution to the problem by hypothesizing, experimenting and testing with customers. They will only go to implementation when they believe a solution to be sufficiently valuable, viable, feasible and usable.
The final three mandates (7-9) operate at an even higher level, potentially extending beyond a single product to impact the entire organization. At this level, teams aren’t just working on solutions – they’re exploring the problem space itself, identifying which problems to tackle, and pivoting as needed based on results. It’s the grail of empowerment, and requires maximum trust.
It’s worth noting that specifications and requirements (very visible at levels 1-3) aren’t necessarily barriers to empowerment – if used right. They can be necessary in clarifying technical or legal boundaries within which solutions need to be developed. The key is that they are used to frame the constraints rather than dictating the solution.
Who ‘gives’ problems to solve? when? how?
Product leadership – typically a trio of product, design, and engineering heads – takes responsibility for identifying and assigning problems to teams.
These problems do not come from thin air; they emerge from the product strategy. It’s the result of a lot of work that includes analyzing product data, customer insights, tech capabilities, market opportunities all the while aligning with business objectives. This represents one of the most important responsibilities for product leaders: to maintain a product strategy that highlights the most relevant problems or opportunities to tackle next, based on the latest insights and learnings.
In a dialog between product leadership and teams, these problems and opportunities are then translated into clear team objectives, often using OKRs (Objectives and Key Results). While product leaders set the objectives to reflect the problems that need solving, team members participate in defining the key results. These OKRs typically run quarterly, though timeframes can vary. The important thing is giving teams enough runway to properly discover and deliver solutions.
So, it’s enough to ‘give’ a problem? That’s it?
As you may already suspect, simply assigning problems is far from enough. Leaders need to ensure teams have the right environment to succeed. At a minimum, these things need to be in place:
- The problem must be clear and measurable. Are there defined success metrics? What leading indicators will show progress? (This is where OKRs can really shine.)
- Teams need strategic context. Why is this problem significant? Why tackle it now? What tradeoffs were considered? Does the team understand the product strategy? What data and insights support this direction? What assumptions are we testing?
- The team needs appropriate competence and skills. Do engineers understand the technology well enough to leverage it for customer solutions? Does the Product Manager have sufficient knowledge across product, users, stakeholders, company, and industry domains to support the team? Can the designer create effective user experiences?
- Teams need direct, unfiltered access to users, customers, and product data/analytics. Can they meet actual users? Are they using these opportunities to learn about user pains, needs, and wants?
- Teams need clear boundaries. Do they understand stakeholder expectations? Can they connect directly with stakeholders when needed? Are they considering financial, legal, and security constraints? Are these boundaries creating a productive playing field rather than being used as control mechanisms?
- The team needs psychological safety to experiment and fail. Are leaders embracing servant leadership – tight on purpose, loose on execution, and tight on learnings? Does the team engage in healthy conflict and discussion? Are experiments sized appropriately to allow for cheap failures?
In other words, empowerment isn’t a one-time grant – it’s an ongoing relationship between leadership and teams.
What does that mean for team members?
With empowerment comes accountability. When teams become responsible for solving problems and delivering results, they’re also accountable for business outcomes.
For team members, this accountability creates an interesting dynamic – it’s both very motivating and deeply intimidating. Taking ownership of meaningful problems and choosing how to solve them energizes most people, but team members can easily become stressed and anxious, doubting their own capabilities in face of the challenges ahead. That’s when good leadership and support is critical, a topic I’ll re-visit in a later article.
Due to leadership’s commitment to create an empowering environment, and an increase in apparent trust, companies almost always experience a boost in empowerment and motivation metrics when implementing empowered teams. The challenge is in sustaining these gains, as it requires commitment to deeper structural changes – from governance and product funding, to innovation financing and performance measurement approaches. In other words, if you only change things at the team or product-level, you will have a hard time to make it viable in the long run.
Are you empowered?
Want to know if your team is truly empowered? Here is a litmus test:
Can you decide HOW to solve the problems you’ve been assigned?
As Marty Cagan points out: “If you picture yourself as empowered but you still need to get approval from stakeholders on your proposed solutions, then you’re not really empowered.”
