Rich Mironov: Hiring a Head of Product

If you don’t have a Head of Product you may suffer from: narrow focus on engineer/development productivity; underpowered product management teams; customer benefits misaligned with actual features; and lack of a realistic product strategy.

But it’s hard to hire a Head of Product. We don’t know what product leaders do, and disagree about what’s most important in a new one. We write wildly aspirational job descriptions for candidates and we confuse subject/market expertise with product management/leadership experience to name just a few errors.

Rich Mironov wrote The Art of Product Management and is a voice for the scrappy entrepreneur in all of us. In this talk from BoS USA Online, he looks at the important aspects of product leaders:

  • Organizing the product organization.
  • Cross-functional leadership.
  • Building what users actually need.

Slides

Want more of these insightful talks?

At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.

Sign up for a weekly dose of latest actionable and useful content.


Unsubscribe any time. We will never sell your email address. It is yours.

Transcript

This normally wouldn’t be an hour, but we’re going to chop it down and speed it up and keep the back half hour for q&a as we go. Great. So we’re gonna talk about hiring a head of product. And as Mark said, I think this is really a general topic. But because I’m a pure software product management guy, I’m telling it from my side of the story. So, you know, we’ll be able to generalize quite a bit, but we’ll take it from that point of view.

Okay, just a very brief introduction for me. Quick hint, I’m on the right in this photo. On the left is my other office manager, Celeste, Olivia may join us as you saw during the warm up. So what’s important about this for the talk is to set up why I think I might have something to say about it. I’m a 30 plus year veteran of Silicon Valley b2b enterprise software. So I had my first product management job in the late 80s. It’s not a new thing. And these days, I’m spending a lot of my time helping software companies design their product organizations, coaching their product leaders. And then you know, the statistic that’s probably important here. So in the last 19 years, since I went solo, I’ve done about 150 engagements with different clients, of which a dozen are what we’ve called the smokejumper, VP product jobs. So that’s where I come into a company as the interim or temporary head of product for usually a couple of quarters and get everything straightened out. I’ve also done a little over a dozen assistance roles where I help my clients figure out who they need as head of product, and then interview the candidates and be part of the the assessment team, which is really where this is coming out. So having done a few dozen of these, I may be, you know, more frequently in this role than anyone else on the planet other than folks who are in the search business themselves.

So I’ve tried to pull together some observations that might be useful for us, you know, of course in the narrow: how do we hire head of product? And in the broader: How do we apply lessons to some of the other departments?

Using the Proper Title.

Okay, let’s jump in. The first challenge I think we have is, nobody seems to know what to call this job. So here’s our caped crusader hero, we don’t know this dog’s name. But what I observe is that I’m going to use the phrase head of product, H O, P, because we need to call it something. And I’m going to specifically say that what we’re talking about is folks who manage product managers. Again, this would seem obvious, most of this is obvious, but I’m discovering that it’s not. Sometimes we call those folks Chief Product Officer, VP, Product Director, product, group, product, lead, whatever, whatever. And this person might also have, I don’t know, a couple of designers, there might be a market research person or whatever. But I’m specifically going to not talk about folks who are mostly running development or engineering teams. So there’s lots of the piece of product out there with many different names CIO, CTO, General Manager, I observed that if you are managing, let’s say, 85 developers, and for product managers, most of your brain is on the development side of the house, not the product side of the house. So I’m going to not include those folks in our little breakdown here.

Common Failures.

Okay, here’s our little bad dog. And, and a few of the failures that I see over and over again, as we say, you know, what are the primary failures that either I’m called in to fix, or I’m stuck on the side of the road watching the accidents for, and there’s really three.

1. Lack of Experience.

The first one, which is maybe where we’re gonna spend most of our time for the next 40 minutes, is companies that hire somebody to be the head of product, who’s neither led a product team, nor been a product manager, this is a head scratcher for me, but we’ll break it down a little bit.

2. MTBE – First PM Quitting.

The second failure mode I see is, if you’re the first product person in the door at a startup, or the first head of product at a startup, it’s pretty rare for the founders to actually give up the autonomy and control that they need for you to succeed, even though they say they do. And so I see the duration of that first head of product being pretty short. The acronym sometimes we use his MTBE, meantime between executives.

3. Confusion.

And then the third thing that really contributes I think to what we’re going to see is that many of the folks at software companies who lead software companies who found companies don’t actually understand what product management does. And so they’ve got some real misapprehensions or confusion around what it is that they need and have a product.

Okay, so because I don’t want to be talking the whole time, we’re going to do a little experiment here. We’re going to try a bit of a tweetstorm. So if I can ask get everybody to open up their chat box. And here’s the question I want you to ask, don’t hit return yet. So type in your answer, and then we’ll all hit it at once. So we can all see it at once. If you are going to be interviewing somebody as your new potential VP of sales or Chief Revenue Officer, what’s the first question or two, you would want to ask them? I’ll give everybody a minute. And then count to three, count to four, count to five. All right, when you have an answer, hit Return, and I’ll pick a few of them out of here. Okay, that’s right.

Tell me about your first sales job. How do you increase sales? What’s your sales strategy? What’s your sales process? Excellent. How much revenue did you earn last year? What was your quota?

