Rich Mironov on How to Structure Product Management

Rich Mironov: Let’s talk about product organisations.

My organisational theory basically says, “Handoffs are the enemy of insight. The distance — the number of conversational hops between the folks who build product and your users — is the most important function about whether we’re going to succeed or not.”

I’ll draw the picture for us and I’ll be talking about conversational distance.

Rich Mironov: Reducing distance. I’ll start with a dumb configuration, and then it’ll get a little better at each step. So the dumbest one: I show a development team on your left, including a product person. Notice I haven’t labelled anything more specific than “product” because I’m going to knock down some titles a little later. On the far side I’ve got the Gartner report, or your favourite bit of market research that wasn’t built specifically for you, and whoever they talked to (not mecessarily your customers) to get that information, and probably 2 years ago because that’s how long the publishing cycle is. So you could have a company that chooses what to build based on a bunch of market researchers’ interviews with some random set of people, no context, and whatever’s in the report. I can’t recommend it that approach very strongly.

So let’s do a little better. Let’s add our sales and marketing team and our customers, and all we do is we listen to or read the notes in Salesforce.com that our sales team wrote down at the end of their customer meetings. (Anybody been in that company, or still in that company?) Notice we’re a little closer: at least we’re talking to our own customers, but the gap is huge because sales people never really ask the questions that product folks ask, and they’re always trying to get to “yes”, and it’s always about who in the organisation can approve stuff and what their budget is. Sales teams take down key phrases, but they don’t actually know or care in detail what those key phrases mean. Not so good, but better than the previous one. Let’s move to the next one.

I’m carefully writing in the word product owner here, and apologies in advance if I offend anybody, but I’m jumping into the fray. There’s a business product manager or business requester on one side – which is the “business unit” — , and on the other side is generally “IT” or development shop. A little better, but Not much. Notice that there’s somebody on the business side who talks to users and customers but doesn’t actually know how anything’s built or what it costs or how hard it is. And there’s a product owner who is following only and exactly what the scrum book says. Can somebody tell me what the scrum book says product owners do?

Audience Member: Prioritise the backlog.

Rich Mironov: They prioritise the backlog. Good. What else do they do?

Audience Member: Write user stories.

Rich Mironov: They write user stories. That’s right. And they also accept user stories.

So, if you open the scrum book here’s what you’re going to find out: product owners must sit with their teams 24/7 and always be available.  That’s stressed in bold type. They write user stories. They accept user stories, and they prioritise the backlog. On what basis do they prioritise the backlog? How do they decide what’s important?

They talk to these folks over here, and if you remember these folks don’t know how systems are built and they’re mostly writing down verbatim what their customers told them because they don’t really have a deep understanding of how the systems work. So this is not the ideal thing.  Because the narrow definition of product owner means I never ever ever am allowed to leave my chair, go out in the field, and meet customers in their native habitat, and I have no reward structure that forces me to talk directly with end users. Now, some product owners are doing a great job and talking with end users anyway, but they’re mostly not in a reward system that encourages it.  So narrow definition of product owner and narrow definition of business unit create a very big communication gap.

So let’s draw something better:  here, I have a product manager, and I’m going to do some careful definition here. For me, a product manager is somebody who is  — in one single person — both talking with end users and working with their development team. They’re probably spending 50% of their time with the team and 30% of their time directly with end users, customers, and buyers/prospects.  They’re not delegating it on two sides where one does 100% of one and the other does 100% of the other. That’s a failure mode. I’m putting in a single person now, which means we’ve reduced the hops by one. Still not the best one, but at least we have one person who both talks to users and works with development teams.

There’s one more step, where I co-locate the product manager with the development team, and then I do something else really special. I’m going to embarrass Elizabeth Griffiths here. Is that okay?

Elizabeth: Sure.

Rich Mironov:  Alright. So Elizabeth Griffiths is a product manager here at Campaign Monitor, and she interviewed me, since I’m a Campaign Monitor user and customer. She and her team interviewed me about 3 weeks ago?

