Discover more from Maarten’s Newsletter
Widespread Product Management Anti-Patterns
Anti-patterns are common responses to recurring problems that seem like a good idea. Upon closer inspection they are highly ineffective and detrimental to the organisation.
These anti-pattern responses are very common. I will share 5 prevalent product management anti-patterns and how to resolve them.
1. Christmas Wishlist Product Backlog
As an organisation you do not want to lose any valuable ideas right? It seems to make a lot of sense to just create a ticket. This way everybody is happy and able to track their brilliant ideas. We want to make sure that we never lose that one magnificent idea we should have implemented.
We fall in love with that amazing idea that would make us beat all our competitors. We do not have time for that ingenious idea now, but our future self will. Everybody in the organisation cherishes the product backlog like a Christmas Wishlist. Even if we never get what we want, we can still dream and be giddy in anticipation.
Except that an idea is worthless unless it is executed. Having an inventory, even for ideas, comes at a cost. The customer will call back to ask how it is going with their excellent idea. Why do we not move it forward? When will we finish it?
Ideas can also become obsolete. A customer suggested a cool idea, but we solved it in an even better way with another cool feature. Suddenly we need to manage the idea backlog and close the original ticket. The company unexpectedly gains a lot of extra monkeys on their back that need to be managed.
Many companies have solved this problem by having an idea board where their customers can vote on features. Every month the company just looks at the top 10 ideas and decides which ones to work on. No need to manage this backlog other than looking at the top 10 most highly-voted features.
If a customer is disappointed that we are not picking up their feature, the company can simply point out that our other customers did not find it valuable enough. No hard feelings.
2. Gremlin Feature Flags
Feature flags are an amazing way to mitigate risk. You can put something live and check if it works on production. If it turns out to cause problems then you can turn it off. When feature flags are used they are like Gremlins in the ‘Mogwai’ stage. Cute, fluffy and innocent. Everybody loves having them around. Leave a ‘Mogwai’ outside long enough and it will turn into a destructive scaly monster.
Feature flags are a form of technical debt that should be short-lived. As soon as the feature is live and working it should be removed. A hundred boolean feature flags means more than a billion different configuration combinations that are possible. These all need to be tested. We all know this never happens.
Unexpected feature-flag combinations may pop-up as nasty production issues. As soon as a feature is live and working as expected then the corresponding feature flag should be removed.
3. Sweet Sixteen Refinement Sessions
Product Owners can act like entitled brats in their Sweet Sixteen. The feature should work exactly as they dreamt about yesterday night. They dictate every single implementation detail of a feature. Instead of explaining what they want and why. They will say:“I want a yellow Hummer H4 with white dots and purple rims. Just build it exactly like I am telling you”.
In agile development, scope should be negotiable. The team should have opportunity to provide feedback and come up with a different solution than what was originally proposed. The PO should focus on the problem domain, while the development team should focus on the solution domain.
Of course they need to interact to resolve dependencies between these two domains. Doing this prevents the release of over-engineered and convoluted features that could have been delivered far better and quicker by taking into account what is technically feasible.
When keeping features small and releasing quickly it becomes possible to make decisions based on data and optimise further using A/B testing.
4. Rabbit Feature Management
Stakeholders love a Product Owner that says ‘Yes’ to all of their requests. It makes everybody feel warm and fuzzy inside, PO included. Every week new features get added and they seem to pop out of nowhere like rabbits. There is absolutely no focus. New features are added on a whim seemingly without logic.
Having a clear product vision empowers Product Owners to say ‘No’. They will be able to explain to everyone why this feature should not be added without sounding unreasonable. If a product vision is articulated well enough then people will suggest fewer irrelevant features. Based on the product vision they will understand their feature does not move the product in the right direction.
5. Stakeholder Ventriloquism
This happens when everything the PO decides, first needs to be checked with all stakeholders. Better safe than sorry right? The team is not able to function properly as they spend a lot of time waiting for decisions to be made. The PO is just a ventriloquist’s dummy waiting for the stakeholders to speak.
The stakeholders need to trust the PO to make the right decisions. What the PO could do is keep track of all decisions and check them afterwards with the stakeholders. If a decision turns out to be incorrect, the PO can learn from this. A release may even be postponed if the decisions made were terrible.
The team is able to continue their work without having to wait. The PO will gain more trust and become better at making judgements in time. He will also feel more useful by not just having to repeat the words of others.
Being aware that an anti-pattern is being applied is the first step to resolving it. Many of these anti-patterns are organisational in nature and difficult to resolve depending on your organisation. Having a label to apply helps to start the discussion. It will also help to gain support as other people will be able to recognise mistakes as they are made and point out that an anti-pattern is being followed.