So those are all questions that would suggest that we’d really like to have somebody as our VP of sales or chief revenue officer who has been a salesperson and maybe lead salespeople. Because it turns out there’s a lot of art and science. Yes, I do know Paul Kenny, and I think he’s brilliant. And I rarely see a company that hires a head of sales who has not been in sales before, although, in full disclosure, one of my clients had somebody running sales who’s really a finance guy from m&a. And that’s a lot more challenging. Likewise, if we’re going to hire somebody, as our Chief Financial Officer, we’d really like to know that they understand payroll, and how to run an accounts payable or receivables group, how to keep our executives out of jail by not running out of money. If we’re gonna hire somebody who’s a VP of engineering or a CTO, we might, for instance, want them to have built software before that would be really handy. Maybe even run a software team or two, because if we dropped somebody in his VP of engineering, who thinks that software is neat, and might like to build some, someday, we’ve got a lot of hurt on our hands. Again, it would seem obvious, but what I noticed over and over again, and it’s Tuesday, I had this discussion twice yesterday with some of my clients were at the very, very top in the very first position of the requirements for this job of head of product, what we don’t find is, in a product manager, run a product team. Okay, so let’s, let’s get back to our animals just a little bit and consider some different animals we might want for this job.

All right. Certainly here, here’s my ideal candidate for the head of product, you’ll notice this Australian Shepherd is going to move the sheep along. Everything about this head of product job, particularly at a startup that’s trying to find its way is thinking about the market and the segments, not the individual, not the one sheep, we’ve got to move the whole herd to wherever the water is, instead of letting them wander in all directions. Do we have a clear strategy? Is it tied to what our development team is going to do? We’re going to measure outcomes, can we move the whole company along toward our product goal and our revenue goal. An important useful fact here is that nobody works for product management, we’ve got lots of responsibility and absolutely no authority. So other than nipping at our heels and moving people along, you know, not many sticks to swinging there. And a lot of it is about long term thinking, if we’re going to get the whole company toward a strategic outcome, we’re all going to have to work together, we’re going to reduce distractions, we’re going to block interrupts, we’re going to hate one off requests from customers that somehow are going to distract us.

And I know as, as the many time had a product, every single department in the company is going to wander at some point. And we’re going to have to keep calling them back with reminders. Who are we selling to? Why are they going to buy? Is this the most wonderful thing? How do we talk about it? Okay, so there’s our animal choice for head of product.

Let’s pick a few more. Here’s our Chief Revenue Officer, our VP of sales, very aggressive by nature, you know, fast, lethal. But what else do we know about these, these hunting cats, they’re very focused, they bring in the red meat, they tend to be single account focused, right? They’re gonna find the weakest prey out there, whichever the envelope is easier to bring down. And they’re tremendously focused on the current quarter. Every salesperson I know can tell me to the exact number, how many days are left in the quarter and how much of their quota they’ve retired. And they strongly believe that they really know exactly what the customer wants, even though everything about selling is about pushing our point of view and getting the users or the buyers or their prospects to say yes, instead of delving deeply and finding out what their real issues are, so we can solve them.

When I see product management teams working for sales – so either we move the product team under the sales organization, or we bring a head of sales over to run product very quickly. What we discover is the whole product team has really become the order ticking handmaidens to sales. We’re working on single decks for single meetings or customers. And we’ve given up our whole strategic roadmap in favor of whatever the top few customers have asked for in the last, I don’t know, 10 minutes. Okay.

So while I love having a head of sales, a chief revenue officer, and I’ve failed at doing it myself, so I know it’s really hard, I can’t see bringing those folks in to run a product team. Okay, some other choices. For any of you who are CEOs, I hope this looks familiar. When I see a CEO who’s doing well seven other things, and has one of the eight tentacles on the product side, we’ve got a part time time sliced person running product. Generally, the failures I see are around sampling. Many of you who been CEOs know that the most frequent calls you get are for some big current customer who’s unhappy, because you never hear from the small ones. And from all of your sales teams to help you lobby the next sales deal. So you’ve got a very strange recency bias view of life. And you’re not going to be able to spend the time to worry about strategy and product and pricing and positioning and all the things that product needs to do. So we need one of these CEOs, but we sure don’t need them as a head of product.

Okay, a few more choices. Let’s think about our VP engineering because often, I see the product team tucked in under the CTO, the CIO, the VP engineering, and these tend to be a lot more methodical, they’re orderly, they’re thoughtful, they’re patient, tough, right? Many of them are nocturnal. We don’t see them so much early in the office. And while they’re very communicative, they’re mostly communicate over Slack. So we don’t hear from them that much. We know they’re emotional, but we don’t see it so much. And what I see often with VPs of engineering, is they have this very odd strange belief that all of our customers are rational, that they evaluate all the tech or product strictly on a rational straightforward bases. And that buying and selling are easy that what sales reps do is they bring a price list and a presentation, and they collect purchase orders. So while it’s great, again, to have a VP of engineering, they those folks tend not to have strong understanding of selling, or marketing or positioning, or many of the things that we have to do on the product side. So stuff gets sold. So not as bad as some of the other choices. But again, not my favorite, let’s go we have a couple more choices.

Here’s some folks I love at every company I’ve ever worked for. They’re the customer support and Customer Success people. What do we know about them? We know they’re tremendously huge supporters of their customers, they’re going to go the extra, not just the single kilometer, they’ll they’ll go the extra 100 miles, they do tend to be single customer or single account folks at a time. Often your customer success team is assigned long term to just one customer. And as you can see here, they’re willing to take that one customer over every bump and through every traffic signal and stopping at every corner, whether that’s good for the company or not as a whole. So they’re never trained to say no, they’re trained to say yes, and to help that one customer figure out how to do the one special thing. When we put our product hats on, we usually take a different point of view. Instead of asking how we can help be of the most help to our next customer. We ask how we can engineer away most of the human support, can we make onboarding easier? Can we create tools? Can we make the workflows better? How do we get out from under the support and success work as opposed to do more of it? And know that we’re the most important folks on the planet?