Elizabeth: Yes.

Rich Mironov: They talked with me over a video link about how I’m using Campaign Monitor and what I like and I don’t like… and in their conference room were a designer and two developers.

So, rather than Elizabeth being the person who takes all the notes and decides what she heard by herself and communicates it, we had in the room members of the development and design team who could hear for themselves, and some of them got to ask questions, so that we could get more of the smart kids in the room together to hear what customers say, and learn what the problems are, and ask hard questions of me – to get it direct from the source. That’s how the good kids in Silicon Valley get this done.

By the way, did we talk about motivation? So the number one motivational thing for our development team is to see and hear and listen to real end customers directly, saying “I liked it. I didn’t like it. I use it. Here’s why.”

That’s the #1 driver of productivity and joy for your development team. It’s having no mediation between them and the user.  (By the way, when I do these interviews I tell my developers they’re not allowed to speak until I know how they handle such situations. They can write questions on post it notes with real-time questions.)  But we’re side by side here. We do the discovery together so we can all hear it.

Designers hear different things than product folks, who hear different things than engineering and development folks. Let’s not have a pipeline problem. If I’m going to design a team structure that’s really going to work that’s what I’m going to do.

So now let’s finally draw some org charts because org charts are how HR folks think. So, here’s the product structure I like. There’s some value stream that’s part of my product suite. It’s some piece of the product where I can both have a focused development team that’s stable and long term (I don’t swap them out, I don’t borrow them.) . And I can identify who the users of this part of the value stream are. If it’s a debt collection module then I know who the debt collectors are and I know which team is building it. If it’s an admin and reporting module I know who the admin users are and I know who’s building it.

So the product manager is instantiating frequent in-depth conversations, and these are not sales conversations. Somebody tell me how you know you’re in a sales conversation.

Audience Member: Can we close the deal?

Rich Mironov: Right. How did this conversation start? A sales person called you up and said, “Can you get on the call?” That’s a really good hint that it’s a sales call. What’s your job in a sales call?

To help close, right? Because if you don’t do that you don’t ever get invited back. But there’s usually one issue that the sales team wants you to address and it’s probably technical. Address it and get off the call. You’re not there to ask long open-ended questions. You’re not there to fish for futures. You’re not there to have your prospect compare your product with competitors. You’re not there to mess up the sale. Sales calls are great, but they’re no way to learn anything. You’re welcome to be on sales calls, as you should, but let’s not count them as learning.

My product managers have frequent in depth non-sales learning conversations with users — and buyers if those are different from users.  With prospects, lost deals, all the time. 3 or 4 times a week. Because if my product managers don’t know enough, if they’re not the primary source of intelligence, and they lose the right to write user stories. Because user stories written without direct user/customer input are mostly those are the wrong things. Which means that product managers/owners lose the right to prioritise the backlog because they have no independent judgement  of their own, instead listening to various random stakeholders.

Rich Mironov: In my software companies we have no product owners. We have product managers. By the way, we pay them better [than product owners] and we promote them. So if you’re a product owner, go back and ask for more money and a better title.

The product managers own a piece of the value stream that includes development and users. If you’re not doing that, I don’t know what a product manager is. And because remember we’re scaling our team, let’s say that we have 4 of these product managers.

If you got 3, 4, 5 teams plus product managers, then you’re going to need a director of development — because the development teams need to report somewhere. And director of product, maybe, or a product line manager. But notice that each of the product managers owns the direct customer relationship and therefore the judgment about what’s important.

So, again, I love product owners individually, but I never have product owners in my organisation. You’re either able to do this job and I promote you to product manager and give you more money and more stock options… Value is striped across left to right. We don’t do column title divisions where we have product owner here and business unit there because it doesn’t lead to good results. I love the scrum folks, but I don’t think most of them understood how products are built for the commercial software market.

