git branches

Five product anti-patterns

Why not get rid of your product person? Why let a product person enable decisions? The best possible case for not getting rid of them and making sure you enable them is what happens to your team if they’re not there.

Here are five alternative approaches that I’ve spotted, and some of the sub-optimal consequences.

1. Anarchy

  • Description: everyone does what they want to do.
  • Risk: the team goes chasing after the shiny stuff.
  • Bad signs: you have multiple feature branches and code that has been waiting to be released for a long time, and a lack of consensus around the product vision and roadmap.

2. Team decisions

  • Description: only stories that everyone agrees on get prioritised.
  • Risks: unpopular tasks – test cases, changes that deliver a major difference for users but are technically complex – get deprioritised. It’s not clear where the responsibility for decisions lies. Groupthink rules and individual voices get lost.
  • Bad signs: your backlog has a lot of blocked stories.

3.  Stasis

  • Description: this is the procrastination option, where decisions are avoided through further conversations or attempts for consensus.
  • Risks: similar to no. 2, the difficult stuff, the stuff that needs most attention gets delayed while the team works on low impact changes.
  • Bad signs: the following phrases start to become well used in planning sessions: “we’ll have a look at that next sprint,” “after we’ve done feature x, we’ll be in a better place to look at that”.

4. Seniority wins

  • Description: the decision gets made outside the team by a HiPPO.
  • Risks: frequent direction changes; you end up working on a mobile app, or something to do with Blockchain.
  • Bad signs: decisions get delayed from planning sessions whilst stakeholders are consulted.

5. Tech first

  • Description: a technical person makes the decision on priority.
  • Risk: decisions get made on technical and not value criteria e.g. you end up refactoring minor code when you could be building new features.
  • Bad signs: gold plating of existing approaches; the approach to planning, prioritisation and sign-off become unclear or bureaucratic.

And that’s not the worst bit…

The risks given in the examples above miss the worst consequence. All these alternatives risk losing the voice of the user: and that’s the most serious risk possible because it means you will end up building a product that makes life harder for your users than it should.

Product people aren’t the only people who should speak up for your users: that’s the job of everyone in the team, no matter what their role is. You may also have specialist user insight from user researchers, interaction designers, service designers, content designers and other roles.

Product people are tasked with ensuring that prioritisation of work is centered on the value delivered for the user. No matter how much insight and awareness the rest of the team has, they are still likely to end up prioritising work that doesn’t deliver maximum value to the user unless it’s someone’s specific responsibility to ensure that this happens. (That includes, where necessary, defending the team against internal stakeholders and others who don’t always understand why you’re not delivering their request first.)

How do I avoid these five scenarios?

Product people aren’t perfect, product isn’t perfect. But allowing your product people to make sure decisions get made, even when they are difficult, means that you avoid these scenarios. I’d suggest this makes product people worthwhile.

Note: this in the second in a series of three posts reflecting on what product is, and how it can best support the work of multidisciplinary teams. They are personal views, with examples drawn from a number of organisations and sources. It’s always difficult to try and define roles and boundaries; my main reason for trying to do this is that I couldn’t find anything else that did this. These posts are provisional: I’m sure that I’ve missed some areas and got other aspects wrong. Please get in touch and suggest additions if you spot anything. 

Header image by miguelpdl, CC BY-NC-SA 2.0

Leave a Reply:

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.