Okay, take a breath here. I think we’ve got maybe one more. Here’s the one that doesn’t happen so often, but I run into sometimes we’ll take a moment because you all know what the picture is going to be right? So here’s my new baby puppy, six weeks, or maybe six months as a product manager, excuse me, I usually expect it’s going to take maybe three or four years to grow this puppy up to be a really, really terrific product manager and another three or four years to grow them up to be a product leader where there might be a director and heading up a team.

And most importantly, having done this a bunch of times I know that when I’, hiring somebody who’s never been a product manager before I as the product leader, I’m going to spend a lot of time house training, right coaching and mentoring and business life skills. We’re not going to send this puppy in to an important meeting with our biggest customer until we’ve given it some training. And as every head of product knows, there’s going to be a bunch of accidents and we may have to clean up the carpet. Add or even replace it a few times. So, while I love having newly minted or freshly arrived product managers on the team, I wouldn’t put them in as head of product.

Want more of these insightful talks?

At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.

Sign up for a weekly dose of latest actionable and useful content.


Unsubscribe any time. We will never sell your email address. It is yours.

Common Misconceptions.

Okay, so we’re through most of our animals. Let’s, let’s open this up. Where are we? Here we go. And I think we want to, we want to ask you guys again, let’s come back to our tweetstorm. Just for fun, because I’m going to give us briefly really three different thoughts for, you know, misconceptions that may be underlying this. And I’m having a lot of trouble finding my chat window, but I’m sure we’ll get there. So go ahead. If anybody has an idea, why don’t you give me an idea – one or two or three – type them in, something that’s a core misconception from the rest of the executive team, about what product leadership is or what we need? So I can break those down. And don’t wait, just drop them in. It’s just about prioritizing work.

John, you’re exactly right. Doesn’t know the real value. Ouch, that hurts. It’s all about which feature next product owns the voice of the customer? Right? Getting software built faster? That was the winning answer I wanted. Only product management knows the answers. I believe that but nobody else believes it, right? Why do we need you anyway, engineering builds it, I’d love it. These are all spot on?

1. Product and Engineering Should Say ‘Yes’.

Okay, so here’s the three I picked out. The first one, and I think several of you said there, right? That what we really need is we need product engineering to say yes to the sales side of the house more often. And so therefore what product management product leadership should be doing? Is whipping the engineers harder, right? How do we get more stuff out of the development side of the house.

2. Technical/Marketing Expertise >> Product Leadership Expertise.

The second thing I run into a lot is, oh, well, our products really very complicated. And so nobody can understand our product unless they have at least one or two advanced degrees in our thing. So it’s not possible to hire any product managers, unless they also happen to have been at a famous university with a thesis on our stuff, right.

3. We Have a Clear Strategy.

And then the third one, which I think several of you had there is the executive team has this odd belief that our strategies are so clear, and so aligned and the OKRs is so well written, that everybody’s going to just do the right thing and be on the right page without much help. And honestly, I think I’ve never found this to be true.

So let’s unpack these three, just a little bit. And here we go. So if anybody’s at this engineering organization, but this is every engineering team or development team I’ve ever met, there is no development team on the planet that isn’t already overloaded and has too much to do 2x 5x 10x. Yet, the executive team tells us that what we really want is to push harder, right? So the executive team, the go to market team, there’s usually some hot issue in their head, right? Just got off a call with a customer. But every dev team is oversubscribed. And so we end up in this ADHD model of roadmapping. Where every 2.5 minutes, it turns out, we’ve got a new strategy. And the failure mode I see. In fact, I’m writing a really long piece for one of my clients on this is that we have too many number one items. And our answer when something’s important is to make another new thing. Another top number one items, so we constantly add, and the team actually never finishes anything. Right? So the reputation that engineering gets is that they’re losers or slackers are sitting around eating bonbons, when the root issue of course, is we’ve taken on four times as much as we can, and we’re thrashing.

Right second of these, right, only our special experts can understand here’s our product manager unable to find her way through the maze, because too complicated. And I’ve taken notes over the years. And the winner I think was, Oh, our company’s doing six factor authentication. And no one can understand Understand six factor authentication, unless they’ve got at least one or two advanced degrees in CES and authentication. So there is no product manager who’s going to understand this. Now, that’s a bit of a problem, not just for the product manager, but probably for the customers, right? Because if we can’t explain it to a product manager, then we probably can’t sell it to anybody. Right? And when we hire a subject expert who’s never worn the product badge before, here’s what I see.

First of all, those subject experts usually don’t ever think about the newbies, the onboarding, the economics, they’re always thinking about the two or three buddies of theirs, who are the power high end users, and they routinely decide that their point of view is so much more accurate than what anything we’re going to learn from customers is of course customers don’t know what they want that They put themselves in the place of already knowing all the answers instead of going out and doing what every good product person does, which is endlessly, repeatedly every single day, talking to lots of users and customers and prospects and partners and lost deals, to find out what’s actually true in the world. And my observation is, if you give your newly arrived Product Manager a couple of months of halftime, send them out on the road, have them do 20 or 30 customer meetings, they’ll come back understanding everything they need. So this idea is I think, fallacious, it’s just not true. But so many places end up hiring a subject expert who honestly couldn’t spell product, if you gave him all the consonants in the correct order.