Rich Mironov: Let’s look at a few other ones.

Here’s a structure I don’t like. We have that same picture, but the product line manager does all the customer interviews and filters all the stuff and has all the opinions and represents all of the pieces of value. We’ve added a hop. We’ve added a handoff. We’ve reduced all the veracity or truth or content or flavour. We’ve washed out all the good stuff, and that’s the “I want to be the boss of you,” story.

In Silicon Valley where we pay people astronomical amounts to be super smart, the “I’m the boss of you” theory is a pretty lousy answer.

Rich Mironov: No surprise, here’s a product structure I hate:  I see organisations that split IT from The Business. We build stuff on demand from the business, but rarely build anything deeply useful in the process. It’s already broken even before we put anyone in any of the jobs because IT is rewarded for reducing costs and IT is rewarded for delivering on time — delivering whatever these folks on the business side wanted… and remember that they don’t understand the choices we have to make.

So, on the right side you have all kinds of people who are demanding things, and there’s some political process where somebody important makes a list. We don’t know why. But somebody important makes a list. On the left side we’ve got a CIO, and we almost always have pools of resources. Anybody want to go to work every day because they’re a resource? Pools of resources is demonstrably the worst way to build software.

We’re going to borrow people for short-lived projects. They’re not going to own the things that they had before.  Pools of resources is a sin in my book, although it’s legal in some countries. I don’t care if you’re a product owner, a tech product manager, a BA: if you’re working with a bunch of borrowed folks for the short term, trust is missing. Everything is missing.

Across the top, we’re going to flow technical requirements and dates — on the assumption that the people on your right actually know what they wanted. And by the way, the requirements and dates never line up. The dates are always more aggressive than the technical requirements, and so we’re going to cut scope and promise things on time, and our job on the IT side is to deliver what was asked for on time.

Notice it has no discussion of end customers who pay our salaries. Not a model that I love. I know it’s in a lot of places, but in my view this doesn’t deliver good results – yet costs billions and billions. Anybody unclear on where I stand?

Okay, let’s do the last thing. How big is big? And for me this is important. I believe that building software is still as much craft as it is science. We know that schedules only go one way [later] because all developers are optimists and estimating is hard. Software is among the most complex artefacts of the human intellect that have ever been built. When it gets big, the complexity goes up probably as the square of the number of people working on it. I’m going to try to paint big, and then I’m going to put a line on it.

Let’s invent the largest reasonable project or product. Let’s give ourselves 1 VP of product management, 4 directors, and 6 product managers. That is actually not so much, and that’s not a limiting factor, but then we match ourselves up against the much larger engineering and development team: 1 VP of engineering, 4 engineering directors, 6 functional managers, 16 teams with one product managers matched to each team, but still spending half their time with the market. So if I have 16 product managers I probably have about 16 teams, and engineering or development organisation will have about 200 people.

I observe in my few decades that really big projects — bigger than this — almost always fail. The complexity of a really big piece of work is such that we can almost never really understand it or its dependencies or its interfaces. We’re going to try to do frequent releases at the team or the group level so we can get stuff done.

But big projects almost always have long timelines, don’t they? They almost always have huge coordinating committees and architecture groups. They’re almost always waterfall because you can’t organise more than about 16 teams in any other way.  (I call BS on folks who tell us otherwise.)

I think when you get something bigger than this you have to break it into smaller pieces. Anything that’s bigger than this you better split it to several distinct products, or some architectural work where your brilliant architect figures out how to have two completely distinct groups with carefully defined APIs and data structures.  You’re going to fully automate all your integration and performance testing so you get the pieces together. I think anything bigger than this is a recipe for disaster.

I observe that huge projects almost always fail. They fail of their own weight.  Yeah, so how do Amazon and Google do this? Amazon is huge, but their functional group is the 2 pizza team. Can anybody tell me how big a 2 pizza team is?

Audience Member: 4-6 people.

