A Product Manager who bypasses change control and impact analysis by presenting a big requirements change as a series of small changes distributed over time.
- Can mutate into: ”The Scope Creeper” Product Manager
- Dangerous when coupled with: “The Disenfranchised” Designer or “The Soldier” Developer
- Likelihood of fixing: Low
- Danger to project: Low
The Scope Wiggler Product Manager is the most insidious of all Product Manager personalities. They most likely have self-elected to wiggle scope, and see it as an effective way of them getting what they want. Their particular brand of achieving their end goals often leaves the project in shambles as it dies a death of a thousand cuts.
Agile and Waterfall methodologies both have mechanisms to limit, track, and control change:
- Agile methodologies are built around giving full visibility to changes, such that all team members have the ability to adapt to the change.
- Waterfall methodologies have change control committees, that often include an impact analysis before approving the change.
But what if a Product Manager wants to quietly correct their mistakes in order to protect the perception that they write solid requirements? As all projects have a tolerance for small changes, they can get a big change done under-the-radar by simply presenting their big change as a series of small changes over time.
This devious method of Product Management causes the project to decay from the inside-out at every level:
- Project Managers are denied the benefits of having full visibility into requirements changes, and therefore cannot appropriately set expectations with project stakeholders.
- Developers are denied the opportunity to design a holistic solution to the big change, often resulting in them having to throw out large amounts of work once they realize the true intent of the small series of changes.
- QA must constantly adjust test cases, often only after realizing that they failed to catch bugs in a feature that had requirements changed they were not aware of.
The Scope Wiggler Product Manager’s true damage is likely seen through the decay in the quality of the codebase. By keeping their end goal a secret, developers are lured into bending the code gradually over time until it can no longer be bent. When code has gotten into this state, it is normally costly to fix, and so it never is. This phenomenon is at the heart of most monolithic legacy code bases that can no longer be adapted to meet new requirements.
The Scope Wiggler Product Manager has decided that the most effective way to influence the direction of the product is through deception and deceit. This stems from personal belief that are not quickly or easily changed:
- They believe they cannot be seen as having made a mistake.
- They care more about getting their job done than about the success of the project as a whole.
- They do not care about the difficulties they are inflicting on others.
As a result, fixing the Scope Wiggler Product Manager is as easy as changing their innate character. Perhaps with a compelling enough personal coaching, they can be made more confident in themselves in admitting mistakes, more committed to overall project success, and more empathetic to their teammates. However, the required shift in character is so great that at best only lip-service will be provided, and instead of improving, they will only become more cunning and subtle in how they go about getting their way.