Ask any product manager how they got into the role, and they are likely to share some story about how it “happened by accident” or “they had some other job and they fell into product management.” Some even say “I didn’t know what a product manager did.” And the current President of the Boston Product Management Association, Bruce McCarthy, is no different. Unfortunately, the number one criteria for hiring managers looking to hire into this role is often that you’ve done it before – you have prior product management experience. Bruce and I talked about this Catch 22 and how it contributes to the current labor shortage in product management.
What has also contributed to the shortage is the spread of technology from just tech-focused business to virtually all businesses. As these businesses have started investing in technology – in “digital transformation” – they’ve realized that hiring a bunch of engineers and “throwing them at the problem” is not the recipe for success, at least not by itself. They’ve spent millions of dollars and several years investing in technology with not a lot to show for it in terms of business results. These companies have recently been casting around, wondering exactly who it is that is supposed to be driving the strategy for these digital transformation initiatives. Recently they’ve woken up to the fact that the job of the product manager is to figure out the strategy, pull together a plan, get everybody on board, and provide some context and some direction for that technology-driven effort. This realization has lead to a significant product management labor shortage.
Bruce and I also talked about the biggest challenge for product managers – product roadmaps. Roadmaps done right can be a powerful way to get everyone on board with your product strategy and focused on delivering value to customers and the organization. Done wrong they can lead to broken promises and unhappy stakeholders.
Another significant challenge related to roadmapping is prioritization. In fact, it’s consistently the number one challenge facing product managers. We recently wrote a handy prioritization guidebook that you can download for free!
This book might be the most practical and helpful book you read all year.
- The frequent confusion between product management and project management
- Why he co-wrote the book Product Roadmaps: Relaunched
- Where product roadmaps go bad, and how to fix them
- His biggest product management mistake
- What the Boston Product Management Association is doing in the local product management community
Listen to the show:
- Download the MP3
- Subscribe through RSS
- Subscribe on iTunes
- Subscribe on SoundCloud
- Subscribe by E-mail
- Connect with Bruce on LinkedIn
- Follow Bruce on Twitter
- Follow BPMA on Twitter
- Learn more about Product Culture
- Get involved with the Boston Product Management Association
- Product Manager vs. Project Manager
- This Is Why I Never Hire Product Managers by David Cancel
Heath: Let’s start off usually as I always do with talking a little bit about your background. So how did you get into product management?
Bruce: Well, like a lot of people, I kind of fell into it backward. It seems like everybody has a story about how they had some other job and then they found out about product management. Janna Bastow tells a story, she’s the CEO of ProdPad, that her boss, when she was a project manager, said to her, I think you’d make a good product manager. And she said, Well, that sounds interesting. What’s that.
And it was sort of similar for me. I’d been in marketing, I’d been in sales. I did a startup in home environmental inspections of all things. And I had to do all of the entrepreneurial things; I did everything from developing software for the inspectors to doing the business plan, raising money, the marketing. You name it, I did it. And then when that startup crashed and burned, I was looking for a job. And a small software company in Waltham was looking for a product manager, somebody with a marketing background. And I misinterpreted it actually as them wanting a marketing person, because I didn’t really know what was a product manager any differently than that.
But I interviewed with them, and they liked me and I liked them, and they hired me. And I quickly found out that it was the most fun job you can have. At least for somebody like me who likes to dabble in a little bit of everything and be involved in all the different functions of the company, and do that integrating/synthesizing job of pulling it all together into a single plan.
So, it was sort of an accident. I didn’t even know what it was when I got myself into it. I got really lucky, the guy who hired me, John Wang, went on to become the CMO of HTC, was a genius in product management, self-taught. And he taught me all the essentials about cross-functional teams, about starting with why we’re doing this, and about the nuts and bolts of the job.
Heath: My worlds are colliding. So just last week, I was sitting at this table, interviewing Janna for a podcast as well.
Bruce: Oh really?
Heath: She of course was not at the table, she being overseas, but I was doing it via Skype. And so I asked her, of course, this same question. So I was chuckling-
Bruce: Did she tell that story?
Heath: Basically, essentially. She was offered the idea of doing, becoming, being product manager, and her response was, Sounds great. What’s that? And then I recounted the story that I often recount is that I had a similar entry into product management in that … and actually an entry into product management and product marketing. I created or was the first person to hold those roles in two different companies. Neither role existed, there was a need for it, and either I or my bosses at the time said, Hey, would you consider doing this? And the reason was because I had just shown an inclination or an interest in some of the activities that they themselves thought were part of a product manager or product marketer’s job. And so I thought, Sure, why not?
So it’s always interesting to me, I actually have a note to write a blog post about this because I’m curious to know … I ask it all the time, How did you get started? And the responses are almost always the same. It’s not to say they all come from the same backgrounds, but it’s always, Oh, I fell into it, or, I got into it by accident, or, I didn’t start in it. Of course, no one starts in it. And often-
Bruce: Well, that’s the thing, it’s not an entry level job. It requires sort of a general understanding of how the business works, and so there’s huge advantage in having done at least one, maybe several, other roles before getting into product management. And it just requires a certain amount of maturity and leadership in order to be able to be effective in the job. The big challenge of course, is that the number one criterion for hiring managers for any product management job is that you’ve done it before, that they see product manager somewhere on your resume, which of course is a catch 22. Now that’s true for any job; it’s hard to get a job until you’ve done it, and it’s hard to do it without having had the job. But it’s triply hard in product management.
Heath: I think the … if I’ll give them credit for calling them this, some of the more forward-thinking local, at least, tech companies have seemed to have backed off on that, and in fact … so, if you listen to David [inaudible 00:04:45], for example, he has a somewhat famous … I joke with him calling it click-baity blog title, Why I don’t hire product managers. And what he means is, if you read it, is it’s not that I don’t hire them, of course we have them, but I don’t go seeking for those with the experience. Quite the opposite; I like those who have not been product managers. Because he feels like, if I recall correctly, he feels like those with deep product management experience have lost some of that curiosity and digging and talking to the user perhaps than … I may be misremembering it, but-
Bruce: I think that’s BS frankly. I think it’s that he-
Heath: I’ll probably delete that, because I think I’m misremembering it.
Bruce: I do know that article, and I had this conversation with him about why he hires people who haven’t had product management experience before. And I think it’s that he just has a very specific way that he wants it done, and he wants them to learn it from him rather than having their own perspective on it. He wants it done a certain way. And I think that’s fine as a CEO or the head of a product organization, that you have a perspective on how it should be done, and you don’t wanna have to get people to unlearn different ways of doing it. There are a lot of ways of doing it. There are a lot of different companies of different sizes in different industries, and they have product managers who are doing it different ways. And that’s probably the right thing. David’s particular situation is not gonna be universal. And just because someone has done product management before, doesn’t mean that their experience is actually super applicable to your situation.
Heath: Right. In fairness, he also says he doesn’t believe in product roadmaps, and yet he clearly does. What he’s saying or writing is the traditional way that has not worked is not what he believes in. He believes very much in, if I may speak for him, in this newer, if you will, style of product management, the now, next, later, making sure it’s not a two-year horizon, which is ridiculous, and making sure it is hyper-connected to your users and your customers.
Bruce: And also making sure that it’s not about deliverables and dates, but it’s about problems to be solved, it’s about broad themes.
Heath: It’s not feature, function overload. It’s not date-driven. It’s not release-plan.
Bruce: Right. I knew he was gonna take that point of view, and so he was one of the first interviews that I did for the product roadmapping book. And it didn’t disappoint. I got some terrific quotes that we used in the book.
Heath: Yeah, I’ve seen some of his quotes about it. He’s smart in his marketing by saying and writing these things. And you see the title, and you go, What? You don’t hire product managers? Well, no, that’s not really what he meant.
Bruce: There’s another related phenomenon though, that I think things are changing in the product management world. When you and I started in product management, or when Janna started for that matter, it wasn’t that well known a discipline. Most people didn’t know about it, or thought-
Heath: Except maybe Microsoft or something.
Bruce: Yeah. Or maybe they thought they misheard project manager. I’ve actually introduced myself as a product manager and had people say back to me, Oh, what’s it like being a project manager?
Heath: I don’t know, ask one.
Bruce: It’s different. I even ended up writing a short piece, like a 10-page report, on the difference between product management and project management for O’Reilly, for their online Safari subscription service, because they’re so frequently confused. But what’s different now is that as technology has spread from tech-focused business to virtually all businesses, and as businesses have started investing in technology, either they need a presence on the web, or they need an E-commerce capability, or they need a mobile app, or they need some sort of technology enablement for their even very traditional business, they’ve realized that hiring a bunch of engineers and sort of throwing them at building some stuff is not the recipe for success, at least not by itself. They’ve spent, many of these big companies, millions of dollars and several years investing in technology with not a lot to show for it in terms of business results. And so I think in the last few years, people have been casting around, saying, Who is it that was supposed to be driving the strategy for our use of technology? This digital transformation thing, who’s in charge? And recently they’ve woken up to the fact that the job of the product manager is to figure out the strategy, pull together a plan, get everybody on board, and provide some context and some direction for that technology-driven effort.
So, companies all over the map have started opening positions for product managers. And there’s essentially a labor shortage in product management right now. At the same time … well, for example, I looked on LinkedIn about a month ago. I did a search for how many people in the US have the word product in their title. And it came out to just over a half a million people. And then I looked for, on LinkedIn, how many open positions are there with the word product in the title. And there were over a million. So there are about twice as many open jobs in product management, if you just look at LinkedIn, as there are people in product management right now. That’s a significant labor shortage.
And at the same time, it seems like a lot of employees or potential employees have woken up to the fact that product management is a fun and interesting and promising and cool career to have. But they have the catch-22 problem. I talked to the folks at Babson, in their MBA program, and they … Traditionally Babson’s MBA program is focused on entrepreneurs. And if you go back two, three years and you talk to the students and ask them what do they wanna be, they would all say, I wanna start my own thing, or, I wanna be a management consultant. Now, according to the folks at Babson, just about all of them wanna be product managers. And that’s a chasm between supply and demand that’s difficult to cross without the requisite experience.
Heath: I’m starting to see … I used to say on these podcasts and in conversations that there was no … you ask 10 people what a product manager does, you get 10 different responses. Still largely true, I think. But part of that was because there was no formal product management training or course. Well now I’ve stopped that latter statement because Julia Austin, also speaking at UX Fest, professor at Harvard Business School, teaches product management 101 and 102. And so we’re starting to see in the business schools this formal introduction to what is the role, what are the skills required, developing those skills very pragmatically. Because it’s interesting, back to when we started this discussion about how people get started in product management and how often the first few sentences of a job req are product management experience, it felt like to me it used to be that business analyst was almost the junior … was the first thing you did on your way to becoming a junior product manager then a product manager then a senior product manager. I haven’t seen the business analyst role as much any more.
Bruce: There’s two reasons for that. One is that a lot of business analysts have simply been recast as product owners. It’s the same or very similar kind of job in an agile context. And so many businesses have moved to agile development. And so they’ve just taken those people and they’ve given them new titles. And that’s good and it’s bad. It’s good in that they’re acknowledging the role is different. But in practice, they’re not often giving them more than a one-time training in scrum process, and hoping that it gets some, that it gets better. But the second reason, I think, that you’re seeing that less often now is that there are a number of gateway, if you will, or vector jobs on the way into product management. And business analysis is just one of them. And in my mind it’s not actually the best one. A business analyst should be good at getting down detailed requirements. But much of the training in the past for business analysts has been kind of straightforwardly asking the customer, What do you want? Or, Tell me about the tasks that you do today. And the job of a product manager is to get behind that and find out what the underlying problem is that really needs to be solved. Instead of asking, What do you want? or, What do you do? a good product manager will ask, Why do you want that?
Heath: Why do you do that?
Bruce: And, Why do you want that?
Heath: Otherwise they end up just trying to build a better way to do that.
Bruce: Right. It’s the old Henry Ford faster horse comment, right? And that’s okay, but it’s not really transformative, it’s not disruptive, it doesn’t take advantage of the real promise of technology.
Heath: Yeah. You mentioned the LinkedIn analysis. It would be interesting, if not ice cream headache inducing, to break that down a level further. I found that as I got into … I spent the majority of my product management and product marketing career in healthcare and operations in healthcare technology companies, and with a couple sidesteps into pharma and biotech. And product manager in the pharma space is very different than product manager in the tech space. It’s more the owner of the product … give me a popular drug name, I’m blanking. Viagra. It’s really the general manager or the owner of the product, the pull, the drug, which is very different than the owner of the product technology, at least in terms of their responsibilities, as I began to understood.
Bruce: It’s more of a marketing job, because the product is established.
Heath: Yeah. It’s more marketing and sales, and there’s a heavy dose, as you would imagine, no pun intended, of regulatory and research. Anyway, sidestep.
Bruce: It’s also very interesting the way titles are different in other industries. I met a guy whose job had always been strategic marketing. And I was like, Oh, okay, what’s that? And he started telling me about it, and he said, Well, you need to understand the customer and their problems, and you need to figure out what product would effectively solve those problems in a differentiated way in which we can make money. And as I’m listening, I’m like, Well, this guy sounds like a product manager to me. And it turned out that he was in the manufacturing industry. And strategic marketing in manufacturing is really what we would call the same thing as tech product management. And so I started telling him about my job, and he said, It sounds to me like we do the same job. So it’s just a matter of terminology.
Heath: Who’s got the better title. Right. What’s the hardest part of product management?
Bruce: Well, it comes out of what we’ve been talking about. Because it’s different everywhere, the hardest part is figuring out where to focus. There’s so many things that as a product manager are probably on your list of things that you should do, and it’s not really possible to do all of those things. So picking and choosing, prioritizing, is one of the hardest things that product managers do. And honestly, most of us don’t do it that well. We could do it better and we have to do it better. I always say that the quickest way to do effective prioritization is to connect the strategic with the tactical. There’s a thousand tactical things that you should be doing. Which ones are the most highly leveraged depends on your strategy.
Should you be listening to your customers? Well, sounds good, motherhood and apple pie, right? Well, it depends actually on whether your strategy is to continue to target the current customer base or to pivot to move upmarket or downmarket or to some other market, in which case, listening to your customers is actually a distraction. Or if you’re planning on inventing something entirely new, then listening to all the complaints about your existing product, not helpful. So, not that I wanna be heretical about not listening to your customers, but what things you prioritize and what tactical activities you engage in on your endless list really needs to be focused by your strategy. So, if somebody says, What’s the hardest thing? you can poll 10 product managers and they’ll probably say prioritization. But I will say that the problem underlying that is connecting strategy and execution.
Heath: And we actually did just that, albeit unscientific. In other words, we did it on Twitter in a Google form. But we did poll our community, and it was pretty cut and dry that prioritization was … I mean, by a long shot it was the biggest thing, the most vexing challenge for them. And that also nicely dovetailed with them on the products annual survey as being … It wasn’t as clearcut, but it was still clearly the biggest challenge.
Bruce: And I did … I put out a UserVoice forum five years ago now, and asked the same question. I gave the 10 … I seeded it with 10 problems of product managers from my own experience, and I wanted to know how do other people prioritize those things. So I just asked. UserVoice has this voting capability, so I just asked, Vote for your favorite problem, and then tell me in the comments your thoughts about your flavor of that problem. And prioritization came up to the top. So things have not changed in that way.
Heath: So very related to prioritization, you can’t execute what I’m about to say without then prioritizing it, but roadmapping. So you co-wrote a book, Product Roadmaps Relaunched. Why did you write the book, and how did you decide on that as your topic?
Bruce: Well, it really came out of partly that same research. Number two on the list after prioritization was roadmapping. And I, back then when I did that survey, started writing and talking about both topics. And I started developing a product called REX for Roadmapping, and it included a prioritization capability. Now, I think that I might have been a little ahead of the market with that product, and also, in the end, I’m not sure people really were looking for a roadmapping product per se, because everybody’s process is a little different, and because a lot of people are really looking for more of a workflow Jura like thing, I think, for product management. But it seemed like there was still a huge problem in the area of people not really having good framework for roadmapping or prioritization.
So, I started talking about it, I started presenting at Product Camp actually, about prioritization and then about roadmapping and then about product vision and all of this cluster of things around what are we doing and why are we doing it. And every year at Product Camp, the audience for those topics got bigger and bigger. So, I said, All right, we need to do something about this. It had been on my backlog of things I really should do for a couple of years. When it was C. Todd actually after Product Camp at the bar who twisted my arm and said, You know, we really oughta write a book about this. And he said, If anybody’s gonna write a book about this, it needs to be you, Bruce, because you’ve been talking about this stuff for so long. So we did. So we talked to O’Reilly, and they didn’t blink. They said, Yes, we are hearing about this left and right and center as well. If you can write a book about this, we will publish it.
Heath: It’s interesting you mentioned the software perhaps being ahead of your time, and maybe even that it wasn’t the biggest … no one was screaming, I need software to solve my product roadmapping ills, it’s more about framework and process, right?
Heath: If you focus on the software, I found when I struggled most it was when I was spending too much time on the physical presentation of the roadmap, right?
Heath: And then you look up weeks and weeks later, countless hours later, and you’ve been with project, right?
Heath: And it’s like no, no, a Gantt chart is not what we need for the roadmaps. Quite the opposite. What we need is a framework and a process that makes sense to everyone in the organization and can help get us to the real endpoint of connecting the strategy to the tactical.
Bruce: And that was the other thing, was there are so many bad roadmaps out there. You do a Google image search for roadmap, and you don’t get what we would call in that book a roadmap. You get-
Heath: You get spreadsheets.
Bruce: You get spreadsheets, you get-
Heath: Gantt charts.
Bruce: Project plans, Gantt charts, flowcharts. You get features and dates, that’s what you get. And you get work plans essentially. And what we tried to communicate in the book is that that is a old-fashioned manufacturing oriented-
Bruce: Waterfall, 20th century concept. It’s about resource optimization; it’s not about achieving objectives. It’s not about solving problems. And more and more, business is about solving problems, not about efficiency and resource utilization. It’s not about can we go from a 0.2% margin to a 0.3% margin. It’s about how do we change the game and be really innovative and stay ahead of the competition so we can have 80% margin.
Heath: And I think one of the many things that leads that style of roadmap presentation is measuring the success of the product team based on how many features and functions they released and not based on whether or not anyone even cares that you realized that.
Heath: You end up with … and this is partly a commentary on Waterfall too, I suppose, but you end up releasing something, and then it’s the old adage if a tree falls and no one’s there to hear it, did it make a sound? If you release something, and none of your users care, should you take credit for that? Is is worthwhile? Did it move the needle for you? And there’s something that, not to overstate, but beautiful in the simplicity of the now, next, later. It just makes so much sense when you look at it, whether you’re in engineering or in sales, or you’re the market. I can see that presentation and understand, okay, they’re focusing on this today, they’ll get to this coming up next, and there’s a bunch of stuff that they’re thinking about, but if I’m a smart user, and I see someone tell me what they’re building with a date on it that’s more than six, eight months out, I’m probably saying, Well they don’t understand what they’re doing. I don’t know if I want that yet. And then some of what you build now and next may change whether or not I feel good about that later stuff.
Bruce: Absolutely. Now, I love the now, next, later format as well, and I use it as sort of my starting place when I’m doing a roadmap. There are situations where some more specificity about dates makes sense. If you’ve got a lot of cross-functional dependencies, then having an idea about whether something is coming in the next six days or the next six months is useful.
Bruce: Knowing whether something is this year or next year is useful. I still say keep it essentially as high level, keep the dates as broad and open as you can get away with given the constraints of your business. And I don’t mean given the constraints of the personality of your boss. But I do mean the real constraints of coordination across business units or with your partners. You know, if you’re selling through retail, well your distributor or Best Buy probably needs to know whether your new receiver is gonna be available for this holiday season or next holiday season.
Heath: If you make a product that somehow benefits the health insurance industry, you need to know when open enrollment occurs so that you can hit that date.
Bruce: Right. And there are some hard-
Heath: Otherwise you might as well wait another 12 months.
Bruce: There are some hard dates that really matter, like regulatory requirements, or in the education industry. If you are planning on rolling out changes, well you’re not rolling them out in September, you’re just not. But that aside, the more you can open up the roadmap to the, Here’s who we’re serving, here’s why we’re in business, here are the problems we thing are important to solve in this space, and the less you focus on features and dates, the less you focus on essentially what looks like a work plan, and the more you focus on a statement of intent and direction in delivering value to your customer, the more engaged you find that people looking at your roadmap are. Instead of it being a dry recitation like you’re reading off a spreadsheet, it’s like, No, we are gonna make your life, your situation, your business better. That’s a far more interesting conversation.
Heath: Agreed. So, where do roadmaps go bad? That sounds like a TV show, When Roadmaps Go Bad. Where do product managers get it wrong? Where does it fall down?
Bruce: Well, right where we were talking about. It falls down with they get bogged down in the details. And it’s not just about the dates. It’s also about the deliverables. So, you were saying earlier, if a feature falls in the forest does it make any money? And the answer is-
Bruce: No. No, it doesn’t. And there are some pretty scary statistics out there about the number of features that are never used, like something on the order of 80% of features never get used. My favorite story about that is that 80% … at a certain point, somewhere around probably version six or seven, 80% of the requests for new features in Microsoft Office were features they already had.
Heath: People just didn’t know about it.
Bruce: Exactly. So, it’s really easy to get this stuff wrong. It’s really easy to think that you have thought through everything about what’s really needed in a feature. Either whether the feature’s needed at all, or how to design it appropriately, or who it’s for and what situation they’re going to need it in. It’s really easy to be confident and wrong. And so confidently putting out a list of the features that you plan to ship, in your mind internally the vision of what value that adds to your customer and your business is very clear. But to the average customer or executive or investor, it’s not. I guarantee it’s really not that clear. So, you really need to paint a picture of why we’re doing this, who we’re doing this for to kind of reality test all those features even conceptually when you’re writing them down. But even more so, you’re probably going to learn along the way which features really matter, and which features really do solve the problems that customers have well. So I would much rather build the roadmap around that, around problems rather than solutions.
I was at a conference in Lisbon a number of years ago where I delivered a roadmap presentation for the company I worked for, ATG at the time, and I did it in that problem solving themes kind of way. And I didn’t list features that we were gonna ship on any particular date. And nonetheless, I started getting a lot of questions about, Well, are you gonna have this feature? Are you gonna have that feature? And one particular ISV who served one of the largest grocery chains in Spain, came up to me and said in a very challenging, almost bullfighter-like kind of way, Well, are you gonna have this particular feature? And are you gonna have it in this release? And I said, Well, it’s one of the things we’re looking at as a solution to this problem. I know that your customer has this problem, and we’re trying hard to figure out what’s the right answer, the best answer to this problem. And I don’t want to constrain my team’s options about the best way to solve the problem.
And he looked really kind of deflated until I turned it around and said, But I would love to talk with you and your customer about different ways to solve the problem and which ones would work best for you. And once he got the idea that I wasn’t just telling him no, but that I was really working in his and his customer’s interest, and I wanted to involve him in the process, he was all smiles. Constraints are really useful for focus, for prioritization. The classic rookie product manager mistake when you are porting a product to a new platform, or re-platforming a product, rebuilding it, re-architecting it, is to say, Well, we just need all the same functions we had before, right? And no, that’s probably wrong because a bunch of the features are not actually used very much. And if you can actually dig down to, well, let’s think again about who our customer is and what problem we’re really solving for them, and think about it from scratch, you can probably eliminate 80% of the features and deliver 80% of the value that you were before.
Heath: A lot of them you can kill off and no one will ever even know you killed them. And so we saw it happen when products were going from an on premises solution to a SaaS solution, and when they went from SaaS to mobile, it may not be that linear, but each of those steps forced product teams to think about, Do I really need to spend all my energy and resources on feature parity from one platform to another? Or is this an opportunity to say we don’t need all these features to come over?
Bruce: I have a story about that that I learned a lot from. Company I worked for, that same one, that was my first product manager job, got acquired by a big company. And there was essentially a duplicate product that they had that wasn’t as good as what we had developed. It was a web facility for purchasing and downloading mailing lists. So I was given the job of figuring out how to get all of the users over from the legacy product onto our newer, more modern, more capable product. So the first thing I did was of course I interviewed a bunch of the users of the legacy product to make sure that I understood who they were and what their needs were. And I quickly discovered that they were pretty much the same kind of users as we had designed the newer product for in our smaller company. So that was great, so there wasn’t a huge delta in the functionality we needed to add. There were a few things that made sense, but who the customer was and the underlying problems they had were the same.
So we announced at a certain point in time, Hey, we’re sunsetting this old product, and here’s this new product that you can have. We’ve already set you up an account, here it is, and you can start using the new thing. Here’s a tutorial, here’s the phone number of your support person if you need help. All those nice things. Everything was going really, really smoothly, until one of the salespeople started complaining that his number one customer was really unhappy with the new product, really was refusing to move onto the new product, was threatening to leave us if we didn’t keep around the old product. And in talking with the salesperson, I was getting some weird signals about the features that he really valued in the old product. They didn’t make sense to me, they weren’t consistent with what I thought the needs of the customer were. And I was wracking my brains, I was like, What did I get wrong? What did I miss here?
So finally of course I managed to get on the phone with the customer himself and started asking about his business. And I quickly found out that he was an outlier, he was not like all the rest of the customers. He was actually not a marketing person buying mailing lists, he was a broker selling mailing lists to other people, and he needed some advanced features that we hadn’t designed for. Well, actually, the original product wasn’t really designed for him either, it just happened to have a couple of things that he had taken advantage of that worked for him. And he was virtually the only significant customer of that type on the product. So, fortunately, the company had another product just for brokers, which he didn’t know about. So we were able to move him onto that and move things along.
Heath: Yeah. Before you said that, I was gonna say, well, that sounds like a case of where you found out sort of unintentionally that you had someone using your product that you could argue that they’re not our target market, right?
Heath: It’s a use case, it’s fine, they’ve been doing it. But that’s not our strategy, it’s not our market. So if we lose him, it’s unfortunate, but we can’t support that.
Bruce: Right. And fortunately we didn’t have to lose him as a company. We did lose him in terms of that product, but that’s okay. We made the customer happy, and we saved the relationship.
Heath: What’s the biggest product management mistake that you’ve made, or if you don’t make any mistakes, that you’ve seen made?
Bruce: Well, I don’t make mistakes.
Heath: Well, that’s fair.
Bruce: Seriously, everybody has to learn by making mistakes. My favorite story about that was going back to my first product management job again, I built a new product that was the second product that the company had ever built. The business had been entirely built on one CD-ROM based product, so that’s dating me a little bit. And we were moving into internet products. And so I created a complimentary product that would work with our CD-ROM product. The CD-ROM product was again it vended mailing lists using a meter, physical dongle. And I built this online letter shop where you could upload your list from the CD-ROM, and we did a partnership with Pitney Bowes for them to print pieces for you to do a mailing. And I thought this is gonna be awesome. And it was the world’s first online letter shop. And the thing that I forgot, even though I had talked to the customers, figured out the problem, figured out the pricing, figured out exactly what the minimum to ship was, we didn’t have the concept of minimum viable product, but it was essentially that back in the day. I had worked everything out from the customer need to the delivery, except the marketing and sales. I had forgotten to talk to our marketing team and our sales team about how were we gonna bring this thing to market.
And we had this really effective machine for selling the CD-ROMs. It was great, we were growing like gangbusters. And when I said to them, And here’s our terrific online letter shop, they were like, Yeah, we’re-
Heath: How do we sell that?
Bruce: We’re not really doing online stuff. We’re not really selling online. And this seems like a distraction to us executing on our plan for selling the CD-ROMs. The price point isn’t high enough for me to care. And I learned a hard, hard lesson that day about first of all tying it to strategy, and second of all, doing your … managing your stakeholders, making sure you’ve got the whole plan from development to delivery to sales and marketing all figured out, and you’ve got the organization behind you.
Heath: So, tell me a little bit about your involvement in the Boston Product Management Association.
Bruce: Sure. I’m the president of BPMA. I have been, this is my third term. And I’ve been involved for five, six years as a volunteer and a board member. But the organization’s been around since 2001, and I’ve been a member ever since then, going to events and so on. BPMA is a community-based organization for product managers and for the companies that are hiring product managers. It’s all volunteer-run. And it’s one of the largest community organizations like this, one of the largest regional organizations like this. There’s a similar one in Silicon Valley for example.
Heath: Is there a national body as well that you’re a member of?
Bruce: Nope. BPMA is its own thing. It’s also one of the longest standing ones. There are a few dotted around the world. We do regular monthly events. We just had one last night at Bentley University. And that one was on the … we had a panel discussion on the working relationship between product and UX. And we hold events all around the Boston area, sometimes downtown, sometimes out in the suburbs, usually at local companies that are interested in hiring product managers and would like to host an event. And we usually have speakers or interactive sessions on things of interest to product people. We have a summer party coming up in July which should be a lot of fun as well.
Bruce: Yeah. And we have an annual career fair. We had it at WeWork South Station a couple of months ago. It’s usually one of our largest events where we invite local companies who are hiring and the local community of people who are interested in product management jobs. And we usually get a couple of hundred people to come to that. We also have a blog called Product Hub where members can write about their experiences and exchange tips and so on. Recently we’ve changed our format a lot to focus on speakers as practitioners rather than consultants or authors coming in and doing 50 slides. We have discussion with somebody who’s doing the same job that all the rest of us are doing and maybe has learned a few things that they could pass along and to have a deeper discussion. And I think that’s working out really well. That’s exactly what people who are in the trenches really need.
Heath: I’ve said this many times before too, and I’m always careful to catch it once I realize that this is the environment that I know, but it feels to me like the product management community offers a lot of opportunities to interact, network, grow to each one another.
Heath: Again, I’m sure there are other roles that would say the same thing probably, but it feels to me like product … and I don’t know if that’s because of the aforementioned lack of formal training and experience or entries into the role.
Heath: But historically it feels like it’s a community that very much is open to grabbing … whether it’s a formal organization like BPMA, or it’s just, Hey, let’s grab coffee and talk about this, because you and I have problems that we’re trying to solve, maybe you can help me solve some of mine and the opposite.
Bruce: I think that’s really true. And I think you’ve hit something there that it is about the fact that there’s very little formal training and that most of us kind of fell into it backwards. And that makes us eager to connect with other people. I also think that the example of BPMA has a program called Product Executives Forum, and it’s a monthly breakfast for VPs of product and CPOs and directors in larger companies. And invariably, while we do talk about best practices, people come away saying, It’s just so good to connect with other people who know what I’m talking about and know what I’m going through. Because product management, even with all of this rise in hiring of product managers, it’s still a bit of a lonely job. You’re usually outnumbered eight or ten to one by your engineers and by your salespeople.
Heath: And by QA and Marketing.
Bruce: Right. And so it’s hard to have somebody else to really talk shop with, but also just talk about the soft side of it, the what’s it like doing the job. So a community is a natural place for that to come together, and BPMA is really trying hard to fill that niche. And we’ve actually expanded into some adjacent niches as well based on demand. A few of the board members from BPMA started a sister group called Boston Women in Product a couple of years ago. I know you’ve interviewed-
Heath: They’ve been on our show.Bruce: Right. And we still cooperate closely under the BPMA umbrella. And if you go to Bostonproducts.org, you can see BPMA events, BWP events, and we have another program called Agile Product Open, which is an ongoing program about the intersection of agile process and practice with product management.