If you’ve ever worked as a product person [1] then you’ll have had the experience of a family member, or someone at a party, asking you what you do. Unless you’re more articulate than me, there will be some awkwardness whilst your mouth opens and closes and you try and fail to explain what you do. Sometimes this will be followed by your audience saying “so, something with computers then?” and you will agree, and then berate yourself later for your complicity in the “computers are important” myth.
From a high level, a product person can say that they own/manage/look after a product [2], they understand how people use it and they prioritise what changes are made to it. That’s simple. What’s not so simple is what that means in practice.
The life of a product person is varied. A product person can be involved in in-depth technical discussions, demonstrating new features, managing difficult stakeholders, taking part in user research, and overhauling a backlog – usually all before they make it to their desk in the morning.
Decisions
The thread that ties product work together is decisions. Product people make sure that decisions about their product(s) get made, and they make sure that those decisions are based on the value provided to the (end) user of the product. Everything else that a product person does aims at providing the information that allows good decisions to be made [3].
Decisions are not easy things [4]. If I were ever to get a product related tattoo, it would be Maimonides’ assertion that “the risk of a wrong decision is preferable to the terror of indecision.”
To be a good PM you have to be ok with being ‘bad cop’ (saying no), ‘stupid cop’ (asking the really obvious questions), and ‘disappointing cop’ (prioritisation means that not everyone’s needs can be met first). To be ok with playing these roles you need not only to leave your ego at the door but you also need a degree of resilience.”
Matt’s triangle of decision making™
I think that I’ve detected three different models of making decisions in multidisciplinary teams with product people. These form a triangle. As with most triangles, you ideally want to be at the top of the triangle; but that’s also where the fewest teams are.
1. Frictionless decision making
Sometimes, you will find yourself in a team where making decisions feels easy. You all have clarity about what you’re aiming to do, who has the expertise in which area, and a decision is as easy as a five-minute chat with a couple of people and a post on the team Slack.
In my experience, teams like this are settled, secure about their status and able to trust and respect each other. Like all good relationships, they’ve been together for long enough to understand how they like to work and they commit quality time to communication [5].
The only problem with this approach is that it’s difficult to get to the level of understanding and awareness that you need to achieve it. I’ve only worked in a few teams that have had the time, talent and backing to achieve this level of trust and understanding. Despite this, almost every book and conference presentation base their approach on this sunny day scenario.
The mundanity of reality is less kind. In the mixed bag of strongly held opinions, egos, and differing experiences that is the natural corollary of a talented multidisciplinary team, a lack of unanimity and consensus is going to be a frequent, if not outright normal state of affairs – at least until you’ve had time to understand and trust each other.
In the public sector, this is frequently exacerbated by churn issues related to a lack of digital skills, sometimes accompanied by a dependency on contract staff, and made worse by a tendency to fund teams looking after products in short bursts rather than the long-term.
This leads us into our other two models.
2. Functional decision making
I think Noah Weiss is right: product people are not tasked with making decisions, they’re tasked with making sure that decisions are made. Ensuring decisions get made means doing everything possible to facilitate, invite input, convene discussions, commission research and generally acting as a lightning conductor.
It also occasionally means stepping in to make and explain unpopular decisions. Product is not all about feature a vs feature b: that’s the glamorous bit. The need to break a logjam or ensure that there is a decision is never more important than when a product person has to step in and say;
“that cool thing over there glitters and you all want to make it and that’s part of why you’re such a good team but you’ve got an ugly bug creating live issues for users, a worrying infrastructure issue that we can’t find a root cause for and none of you have written tests for the stories in the last two sprints because you persuaded the delivery manager that you could only deliver that feature if they allowed you to take a temporary break on test coverage”.
In these cases, the entire team needs to demonstrate servant leadership [6] and accept that the best outcome for the team is not always the same as the outcome that people want, but is the outcome that has been explained and discussed. It’s product’s role to take responsibility for the explanation, proposed decision and priority; it’s the team’s responsibility to point out any issues and problems that they can see with this approach.
3. Non-functional decision making (aka the blame game)
If this doesn’t happen then what’s left? The worst case scenario – the bottom of the pyramid – is that, faced with a difficult problem and no clear immediate consensus among the team, the product person makes a call that at least some of the team disagree with. In bad team relationships, what can happen is that the product person fails to provide clear reasoning and a chance to discuss the choice. This is sometimes made worse by time pressures, stakeholder demands or because the product person predicts difficulties and becomes defensive about their choice.
At the same time, members of the wider team can fall into passive general criticism: the product person “doesn’t understand”, “isn’t providing vision”, “is failing to serve the team.” It’s always far easier to point at others and criticise than it is to take responsibility, a tendency that I’ve never seen better described than RS Thomas managed:
we agreed power
was not ours, launched our invective
at others, the anonymous wielders
of such. Life became small, grey,
the smell of interiors.”
In these circumstances, the question the team needs to ask is “what different decision could we propose given the same constraints?”. The question the team can end up asking is “why can’t you go away and get more money or people, or get security or the legal team to leave us alone, or just let us postpone doing this thing that we don’t want to do for a bit longer?”. At this point, the smell of interiors can become overwhelmingly stinky.
But what if the product person does get it wrong?
I’ve tried to be generic in this post but it’s safe to assume that I am personally guilty of every one of the product mistakes I’ve outlined above. I’m also not suggesting that there are never any occasions when product people start acting like power-crazed dictators. (Although, if I’m honest, I can think of many more situations where product people needed to take more responsibility for enabling decisions than I can situations where they went too far in making decisions.)
If a product person starts to show autocratic tendencies, then the answer is to work with them to help them understand that they need to provide more context for decisions about priorities. If that doesn’t work, then raising the issue at retrospectives and talking with delivery people are the next steps. A team deserves a good product person and the way to fix product problems is not to start working in a different way, it’s to make sure that the conditions are there for the product person to work in the right way. Working in a different way creates a host of different problems.
The way to avoid the smell of interiors and start working up from the bottom of the triangle to the top is for product people, and the teams they work in, to do everything they can to ensure that good decisions are made. Sometimes that means a product person making a difficult decision and explaining this to the rest of the team. More often, it means a product person facilitating the process of making that decision. These decisions have to be supported by the entire team.
Why does this matter? Without decision making that works, your team isn’t going to deliver maximum value. Without enabling product people to ensure good decisions happen, you’re not making the best use of your product person. And if product people aren’t able to ensure good decisions occur then I am not sure what the point of us is.
Note: this in the first 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 Digital Doughnut, CC BY-NC-ND 2.0
[1] I’m going to use “product person” throughout this post to refer collectively to product owners and product managers.I am aware that these two terms have different histories and different uses in different organisations. The problem is that they swap in meaning between organisations so often that it’s difficult to use one of them without inviting misunderstanding.
[2] There are more sophisticated definitions but mine is “a product is a thing that allows someone to do something.”
[3] You’ll note that I say “good” and not “right”. If you’re genuinely iterating, then “good” is what you want; waiting around until you’ve done all of the work to find out what is “right” could take years.
[4] I agree with Marty Cagan’s definition but I’d add that you have to use that knowledge to achieve an outcome.
[5] This may betray my love of caffeine but two recent ideas I’ve seen that I liked are team Fika and mandated coffees with team members to talk about work.
[6] If we’re genuine about equality in teams, then please let’s make sure we never demand specific qualities from some team members but not all of them.
Recent Comments