And then my third one here, here’s our geese all lined up. Here’s our beautiful strategy. everything’s aligned, everybody knows where we’re going. The first thing I find when customers or companies adopt OKRs, is they adopt first just some revenue OKRs. Right, our goal for the quarter is to make 20 million. And, you know, that might suggest that I’m going to sell off some my household furniture for revenue or stand on the corner in a very short skirt, it’s not a pretty sight. When we try to, to figure out how to apply that to product, it’s a zero help in figuring out what’s more important, or most important, because we haven’t yet gotten down to target audiences and positioning and where we’re going to win where we’re going to not win.

The other thing I see in these organizations is that all the OKRs are really functional level ones. Finance has its goals. Marketing has its goals, and they simply don’t ever touch. Part of what we do is head of product back to our sheepdog is, I spent an awful lot of my time trying to get my executive peers to line up their their goals and maybe measure the right thing. I don’t know if you’ve ever been in a company where the support team has a goal of shortening their average call. And you know what they do it. And the way they do it is they throw folks off the phone, and they don’t solve the problems. So those people can call back, but the average call is shorter. You know, when we create goals, we have to be really thoughtful, because folks are going to do just what we asked them paid them to do.

Alright, so there’s our three misconceptions. Here’s a sort of takeaway thought for me, by the way, I put a post up over the weekend. That’s the long form text version of this. So anybody who feels like they want to read the 2000 words, just go to my website, but he was the takeaway from that, right? What are the key skills, right? A lot of negotiating a lot of empathy, a lot of horse trading among the internal stakeholders. But somebody’s got to stand up for the real customers. I’m always channeling the original Tron movie from 1982, where they say, we fight for the users, we don’t fight for the stakeholders, we fight for the users.

Interviewing.

Okay, so having done all that, I’m going to flash past three quick slides here. I’m not even going to bother reading them all. But I put together some interview questions that when we look at the videotape, or you pull down the slide set, you might want to borrow the next time you’re interviewing you had a product. So instead of asking how can we get more on the roadmap? Here’s a couple of better questions, right? And instead of how are you going to get more productivity out of our development team, whipping them harder? Here’s an alternative. Right? Likewise, instead of asking, Are you a subject expert? Have you worked in our exact tech segment and already know what customers want? Wrong? Here’s a couple of ways you might unpack that in an interview.

And then one last one. I’m not a fan of Net Promoter Score, because it’s pretty random and doesn’t give us much information and it’s easy to manipulate. So here’s a few better questions, then NPS score to figure out how we’re going to understand what our customers are doing. Okay, I want to leave a lot of time for questions. So let’s go to a few takeaways. Right? Got to have a treat at the end. Everybody got to the end. Here’s your treat. So here’s our three things, right. And if we were in the hall together in Boston, I might actually ask everybody to stand up and repeat this. But I think you can do that in the privacy of your own desks here. Right? Product management experience, product leadership experience. Before subject market technical specifics, right? Please, Oh, please, oh, please, don’t bring in somebody just because they know your tech.

The thing we do, how do we add value? Why do we care? Why does anybody else care? It’s because often the product management team and therefore the product management leader, are the people balancing long term scratch strategy against current quarter execution. And we are endlessly battling the fight of should we do this one special little thing for this one big customer who promises never to ask us anything else again, at least until later in the day? Or are we going to let the entire development team be diverted to whatever three or four shiny objects have come up in today’s sales calls? And then, you know, what do we do leadership skills, things we need, right? We need to be able to keep the rest of the executive team focused. not trivial.

We need to keep our eyes on the market success, the segments, the larger picture, not single accounts, we got to spend a tremendous amount of time understanding and loving all of our peers across all the organizations. And then last of all, back to our puppy photo. We’ve got to raise those young uns, those soon to be product managers, mentoring, tutoring, teaching them how to do it, cleaning up the carpet as necessary. So that’s the things I think we’re looking for in a head of product. And I hope that that helps us helps you with a better frame around that. And then just circling back to Mark’s point from the very beginning, you could apply this to any of your functions. I just happen to tell it as a product leadership story, because that’s my part of the problem. All right, here’s how to find me. That’s the website. That’s the email. That’s the Twitter handle. Anybody notice it’s hard to spell, but it’s all the same?

Want more of these insightful talks?

At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.

Sign up for a weekly dose of latest actionable and useful content.


Unsubscribe any time. We will never sell your email address. It is yours.

Let’s have a little round of applause first.

I’ll pick a few of these off the chat, just start. Anybody wants to break in with with the audio later. So so lots of good questions.

Why Are These Issues so Difficult to Solve?

I’m going to start with with the top one from from Brian: these issues have existed since the beginning of software product businesses. Why is it so hard to solve? I think part of it is that most of what product management does is sort of transparent, right? When it’s working, you don’t see it. And when it’s broken, you’re usually miss attributing it. So most of the calls I get are from CEOs who tell me their engineering team doesn’t work hard enough or isn’t productive or is lazy. And then when we open the box, we figure out that there’s no goals for the company, or they’re in complete conflict. And the CEO comes down no more frequently than let’s say, every 25 minutes to the development organization with a new number one priority. And they’re dejected and frustrated. And what they really need more than anything else is a product management team, especially a head of product, that’s the semi permeable membrane, the funnel, the umbrella, such that the rest of the company has to go through something painful, before we can interrupt what we’ve already agreed to be in the sprint.

