In March 2018, Rich Mironov visited Australia and presented to the Product Talks Sydney Meetup Group on building and scaling Product teams. This blog is a transcript of part of that meetup, focusing on why we need Product Management.
Why do we need a Product Management team?
I have 30 years in Silicon Valley product management, so this isn’t a new thing. Some of you may not have been born when I first picked up software product management. But it hasn’t arrived every place at the same rate. So if it’s still new in Sydney, great. I know that we’re growing it up.
Part of my journey was 6 startups. Four of those are what we call “good life learning and character building”. And what I do a lot of the time is parachute into San Francisco area companies as the interim or temporary Head of Product. Either the head of product walked out the door or the company forgot to have one or they don’t know how to spell product management. I come in for a couple of quarters to get everything running again. My recent experience is more with startups, and I tend toward enterprise rather than consumer.
I observe, certainly in startups but also in really big companies and everything in between, most of the folks are incented to think about the current quarter. Especially in startups, you know that your investors are going to have a really sharp talk with you at the end of the quarter if you miss your numbers. So there’s tremendous incentive to think about the next 31 days or however many are left in the quarter. Shortest path to short term revenue. How do we get the next thing done?
I think of product management as the folks who balance that wonderful enthusiasm with a little bit of market honesty. As in “Do we actually have market fit? I know you’d like to tell the board we have market fit, but do we have any evidence?” “Are we shipping whole product that actually works and solves somebody’s problem, or some fractional thing?”
[There are] a lot of fist fights about segments. “Are we really in a segment or have we just drawn a line around our first 4 live customers and anybody else who can fog a mirror and has revenue and will sign a purchase order?”
Startups as well as big companies tend to focus on individual customers, individual accounts. Do they have money? Product management has to be the organisation that thinks about segments and groups and overall success, or we end up in a pure sales-driven model that ends badly.
I think it’s our job as product folks to represent the customers as opposed to the internal stakeholders. The customers pay our company money. The stakeholders are internal folks. Who gets value? Who pays us money? Who rewards us for doing a good job in the market? We have to think about company-level things and product-level success rather than the individual enterprise sales team that gets to go to club in Fiji if they close that one big deal.
This is an input/output chart, with product management in the middle. I built this a decade ago for engineers because engineers need input/output diagrams to understand things. Product management in the middle, not at the top, because nobody works for us. We have responsibility but no authority.
Rich Mironov: What does a Product Manager do?What are the important things that flow from the product management group to development? And by development I mean everybody who does real work: designers, DevOps, tech writers, development teams, whatever. The folks who actually build stuff. What are we going to supply to them? What are they looking for?
Rich Mironov: Priorities are good. What else?
Audience: Problems to be solved.
Rich Mironov: Problems to be solved. I think that’s the winner for a book. What else?
Rich Mironov: Direction, yeah, not so much. We may give them direction, but they’re not excited about taking it.
So here’s my list. I start with context and conversation. We as product folks have to provide a really clear sense to our teams of why we’re working on stuff, why it matters, who it’s for, how it’s going to derive value, and why they should care. Somethingis really important for everyone in a product management job to remember is that every member of your development is smarter than you. How do we know this? Because we ask them. All developers believe they are smarter than their product managers. It’s a fact.
What they need, what they want from us more than anything else, is to know that they are building products that other people will use, that’s going to lead to value, that they will see in the market place, and it’s going to give them feedback that their work was not wasted. They may be introverted, but they’re deeply emotional about what they do.
There’s nothing worse than being on the engineering and development side, doing your best, and have the silence in the market be deafening. So as product folks, we must must must must share the love and the care for our users, set the context, share the problem that users have. We don’t have to actually come up with the best solution, because if you remember, our developers are all smarter than we are. So we need to get the smart folks together to find the solution, but we need to communicate context, market view, priorities, problem statements, ethics and user stores if that’s what we’re using. Typing into Jira is not how we add value, although sometimes we have to do it.
What do we get back from the development side of the house? Anybody?
Rich Mironov: Questions, yes. But that’s not what we’re looking for.
Rich Mironov: Solutions. On a good day.
Rich Mironov: Trade-offs, not really. Here’s what I was looking for: product bits. This is the part of the product that’s the actual technology or software. Your engineers actually believe it is the entire product. But it’s a part of the product. Not the whole thing. And we know this because what’s the marketing and sales side of the house actually looking for us to deliver to them?
Rich Mironov: Leads. Great, but no.
Audience: The prototype?
Rich Mironov: Yeah, the prototype, maybe. They don’t care.
Audience: Market awareness.
Rich Mironov: Market awareness. No, they don’t care. Well, marketing cares. Sales doesn’t.
Audience: Customer value.
Rich Mironov: Customer value, yes. Blah blah blah.
What sales wants more than anything in the world is a story that they can repeat to users or prospects that will cause the users and prospects to fill out a purchase order or send money. They want the high level. They want the message. They want the benefits. They don’t actually care at all about the features. Pricing because we shouldn’t ever let our sales team set pricing or bad things happen. Segmentation because it would be nice to know who this is for: small business, big business, solo entrepreneurs, consumers at home.
Rich Mironov: What do we get back?
Rich Mironov: Dollars? The dollars don’t come back to us. What do we get back?
Audience: User feedback.
Rich Mironov: We get feedback. What do we get feedback about?
Rich Mironov: Problems. I’m going to call it “input and feedback” but what I mean specifically is here’s why we didn’t close the sale. So if I survey your sales force, and I’m thinking again enterprise, what’s the number one reason we closed deals this quarter?
Audience: Because the sales people are so good.
Rich Mironov: That’s right. Because we have an awesome sales force. All of our sales people are above average. We are terrific. Coffee is for closers. If you survey your sales force about why we won deals, you will get one answer right away, which is that they are great, great, great sales people. Very useful. And the 2 reasons we lost deals this quarter?
Audience: The product.
Rich Mironov: The product. What about the product.
Audience: It wasn’t something we could sell.
Rich Mironov: Yeah. We’ll find out that we were missing just a couple of hundred features, right? And what’s the other reason?
Rich Mironov: Price. What about the price?
Audience: Too high.
Rich Mironov: Too high. Right.
Rich Mironov: So, if you survey your sales force to figure out how to improve your product you’re going to learn these 3 things: They’re a great sales force; that we’re missing a boatload of features; and that we should lower the price by 2/3. All sales forces will teach you this.
So that’s why it’s really really really really important that we draw this other connection between the product folks and your actual users, actual buyers, actual win/loss folks, actual prospects, where you are talking directly to the people who use the stuff because they’ll actually tell you something as long as you’re not on a sales call. They will tell you about their problems and their issues and what other things they tried. If you don’t talk to those folks, you don’t know enough. You don’t earn the right to deal with the folks on your development team — because they’re smarter than you and you don’t have any more data than them.
When I parachute into a company as the interim or temporary head of product I get an hour each with all the folks who are now on my staff and I ask them a bunch of questions. One of the important ones is, “How many customers did you talk to in the last 2 weeks?” Some of them will give me a good positive number, and some of them will tell me about a barrier with the sales team where they’re not allowed, and I can help remove that. And the third group who don’t talk to customers and don’t have a good reason for it, I look for a way to promote into some other department in the company because they’re not product people. Sorry.
Last thing. The executive team wants what stuff from us?
Rich Mironov: Roadmaps. They don’t actually care about roadmaps, but yeah.
Audience: Results and forecast.
Rich Mironov: Results and forecast. And what are they denominated in?
Rich Mironov: Revenue, right. And here we would say dollars.
Rich Mironov: So, what they’re really looking for is a revenue forecast and maybe some commitments and roadmaps. I observe that executive teams mostly can’t hear anything you say other than when it’s denominated in revenue and dollars. Don’t waste your time.
Rich Mironov: What do we get back from the executive team?
Rich Mironov: Funding. For?
Rich Mironov: Funding for development.
We don’t get money for more product management. We get money for more development because in every company it’s true that your development team isn’t as big as your dreams. And we have more things to build, so we are always always always pitching for more development teams so we can get more products built. So what we get back is a budget for development or staff for your left side. And, by the way, the target that was on my little forecast is what comes back, but it’s been moved forward 2 quarters.
And if I sit in that grey bubble, what’s really really important is that I have to be trilingual. I have to speak enough development that they don’t dis-invite me from the stand ups, lock me out of the room, look at my button-down shirt and get scared. I have to speak enough end customer user that I can empathise and understand their problem set, and I have to speak enough thumbnail finance on the back of an envelope that I could put a number or two that has a dollar sign on it in front of the things we need to do. A very strange odd intersection of skills. Nobody is born doing this. There aren’t a lot of 6- and 7-year-old kids who go to their parents and say, “Mom, Dad, I’d like to grow up to be a product manager.”
Alex Osterwalder. Anybody know Alex or his very famous books about the business canvas and the value canvas? Alex teaches something which we all knew but didn’t really get clear on – when we talk to customers, users, everybody, they will always describe solutions to us. And it’s our job to dig through that because the solutions they describe are almost always wrong. And we have to figure out what the problem was that caused them to create a solution for us, because they don’t understand our systems and they’re not software folks. They have the wrong view.
People always come forward with, “Here’s what I need you to do.” And they’re almost always wrong. But underneath it is a problem that they want or need solved, and they’re almost always right about the pain that they’re experiencing. So it’s our job to rip the solutioning off the top and dig deep to figure out what the pain or the problem is and reframe that up. Really, really important. Because if we don’t do that … If we do just what they ask us to do, tell us to do, we almost always deliver something useless.
Let’s talk about product leverage and a little history because I’m old enough to remember this stuff. In the 1980’s when I first joined the ranks of product managers, having a business case was actually an advantage. It was above average. It was a differentiator and a distinguisher, but that was in the 80’s and that’s over. Everybody needs enough of a business case to justify the thing they’re doing. Not a differentiator.
Rich Mironov: Where’s our Product leverage?In the 90’s we discovered, or maybe already knew about, whole cross-functional teams. That’s where we have some devs and some test automation engineers and some tech writers and whatever else we need, DevOps, on the same team in a stable configuration that we don’t borrow from project to project. That gives us a lot more joy and throughput and better product build. So in 1992 if you were doing that, you got bonus points and maybe some advantage in the market. Anybody who’s not doing that today? Didn’t get the telegram we sent out in 1993 from Silicon Valley to the rest of the world.
Agile Development. I’ve been working at Agile since maybe 2005. By the way, it was not new in 2001, but we didn’t know what to call it before then. When NASA put the first folks on the moon, it turned out they were doing a bunch of agile development on some very old computers. In the early 2000’s, you could claim some advantage by having a really good agile team that had good velocity and got stuff done faster.
So, there’s one thing that’s left, and this is also not new, but not uniformly distributed yet, is really understanding problems and then framing good solutions to those problems. You can call it Jobs To Be Done. You can call it customer development. You can call it validation, design thinking, whatever you want. They’re all synonyms for me.
We on the product and design side still have a chance to get advantage versus our competitors by really understanding the problems that customers have — instead of the solutions they want — and getting our teams together to really think as a team about the best ways to solve those problems.
The idea that we as product folks go out into the field and gather requirements as if we have a basket and they are daisies? You plucked ’em; you put them in the basket. You press them and you make user stories out of them. No no no no no no no! If we take what our customers ask us to do at face value, we mostly build the wrong thing. Even worse, if we take what our internal corporate stakeholders ask us to do on the assumption that they have thoughtfully talked to real customers, we’re almost assured of building something worthless.
So, we don’t gather requirements. We gather thoughtful analysis of problems, and then we bring it back to our teams … Because if you remember our teams are smarter than we are. So how do we get our whole team together to work on solutions if we’ve correctly framed the problem? We want to get some good solutions, and then we have to earn our real customers’ love and trust by delivering real good products that do the right thing and deliver value over time.
By the way, I believe we have an obligation of trust and honesty with our end customers. As a product manager on my team, if you lie to a customer and I find out about it you’re turfed. Fired. You’re out. There’s the door, don’t let it hit you on the way out. I don’t care what anybody else in the company does. Product managers are the people at corporate who represent their products and protect their products like their children because somebody has to, and we never lie to customers.
Alright, so that’s why we need product mangers. Somebody’s honest. Somebody thinks long term. Somebody thinks about customer value and segments as a whole and building the right thing and validation.
You can read the other blogs from Rich Mironov’s 2018 visit to Brainmates:
Thanks to the team at Campaign Monitor for hosting this meetup.