How to Sabotage a Product Owner

One of my favorite exercises from my Professional Scrum Product Owner classes is how to best sabotage a Product Owner as a member of the middle management. The exercise rules are simple: You’re not allowed to use any form of illegal activity. So, outsourcing the task to a bunch of outlaws is out of the question. Instead, you are only allowed to use practices that are culturally acceptable within your organization.

Read on and learn more on how to best sabotage a Product Owner from the exercise results of more than twenty PSPO classes. (I edited the suggestions for better readability.)

The Exercise: Consider How to Best Sabotage A Product Owner

The exercise is based on a Liberating Structure microstructure called TRIZ.

Here is the briefing for the participants; typically, they have a five-minute timebox to come up with suggestions and observations in a workgroup of three to five people.

• You are a middle manager in the IT organization, and you believe this Scrum thingy is a fad and will go away—with a little help from your side.
• Your task: As a team, come up with ideas on how to best sabotage the new Product Owner of the first Scrum Team in your organization.
• Please note that only legal and culturally accepted practices qualify as a suitable outcome. 

Once we accomplish the first part of the exercise—aggregating sabotaging practices—the workgroup then identifies those practices to sabotage Product Owners they have already witnessed, followed by identifying possible ways to counter these practices. 

I categorized the results from the before-mentioned classes into eight groups:

1. Messing with the Scrum Framework in General

The first category of how to best sabotage a Product Owner is generally about disqualifying Scrum itself as a helpful framework or introducing changes to conflict with the first principles of Scrum:

• Ignore the autonomy of the Product Owner in general.
• Bypass the Product Owner and talk directly to the Developers.
• Product Owner has to act as Scrum Master at the same time.
• Impose traditional project management tasks on the Product Owner.
• Enforce traditional or waterfall practices within the Scrum framework; for example, insist on approving Increments.
• Isolate the Scrum team by applying “old” processes at the interface between the Scrum team and the rest of the organization.
• Organize important stakeholder meetings in parallel to Sprint Reviews.
• Ensure that critical stakeholders are never available for the Product Owner.
• Set hard timelines or milestones.
• Insist on all projects being accomplished within a fixed time, scope, and budget setting.

2. Scrum Team Building & Line Management

If the direct approach does not yield the expected results, why not use the backdoor and help make the Scrum team as dysfunctional as possible? Some suggestions worth considering are:

• Ignore the self-management of Scrum Teams; instead, micromanage them.
• Assign Developers to multiple projects to increase the overhead. Then, blame the Product Owner for lack of productivity.
• Change the Scrum Team structure often to keep it in a state of constant team building. For example, introduce new team members during a Sprint or shuffling Developers between multiple Scrum teams.
• Deliberately pick new Scrum team members from those who openly despise Scrum.
• Assign ad-hoc tasks outside the Scrum team’s focus to team members.
• Put constant pressure on the Developers. Tell them they are too slow and they don’t understand the business.
• Award contradicting individual incentives to Developers to cause internal competition within the Scrum team.
• Use the Daily Scrum to check on progress and hold the Product Owner accountable for not meeting your targets.
• Make the availability of tools and other resources difficult for the Scrum team. 

3. Flow of Information

If you are already messing with the Scrum Team team-building process, why not place a few obstacles into the Scrum Team’s way of working? Sabotage your Product Owner by keeping them in the dark while holding them accountable for not being up-to-date:

• Don’t provide feedback.
• Otherwise, respond irregularly and with a long delay to inquiries of the Product Owner.
• Don’t share new market insights or intelligence with the Product Owner, particularly during the Sprint Review. Later hold the Product Owner accountable for not knowing this information.
• Don’t attend the Sprint Review in the first place.
• Generally, don’t accept meeting requests by the Product Owner.
• Restrict the Scrum team’s access to the customers.
• Ensure that the salespeople relay feedback from customers exclusively.
• Never communicate organizational changes that could affect the Scrum team’s work in time.

4. Metrics & Reporting

The next bucket of useful sabotage practices are metrics, OKRs, KPIs — you name it. Just turn the members of your Scrum team into glorified data-entry clerks with a challenging reporting burden:

• Keep the team busy with unnecessary reports, documentation, or administrative tasks.
• Enforce proprietary and obscure metrics useless to the Scrum team.
• Demand evidence of progress. At the same time, reject all metrics from the Scrum team as unsuited. 
• Request detailed accounts of what will be done when. Insist on defining milestones with accurate breakdowns of work items.

5. Vision, Product Discovery & Product Backlog Management

All sabotage is—at least partly—based on deception. Therefore, obfuscate whatever might help the Product Owner to get an understanding of what strategic direction they are supposed to support with their Scrum team:

• Constantly change the organization’s focus or priorities.
• Create an unclear vision and keep changing it regularly.
• Break down the vision into unclear requirements and refuse to elaborate, claiming they are apparent.
• Overwhelm the Product Owner with a never-ending flow of unclear requirements and requests.
• Ask for requirements specifically outside of the expertise of the Scrum team, deny them the necessary resources, yet hold the Product Owner accountable for the subsequent failure.
• Overrule the Product Owner’s decisions by pulling rank.
• Spread the Product Owner thin by assigning them to multiple products simultaneously only to complain about the resulting lack of attention to detail.
• Add items to the Product Backlog at your will.
• Micromanage the Product Backlog and its refinement; for example, insist on being present but rarely commit to attendance.
• Insist on detailed specifications for each Product Backlog item.

6. Messing w/ the Sprint, Increment, or Release

Does the Product Owner still lead the Scrum team towards creating Increments? Time for some rearguard action by introducing new approval stages and security measures—for the sake of your customers, of course:

• Reject Increments as not meeting specifications and blame the Product Owner.
• Add tasks for the Developers to the Sprint Backlog that are not aligned with the Sprint Goal.
• Keep striving for perfection, never release.
• Request a separate, multi-step approval process outside the Scrum team before any release.
• Install a separate governance board dedicated to product quality and security issues.
• Define new security protocols that overburden the Scrum team, claiming legal requirements.

7. Politics

Use your career equity, the network you have been building for years, to your advantage. Maybe, it is time to call in some favors:

• Continuously seed doubt within the organization’s hierarchy regarding the capabilities of the Product Owner. 
• Challenge Scrum’s suitability as a framework in your organization’s case by pointing at failures in other organizations.
• Play ‘blame-game’ with the Product Owner for any failure or shortcoming while claiming successes of the Scrum team as yours.

8. Budget

If everything fails, don’t waste time reading the Scrum Guide. Instead, use the budgeting process to your advantage: 

• Slash the budget but keep the scope.
• Keep the budget but increase the scope.
• In general, make the budget process longer and more complex by adding useless requirements, for example, regarding the paperwork.

How to Sabotage A Product Owner — Conclusion

Every middle manager has ample opportunity to sabotage Product Owners. Moreover, most of the time, it will be unlikely that others will identify these practices as deliberate obstruction. Providing the benefit of the doubt and assuming positive intent, they probably get away with it. Therefore, reading these signals early in the process is vital to us agile practitioners. 

Please keep in mind: not everyone will be excited when the organization succeeds in becoming a learning organization. Self-management and shifting decision-making to those closest to the problems will likely flatten the hierarchy, reducing the need for managers. Typically, scaling “agility” equals “descaling the organization.”

What practices to sabotage Product Owners have you observed? Please share your learnings with us in the comments.