So that’s not the obvious skill. Everybody thinks about writing user stories. Honestly, I don’t care about user stories, and I don’t care what format we have them in. Turns out a grammatically correct user story is usually probably still the wrong thing we should build. It’s not the grammar we want to check. It’s whether we did our homework and truly understand our customers, which is hard to see. So the other thing, the failure mode here is a lot of folks have never been at a company where product management was any darn good. And so they don’t have a model in their head what we’re supposed to do.

Building Strength of Your Voice.

Okay, good. Tim Burgess: How do you build consensus or strength of your voice when the other executives are ostensibly more important? or higher profile?

Really good question. I think of every good product manager, as a student of human behavior, right? We’ve all read Dale Carnegie’s book from the 1920s, about how to make friends and influence people, we all understand what the different departments value and how they’re measured. We think a lot about motivations and goals and alignment. And so for instance, the way I talk, the marketing and sales side of the house, through my roadmap, is entirely different than the way I’d go through it with my engineering team. It’s the same roadmap. But on the sales side, we’re almost all talking about who it’s for, why they want it, and how can we should be able to get full price for it. Whereas on the engineering side, we’re talking a lot more about the inner workings of the problems we’re solving. So there’s a lot of channeling the different audiences and what they need. And then there’s a tremendous amount of honestly, horse trading and alignment here.

Many of you know this, but every single person in your support organization expects to get 100% of developments effort against fixing bugs. And everybody in your sales organization expects engineering to spend 100% of their effort on whatever these new deals need. And your success team wants 100% of their effort against simpler workflows and better onboarding. And your engineering team wants to spend 80% on fixing your tech debt and doing factoring. So there’s actually no way to get to a good answer here. Unless we set up some you know allocations in agreements about how we’re going to work here. So I spend a lot of my time trying to get consensus on how we’re going to spend our general money before we fall down the rabbit hole of tickets. Okay.

Order of Hiring.

David Carta: what order would you hire people beyond founders, CFO, product manager, VP sales.

That’s a hard one. Because usually the founders come from some side, if they’re technologists, I probably want to get maybe an early business development person as opposed to a salesperson. Because for the first year, honestly, we don’t know what we’re selling. And we’re going to have to take our word back a few times, I usually expect a company a startup to hire its first full time product manager, and about 12 people. Because then by then you’ve got a development team and engineering team of six or seven, that’s enough to justify a product manager, I don’t really see a head of product or VP of product until we get to, I don’t know 3035. Because there’s just not enough scope there. If I come in as the head of product at a 12 person company, I have to be also willing to do all the individual contributor work, which is fine, but not everybody is willing to do that. Okay.

The CEO Giving Up the Reins.

That’s a great question from Go ahead. And Mark Davis wants to ask the CEO to validate they do in fact, want to give up the reins.

This is hard, because almost every CEO will say yes to that.

Really no, right?

That’s right, in practice, so I’m not sure there’s a question I asked the CEO directly. Advice I give to folks in every job: if you’re interviewing for a job at a company is find some folks who work at the company who are not on the interview roster, get into LinkedIn figured out who you know, or who you’re connected, one hop away from. In a better time, I would have said take them out to breakfast. But right now, it’s virtual coffee, and ask a lot of questions about the company. Because first of all, you want to learn about the company before you get too far in the interview cycle.

But a question I always ask or some variation is, would you recommend a good friend of yours work at this company? Surprising how often that answer is no. How about did the CEO have a bad childhood? Often? That’s it. Yes. Right? Well, what we’re looking we’re looking for here is somebody who’s not sufficiently biased by being in the interview cycle, which means they’re trying to sell me on the job and figure out if I’m selling hard enough, but find somebody whose objective is going to tell you what’s going on, what are the company problems? How are they doing? Are there layoffs coming? Just does this person get joy coming into the office? Because I find when you could answer get good answers to that your CEO is most likely doing a lot of the right things. And there’s a good chance that that head of product is going to be allowed to succeed. I would say half the time on those discussions. What I hear back from people is, huh, huh? Can we take that one offline? And no, I wouldn’t recommend that my best friend take a job here. Right? You don’t want to work there. Move on. There’s other jobs. Okay, how about one other one? Should I just pick one out? Or if there’s somebody who wants to come in on audio? That would be fun?

I think yeah, let’s find someone that wants to come in on audio.

Accountabilities of the Product Manager.

Q: So I find that in a lot of companies, the head of product means a lot of things. And sometimes it’s like, encroaching across everything in the company. And it’s like owning the customer. And I don’t know why. But so I just want to clarify and have some opinion from you. Like, what should be the accountabilities of the head of product or the accountabilities of the product function?

Yeah, and this is hard, because none of the things that Product Management delivers are direct customer consumables, right? And products not actually in control of any almost any of the resources in the company. It’s hard to pin either success or failure directly on product. So I look for a lot of of secondary things. Does everybody in the company really understand what’s on the roadmap? Are we selling to the right segments? Are we mostly able to prop up our prices and sell for something near list price? A good secondary thing is that sales doesn’t hate engineering. And engineering doesn’t hate sales. Because by the way, if that’s the case, product either can’t succeed, or has failed miserably, right. So notice, those are all sort of interstitial things. Do we have a product strategy that we stick to? Again, you can knock that down from almost any department, but if product succeeding those are things that everybody immediately says yes to. And so the head of product is as much intent internal salesperson for clarity and strategy and segmentation in targeting and staying on focus as anything else. Thanks. Sure.

