product management

Bizarre love triangle

Simon Morgan-Wilson

• 6 min read
Share

Or: What do you mean by product thinking?

I've had a few chats about roles the last few months. In way more than one of them someone said We need product management. Or We need product thinking. And to emphasise the point: I hear this a lot. A lot.

It's a fair thing to want, I guess, especially in a world of product! product! product!. I'd just like more people to know what they think they're getting. So here's my go. Then some questions to ask, whichever side of the chat you're on.

What is product thinking?

To me, product thinking is about:

  • What you ask of a piece of work. What's it for? Who's it for? Is it working?
  • How you judge it. By what it changes for the people using it, as well as whether it got delivered.
  • What you decide next. Based on what you've learned, including whether to stop.

And a few habits that go with it:

  • It starts from a problem. A problem is a person, a situation and what's hard for them, or for the organisation trying to serve them. We don't have an app is a solution. People miss appointments because the letter turns up after the date is a problem.
  • It treats the work as something that keeps going. A project ends when it's handed over. A product gets used, gets changed, and gets better or worse over time.
  • It holds several things at once. Is it useful to the people it's for? Can the organisation afford it, run it and support it? Can it be built? All at the same time.
  • It's honest about what's a guess. Most plans are mostly assumptions. Say which bits. Then find out which are wrong, as cheaply as you can.

It doesn't belong to product managers. I've seen designers, researchers, developers and delivery managers do it brilliantly. I've seen people with product in their job title not do it at all.

What is product management?

The job of making sure that thinking happens – and that decisions come out of it.

Someone has to keep hold of why we're doing this. They say what we're doing next and what we're not, and can explain both to the team and to whoever's paying. They keep the team close to the people it's for and to the organisation it sits in.

It's a job done for the team. If the product manager is the only person doing the product thinking, something's gone wrong.

It also means different things in different places. In some it's taking requirements, configuring something bought in and handing it on. In some it's writing a plan and managing delivery against it. In others it's working inside a team, learning as you go and deciding what's the next most useful problem to work on. All of them get called product management – and need quite different people.

And a product operating model?

The bigger version, and more often on a slide. It's the organisation around the teams. How the work gets funded – as something that keeps going, or a project that ends. Who decides what teams work on. What governance asks to see. Whether a team sticks together long enough to learn anything.

Put a product manager into an organisation run on projects and you mostly get a project manager with a different job title.

What I'd expect to see

Walk into a team that does this well and you'd notice things. Nothing fancy.

The problem, in their own words. Ask anyone on the team what problem they're working on and you get roughly the same answer, said differently each time. A sentence about a person and what's hard for them. If you get a feature name, keep asking.

"Build X" is where the conversation starts. When a request turns up as a solution, someone asks what it's for. For whom? What happens if we don't? Is there something smaller that gets most of it? Quite often X is right. You find out by asking.

Guesses written down as guesses. We're assuming people want this. We're assuming the data is good enough. We're assuming the integration takes a week. All kept apart from what's actually known. I know this can look like paperwork, a layer of management for the sake of a layer of management. It's how a team works out what to test first.

Saying what you expect before you do it. If we do this, we think that will happen. Then looking at what did happen. Skip it and everything gets written up as a success.

The cheapest test first. What are we most likely to be wrong about and what's the quickest way to find out? Sometimes a prototype. Sometimes doing the thing by hand for a fortnight before anyone builds anything.

Someone spoke to a user recently. And can tell you what they heard and what changed because of it. The numbers the team watches are about those users. Tickets closed is for the team, not for anyone else

Things stopped. A list of what the team decided not to do and why. Work dropped when it wasn't going to land, and said so out loud. I wrote recently about the chipping and the craft, and how a lot of the craft shows up as things that didn't happen.

Options, with a recommendation. Here's what we could do, here's what we'd pick, here's what we'd stop to make room. The people above the team get a decision to make. They don't have to do the team's thinking for them.

Underneath all of that is tone. Curious first, defensive later, if at all. Doesn't jump straight to a solution. Listens. Isn't stroppy when someone asks an obvious question, because it's usually a real one. Says I don't know without flinching.

A team can produce every artefact on that list and have none of this. That's theatre.

Does this slow delivery down?

That's the worry. More questions, less shipping.

I don't think so. The expensive thing is building the wrong thing, on time. Most of that list is about finding out while it's still a conversation and hasn't become a quarter's work. (Good delivery people tend to like that too.)

Questions to ask

The phrase on its own doesn't tell either side much. Some questions that might.

If you're hiring

Ask yourself these before you say it to someone like me.

  • So that what? What would be different in six months?
  • Which kind of product management? Configuring something you've bought, managing delivery against a plan, or a team working out what to build?
  • What happened recently that made you say it?
  • Is it a person you need or a way of working? One product manager won't change much if nothing around them does.
  • Who decides what gets worked on now? Are you up for that changing?
  • When did a team here last stop something? What happened to the person who said stop?
  • How is the work funded, by project or by something that keeps going?

Then put the answers in the job ad. Saves everyone a few chats.

If you're looking

Ask them these when they say it to you.

  • What happened that made you say you need product management?
  • Who decides what the team works on today? Would that be me?
  • Is the team building its own thing, or configuring someone else's?
  • When did someone on the team last speak to a user?
  • What's the last thing the team stopped?
  • What happens here when a team says no?
  • What happens to the team when this year's funding ends?
  • How would you know in six months that it had worked?

Either way you're listening for specifics. A real thing that happened, told plainly. If the answer is just another buzzword, like more strategic or more outcome focused, ask again.

A good answer probably means hearing no and we don't know yet more often than they do now. I'm not sure everyone asking for product thinking wants that part.