Rich Mironov: 4-6 people, right. So Amazon actually has a lot of things going on, but they don’t have a single project that has 1000 people on it because they know that that simply doesn’t work. They have many, many separate things going on.

If you look at the AWS organisation, which is really big, it’s broken into lots of pieces that work independently. They have their own value streams that maybe have their own pricing lists, that have infrastructure choices. They’ve carefully architected the work.

They’ve broken it up into smaller pieces because smaller teams are more efficient, get more done, and are successful. You’ll see at Amazon or Google groups with 3 teams and 7 teams and maybe 11 or 15 teams. When you get beyond some number, and I like to pick 16, it crushes under its own weight because of the cross-dependencies and the complexities and the architecture and the reporting. And then of course you need 3 months to get started and 3 months to do testing at the end, and that 9 month schedule looks like 18 months.

Think about every big insurance company that’s taken on a 500-person 2-year project. Anybody ever worked at or with SAP? How did that go for you?

Audience Member: It’s horrible. You have to memorise how to do things.

Rich Mironov: That’s right. You have to memorise how to do things, and for SAP a short project is like 500 people from Deloitte and 3 years and $50 million, and usually you got cancelled halfway through. A big waste.

I’d call out the cognitive load, trying to understand what a 500 person application is … I don’t know anybody who can do that, and that means that the folks doing the upfront design aren’t getting it right enough that the waterfall model works. Dependencies, discovery, whenever we do something that big we’re going to find a lot of stuff. The pressure is not to slip.

So what do we do? We sacrifice all the integration testing at the end. I believe you can’t do anything that’s agile that’s 500 people wide. Nobody can comprehend a really big system, so there will always be discovery. Nobody actually knows how your current system works, and so replacing it as a whole is a fool’s errand.

Any plan that’s longer than 12 months probably sinks of its own weight. Instead, what can we do in 6 or 9 months that adds value and does a partial solution that the market can actually use. Scope creep is a function of duration. For a 12 month project, I know it turns 18 months when we look closely.

Full system replacement, which you sometimes call fork uplifts.  We take the old system out. We put the new system in. We expect it to be plug compatible. It’s never happened in the history of the world because no one actually knows how the current system works.

It’s been patched and it’s 30 years old and it does all these cool things and it’s got business rules in the wrong place, and the people who built it are retired. We don’t know how our systems work, and so the idea that we’re going to write down exact replacement requirements is foolish.

Okay, I think I had one more here which is, anything that takes 2 years is getting no market feedback, which means you probably made a bunch of mistakes. We all make them. But if we make mistakes with a 3 month shipping cycle, then we only waste 3 months and we get punched in the nose a couple times and we fix it. The 2 year cycle, which is always a huge project with 500 people and probably costs $160 million — that’s a lot of waste. And we got no feedback and we don’t know if it works.

The things we thought of as new 24 months ago aren’t so new 2 years later. I observe that I don’t want to scale my product organisation beyond about 16 product managers because I don’t want to be the guy at the top of that chart who comes back 2 years later and says, “Sorry. Wasted your $160 million and my 2 years of life that I can’t replace.”

So our take away is … that we talked about stakeholders and organisations. What’s more important than stakeholders and organisations?

Audience Member: Users.

Rich Mironov:  Users. That’s right.

I don’t know if anybody was alive when the first Tron movie came out, their tagline was “I fight for the users.” Everyday, I come into the office to fight for my product and for my users and for the value users  are going to get. Everybody else is interesting but they’re not my customers. Stakeholders are not customers. They don’t pay my company hard cash money. They’re just people between me and getting the job done.

As a product person who runs product teams, I need everyone on my group and everybody on my development team to come in everyday to say, “We fight for the users,” because the users are who love us and pay our bills.

*   *   *

If you’d like to follow Rich Mironov’s work, you can read his book ‘The Art of Product Management’, check out his website, follow him on Twitter, or see his experience on LinkedIn.