Delegating Responsibilities.

So Peldi asked a question, which was skelding. Any tips for founders, CEOs to delegate Head of Product responsibilities? Probably being unusually shy today?

Yeah. I don’t know why Peldi. But I think the that is the right question, which is, can I feel comfortable enough delegating to the head of product. And generally, the failure mode here is around the CEO believing that they are in fact sampling the customer base adequately, and that I know what customers want, because I’m talking to a lot of customers. And the reason that doesn’t hold up is because at least at this stage, almost all the conversations that the CEO is having with customers are pushed, they’re selling, they’re trying to get somebody to agree. And what you do when you listen to those calls with the CEO is you find out the CEO is talking 70% or 80% of the time, which is a sales call. And the folks at the other end are either politely listening or raising small objections. But they’re not really saying what they think the other thing that CEOs and founders get is they get the rapid escalations from the few large customers of random things they’re unhappy about. And so they decide that all customers are having this problem, because they’re sampling badly, right.

And so, as a head of product, what I need is some agreement from the CEO, that if I can show data, if my team is interviewing 40 customers a month or 90 customers a month, that we’re going to get believed that when we identify that 65% of the customers have an issue, but it’s not the one that CEO heard about this morning, that we’re gonna get a hearing on that and facts matter. And that’s really hard emotionally for the CEO, because, you know, we’re all the center of our universes. And we believe that what we’re seeing is a you know, an effective and well sampled pattern.

When Should a PM be Hired?

Okay, I’m gonna pick one more, Tim, we got from Tim, how about Elizabeth Aveda: when should a company hire it’s first product manager? I think we touched that, you know, again, I’m thinking like 12 employees, 14 employees.

Capturing Customer Understanding.

Let’s see what we got. Igor says: In what form is understanding the customer captured? Is it just in a product managers head, this is a really hard problem, because it’s rather unstructured. One of the ways I coach my heads of product and product managers is, first of all, every time we interview a customer, assuming it’s not a sales call, I want to include on the call a designer and developer. Now, they probably don’t talk, I run the interview. But it’s very clear, they hear different things than I do, and they listen for different things.

And we usually have some regime where either they write me a post it note, or they drop me a Slack message on the side for questions I’m missing, right, we might have an hour’s conversation with a customer. So we’re going to capture that we’re gonna record it with permission, of course, don’t want to break the law, we’re going to put that in a repository. But right next to it. At the very end of the call, as soon as we’re done before it falls out of our heads, we’re going to among ourselves, pick the three or four or five takeaways, lessons, interesting things, put them in bullets at the very top, and send around to the rest of the company, the three bullets and a link to the recording. That’s important because we do it right away. So a recency bias isn’t going to get us in trouble. It helps because the rest of the company starts to notice that the product team actually talks to customers all the time.

And then, in general, I find that we don’t know the right questions until 10 interviews in or 15 interviews and we have to go back and read our notes. Because something popped up in five of those conversations, that was so bizarre, that we never even thought to ask and we’re going to go back to our notes back to our recordings, and figure out if it was a pattern. So that’s a way that we can share them out, get this summary to the rest of the world. And anybody who needs to dig deep configure out which transcript or recording is going to have the detailed stuff in it.

Smokejumper Role.

Q: Hey, thanks for just a great talk and answering so many questions generously. I was wondering if you could talk a little bit more about the smokejumper role and outside the context of just fighting a burning fire but also like as a transition or even alternative to hiring a full time executive.

Yeah, so I’ve done about a dozen of those. And every time I promised myself not to do it again. Because honestly, they’re they’re really hard and irrationally painful. And it does borrow from the firefighter terminology because the, the smoke jumpers are the ones who are parachuted on the far side of the fire, to knock down all the fuel, and they don’t get to go home, smelly and tired and smoky until they fought their way back through the fire. I don’t advise anyone to do this, if they have a choice. You’re bringing in an outsider who doesn’t know the company and doesn’t know the product, I’m generally much more effective in that first quarter, or quarter and a half. And fixing organizational issues, and process issues and goal issues, I’m never gonna be smart enough about your product in three months, to really have strong opinions about the product details.

So generally, I’m called in when it’s really broken. And I want to leave as soon as possible. And the company wants me to help them hiring a replacement as soon as possible. Because every company deserves a full time head of product, who has the long term understands the trade offs, loves the customers with all their heart and soul, and understands how to move the other executive players around the board. So we get the right things built and shipped. And that’s a lot of internal discovery. It’s a lot of relationship building.

The one dirty secret here, which since we’re recording everybody’s going to know is as the interim, here’s here’s my other office manager, by the way, as the interim head of product, I can say and do things that no full time employee would ever say or do. I can be as blunt with the CEO and pull them aside for coaching about things that you would never do if you want to keep your job, because I’m leaving anyway. And there’s no stock options for me. And there’s no bonus for me. My job is to clean it up and get the heck out. And so I have a lot more freedom of movement. But for a limited time, because you don’t get away with that for more than a quarter or two. And I’m usually burned out by then anyway, so time to go home. I can’t I can’t tell you that that’s something you would love. But it’s strong medicine when you need it.

Relative Roles.

Well, that was actually a reason for picking on picking on Jeff. He asked that question earlier on about relative roles, or roles of head of product versus some of the other bits of the team. Jeff, do you want to speak?

