(2018-03-07) Mironov How To Structure Product Management

Rich Mironov: How to structure Product Management. My organisational theory basically says, "Handoffs are the enemy of insight."

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: Prioritize the backlog.

if you open the scrum book here’s what you’re going to find out: product owners must sit with their product teams 24 by 7 and always be available

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

There’s one more step, where I co-locate the product manager with the development team, and then I do something else really special

...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

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.

I believe that the scrum defined product owner job as written in every scrum book you’ve ever picked up is an entirely failed model if you’re in the product business.

Do you know about proxies? This is a curse word for me. Proxy means talking to somebody who’s not a real user, but has an opinion. (cough stakeholder)

This is an organisational problem. It’s not about you as an individual product owner, but that product owners are almost always assigned after we’ve made all of the hard decisions about what to invest in. So first we decide to do a whole major rewrite and refactor of our entire system, and then we assign 22 teams, and then we figure out who the product owners are. By the way, that’s a failed project even before it starts, and the product owners are stuck with it

Product owner is a ROLE. In my shops, it’s a role that every one of my product managers spends about half their time doing. It’s not a JOB

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 two pizza team. Can anybody tell me how big a 2 pizza team is? Audience: 4-6 people. Rich Mironov: 4-6 people, right.

You’ll see at Amazon or Google groups with 3 teams and 7 teams and maybe 11 or 15 teams.

What’s more important than stakeholders and organisations? Audience: 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 (GetsThingsDone).

I strongly agree: see My Product Development Process.


Edited: |

blog comments powered by Disqus