Q: The question that Tomas asked in rich well answered to pretty much covered the majority of that, like from the standpoint that? Yeah, I think there’s this really interesting thing where this sort of there’s these accountabilities, probably the the product team typically has that there is responsibilities are tough to fall through. And, again, I thought rich painted it really well. Maybe the only thing I would add, there was the other nuance was, yeah, if we were just complete a more organizational picture. And that same sort of vein, what then is the accountabilities of, say engineering and maybe marketing in this role of figuring out the product. Conversely, to it Rich said, because there’s this interesting trend, where some people have talked about how product management is a separate, not as a role. It’s obviously a very important role in the company to, to focus on these accountabilities. But that, as a separate vertical department in a company is a could be a little problematic. In other words, why isn’t product considered part of the engineering organization, for example, an organization right.

And the challenge, if you have a 13 person company, you can’t have I mean, 13 departments, but I observe that the engineering team is really measured and rewarded by getting things done. But they’re not measured and rewarded for getting the right things done. And it’s not their competency to make that call. And on the marketing side, in a good company, we’ve got a product focus one. And so marketing is really focusing on the outbound positioning and segmentation, and nurturing and all the things that are that are core to marketing. In general, the marketing folks are a little lightweight in terms of product knowledge and internals. When we have marketing folks spec out products, we have really good UX, but nothing under the hood, soy, soy products sort of halfway between. But in every organization, we draw the line in a different place. There’s no perfect, and it’s so much about how the different execs are going to divide up the world where they are the work in a way that everybody can get along and the fistfights in the alleys or the the aisles of the office are minimized. One last thought and then I’ll close.

PM Roles and Responsibilities.

We’ve got a few more questions. Emily. Emily, could you just say something.

I don’t reload because people get distracted but yeah, there we go. That’s my background everybody. Self esteem boost for the day.

For Emily, there’s a couple of questions and then quite a few You’re different people asking about early stage companies, Nick mer or Ben Ebong. Do you want to pipe up and talk about pm and roles and responsibilities?

Q: Yeah, hey, guys. Hey, rich, I think you mentioned when you should invest in a PM, essentially around a 12 person team when you get to that stage, but what happens if you’re trying to get to that stage? Who should be tackling those roles and responsibilities? And how do you do that effectively? Maybe you’re a Product Manager and CEO, maybe you’re not.

It’s a real challenge. Yeah. And I’m not I’m seeing more true startups two, and three and five person startups where one of those folks is, in fact, at heart, a product manager. And I think that gets us along the discovery or validation track really fast, I just don’t see most companies being able to afford it. Right. So and that person’s even, even if they’re 100% product originally, they’re probably doing three other jobs, right? At a startup, we’re all doing a bunch of jobs.

So what I’d say is, I think it’s really, really important or useful for a startup to have somebody who’s got product management experience. But I’m not sure at a four person company that we’re going to have anybody whose sole job and name tag says Product Management because there’s, there’s not enough division of labor in a company that size.

I was just gonna pick something up because Kevin Davis had a good comment here, full disclosure had been fired more than once in this failure mode. I’ve got to tell you, I’ve been fired more than once in this failure mode, too. So only, you know, a handful of times, but it was very instructive and good to deflate my ego from where I thought it was. Okay, I’m sorry, Mark, you were going to take us somewhere else?

Where Does Product Marketing Fit?

Yeah, I was just gonna ask John Saltz, if he wants to talk about where product marketing should fit.

Yes. You mentioned the marketing sort of spectrum between marketing and product management. I’m wondering product marketing. Yeah, big enough where you need product marketing, which we’re big enough, right? Yeah. It’s more of knowing the products and then doing the marketing function. What do you think about that?

I think, it’s a hard call, right. So when there’s enough product marketers, or enough product marketing to have a department, right, the two choices one is to have it report to marketing. And often the product marketers feel a little unloved and left out, because they’re doing something, you know, somewhat more intellectual is maybe a strong word, but it’s more content driven, it’s more subjective. It’s very closely tied to sales. And often the product marketers feel unloved by the demand gen side of the house. But it’s one of the two choices. And at least, we know that when we bring out a new product, they’ll be some campaigns behind it, because they’re in the same organization. And the messaging will be good when we move it under the head of product, because sometimes I see product marketing as part of the product team next to product management.

What we’ve done is on the positive side, we’re getting a lot better communications between the product marketers and the product managers were much more likely to describe the products correctly, to know who they’re for to have that stuff. But often what we’ve lost is the really tight connection to the rest of marketing. So there’s this pendulum effect. Sometimes I see where we have product marketing on the marketing side for 15 months, and then we decide it would be better on the product side for 15 months, and then we think it would be better on the marketing side for 15 months. And those folks get a little whiplash. But, you know, I think all product folks figure out that we have to fill the gap that the organization creates. So no matter how we divide people up, there are natural gaps. And as the product folks, we have to see those we have to reach across we have to be triply quadruple ly pushy about communicating and loving the folks across the gap because everybody is across the aisle from us. And, you know, we’re always papering over whatever division we created. To non answer, but it’s my answer.

Experience Knowledge.

Right, Patrick Quinn, who traditionally if he doesn’t ask a number of questions at any BoS Conference. Isn’t really at the conference. Patrick, you’ve got a question about experience knowledge.

And and it looks like that’s about Scrum and Agile. So I’ll pick up Patrick’s question. So I think it’s essential. I think it’s required that product managers really understand how their software is built. I think there’s no excuse for that. And so we have to be agile practitioners, right? We and but in the broad sense, not in honest again, I don’t care if you’re Kanban or Scrum or halfway in between your XP, you’re right. I’ve been at this game so long that I know that those are all right solutions for some situations, I don’t think the product folks get to be dogmatic about how the software is built. It’s not their call. But we have to know where we fit in. And probably three places where it’s really important one is, we have to get our problem statements or whatever they are in the right format. So our engineers and developers are actually going to engage with them. Notice, I didn’t say solutions, I said problems, right.

The second is, I think we need to be in every retrospective, because so many of the issues that come up on our development teams are out of scope for the developers themselves, right? They can’t fix organizational problems, they can’t fix lack of focus on the sales side. They can’t fix weird, you know, things that marketing’s doing, and and so my product managers and I show up to the retrospectives. So we take assignments out of that to go fix things, or lobby folks who are outside the development team that are blocking things for development, right.

And then the third one is, we as product folks are the semi permeable shields were the blockers to everybody who wants to interrupt the current sprint, I was just working with somebody yesterday. And we defined the conditions under which somebody else in the company can break the sprint, and it is the list of one and it is p zero system down. Customers can’t use our software, right? If our cloud is offline, if our users can’t log in or enter data, we all stop what we’re doing, and we get it fixed. But anything other than that product managers have to throw their bodies in the way of all the other interrupts there’s nothing so important that we can’t wait a half a week until the next sprint starts. And so we have to live the Agile story, we have to be part of the Agile story. But I don’t actually care about the details that happen, you know that the inside baseball inside the sprint, other than that the team’s working and I can help them. So there’s an outer loop, agile here, as opposed to the inner loop agile of single story single points. Right? How do we support agile as an organization’s organization? Awesome. Thank you. Cool.

Pragmatic Marketing Framework.

All right. Ben McDonald. So what are your thoughts on pragmatic marketing framework? But let’s extend that I mean, the almost infinite number of frameworks.

Yeah. And for everything, I guess, and I know, the pragmatic folks are really smart, and they’re helping educate up the product, folks, here’s my observation. There are, I don’t know, maybe no more than a dozen or two different frameworks for product management, they are all morally the same. You know, you need to have your own framework, if you’re going to put it on your logo and promote it and sell books and put people through your class. But I’ve never actually found anybody who directly implements any of them as written. So first of all, they’re just boxes on a page with some templates. Going to a class for two days does not teach you how to be a product manager.

My good friend Scott Sal Horst out of Austin taught me that a weekend at the dude ranch doesn’t make you a cowboy. Right. And so it’s true mark, sorry. So I know that I want to send my folks off maybe to a class or two, because we’re gonna get a common vocabulary, and we’re gonna maybe have some common templates, you know, get on the same tools. But none of that is the essence of product management, the essence of product management is embroiling yourself in lots of customer issues, and really, really, really deeply understanding and empathizing with what they need. And then bringing that stuff back to your development team, where the much smarter folks are going to help you figure out how to solve it. And the workflows are useful. But every time we come to a new company, we blow up those workflows and start some new ones.

So I wouldn’t confuse the grid or the matrix or the flow through diagram. With the essential content. It’s the same problem as I don’t know if you guys know this, but writing a book is just a matter of putting 100,000 words in a file. Now, writing a good book is putting the correct 100,000 words in the file. And it’s easy to get confused between I showed up I was in a meeting, I wrote a user story and anything of value. So, you know, let’s just be cautious about how much you can learn in two days of a survey course, rather than two years of living with your mistakes by staying on the same product long enough that they all come back to bite you.

Amazing. One last question. If someone’s got something rich, you rattle through these so quickly. Alright. I rattled. Let’s don’t apologize.

Alright, so I have, I have one last thought here, which, for those of you who thought this was going to be something you wanted to emulate, right? Whenever anybody comes up to me and says they think they might want to become a product manager, or even worse, a product leader, I think it’s my obligation spend the next 10 or 15 minutes, arguing the other side. It’s a, it’s a fascinating, wonderful, narrow position. Most folks don’t want it most folks don’t succeed at it. It’s not that much fun. I observed that really smart folks do product management for a few years, and then something more rewarding. And that’s only useful if I can tell you I wasn’t so smart because I’ve been in product management for 30 plus years. So II OMEOJ Whatever. Oh, nobody’s old enough. And anybody tell me what the last punch card in the stack says. And that’s only useful because each time I’ve been fired, the three letters I write on my whiteboard on my way out R E. O. J. I put an away message you said 404. Vice President not found Nice. Okay. Great. Thanks for everybody’s attention. And for Mark and the team for letting me come play.


Rich Mironov

Smokejumper

Rich is a seasoned executive and serial entrepreneur – he has been the ‘product guy’ (as CEO/VP Product) at six startups. With deep technical roots in B2B infrastructure, SaaS and consumer online, Rich combines ‘what-we-can-build’ with ‘what-markets-want’.

He has been relentlessly blogging, speaking, teaching and mentoring on software strategy, product management for two decades. Today he coaches executives, product management teams and agile organizations. He has spoken at BoS Conference before, always to rave reviews, on topics such as the Four Laws of Software Economics, Solving Your Real Roadmapping Questions and, The Art of Software Pricing Demystified.

Rich has three big things he cares a lot about:

  • Organizing the product organization.
  • Cross-functional leadership.
  • Building what users actually need.

He wrote The Art of Product Management and is a voice for the scrappy entrepreneur in all of us.


Next Events

Want more of these insightful talks?

At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.

Sign up for a weekly dose of latest actionable and useful content.


Unsubscribe any time. We will never sell your email address. It is yours.