Bruce McCarthy: Is My Product Team Any Good?

Could we be going faster? Could we be winning more? Making customers happier? Not instantly, but how do we know if we have the right team to make these things happen over time? And how do we set them up for that kind of success?

It’s not the tech, the tools, the frameworks, the practices, or the KPIs that make the difference. It’s all down to the habits of mind, ways of working, and shared assumptions of the team.

Bruce McCarthy, Founder of Product Culture, walks you through how he’s learned to assess and diagnose what ails your product team. No surprise, he uses product discovery techniques, observing behaviours in order to understand what your team values. Bruce shares key diagnostic questions he asks, the right answers and the wrong ones, and shares a few stories in confidence.

Slides

Transcript

Bruce McCarthy
Hi, everybody. Everybody doing okay this morning? All right, good.

I’m going to talk about myself first if that’s okay. Then we’ll talk about product teams, because we’re going to talk about judging whether your product teams are any good. And I thought, for those of you who don’t know me, I should tell you: why would I be a reasonable judge? Why should you trust my feeling about this? Welkl, I’ve been part of, or deeply inside of lots of them. Lots of product teams, big companies, small companies, startups, later stage. I worked for one company that was 200 years old. I’ve also played just about every role you can point a stick at. I’ve written code, I’ve done designs, I’ve been in charge of agile enablement. I’ve been in charge of partnerships, marketing, sales, you name it. I’ve run organisations, I was the president of the Boston Product Management Association for three years. I’ve been an individual contributor, and I’ve been an executive.

If I have a superpower, having observed a lot of cases where things come together properly or don’t, I’ve developed a kind of a sense for whether a team is going to be able to function as a team or not. So that’s the basis of my expertise, if you will. I also wrote a book on product roadmapping, a few years ago, with O’Reilly, and the book might sound like it’s sort of a hard skill, a technical skill, you know, like: ‘this is how you assemble the roadmap. These are the pieces, this is how they come together.’ And there is that in the book. But it’s really more about the team sport of coming together to produce something, the collaborative effort that is required. The roadmap is just sort of documentation of the end of that process.

And today, I’m a consultant, I’m an advisor, I’m a trainer, I work with loads of companies of all different sizes and shapes, all around the world on getting better at this stuff, getting better at product. One of the things that I work with teams on these days also is: hiring. I’m not a recruiter, but I’ve got some sense for what makes for a good add to your team. And I focus mostly on scaleups, companies that have reached some level of product market fit, have maybe raised some money, have a reasonably good sized team (100 or more people) and are looking to really grow.

I’m going to walk through several examples of companies that I have had a chance to understand better and what wasn’t working for them. And I’m going to tell the story of one particular company. So I got called up by the CEO of one particular company, who was exactly in this position; they had a product in the market, they were selling it, customers were happy. They had 150 people, they had raised a series B. And like a lot of companies at that phase, what they had done was they had hired a lot. They hired a bunch more engineers, they hired a VP of product from a big Silicon Valley company, they hired half a dozen product owners to work for this person. Everything looked kind of good on the surface. But they were having a retention problem with customers. And growth was slowing. And things seemed to be coming apart from the CEOs point of view. And they were worried about their burn rate and their runway, and he was worried about money and he was ready to fire the fancy Silicon Valley VP of product because he couldn’t figure out what the person was doing. Because from his point of view, as CEO, nothing was getting better, it was getting worse. Having hired all of these people, the only net effect seemed to be the cost to run the company was now larger. So he asked me if could I take a look at the situation. And I’ll tell you the things that I discovered.

Before I get into that, though, I want to talk about what I think successful product teams need. I think they need three things: I think they need good leadership, I think they need some structure. And not just any structure, but a deliberately designed structure, and I’m going to give you some ideas about what I mean by that. And – thinking about what Saielle was just telling us – I think they need a proper product culture within the organisation. Now, I’m not going to talk about lots of numbers, I’ll give you some numbers. Yesterday, we had a session on SAS metrics, which I sat in about CAC to LTV and the rule of 40 and all that stuff. Investors need that, they want that and they’re good at that. That’s not my angle on it. I do work with a lot of VCs who are doing due diligence on companies but my angle on it is: all of those things are lagging indicators of a good product team. And I can’t tell you what those numbers will be like in a year. But I can tell you that they’re more likely to be good if you’ve got the right leadership structure and culture in place.

So let’s talk about them in order, with the leadership piece first. A lot of questions I get are “Okay, so we’vee gotten to this stage, when should we hire a product team? When should we hire a VP of product or a CPO?” It’s right about this time when companies start thinking they need to do it. The founding team has done a good job getting them to this point, do we need professional management? And I think probably hiring some professionals makes some sense. I want to talk sort of about the evolution though of company, as companies go through their maturity in developing product. In my mind that the first step is usually that they expect the product team to focus on development, developing the product. What features are we writing, and delivering? But then they begin to realise that that’s not always enough to satisfy the customers. And so they start thinking about: go to market. And they ask, “Well, can the product team help us to develop the messaging and the pricing, and the packaging and all of the things that are going to be necessary to go successfully to market?” And they can.

But then the next step in evolution is they start asking, “Well, if we have those pieces, is there anybody who’s in charge of strategy? Who’s deciding what segments Should we go after? And how will we win in that segment? And is it a big opportunity? So we’re going to do opportunity analysis, we’re going to do competitor analysis, we’re going to do neat needs gap analysis. And we’re going to do those things. And how do we bring all those together?” Now, hopefully, some bits of this have been done by somebody in the company at this point. And the company at this point is growing. And there’s lots of employees and multiple product teams at this point. So actually, at this point, the missing ingredient is usually some level of direction, some level of “Well, yes, for any given product or any given market segment, we need these three ingredients. But we also need it all to orchestrate together.”

So the job of that first head of product, that professional person is to ensure all three of these things are happening, but to ensure they’re happening in a coordinated aligned fashion. So that all the product teams are going in the same direction. Obviously, you want it up into the right, that’s the proper direction, right? But it needs to be some direction. That alignment process is hard. And it’s cultural. And it’s behavioural. And it’s not just about numbers. So I want the person to be focused more on leadership, on articulating that direction, and on stakeholder management, on understanding the different points of view around the company. And being able to integrate them into a story that we all can tell, that we’re all going to tell, and that we’re all going to contribute to.

So going back to my specific company that I was telling you about, they’d hired this fancy Silicon Valley VP, but he was not part of the executive team, he actually reported to a founder who was on the executive team, and who had two other functions under them. And this person’s experience was terrific at a big Silicon Valley firm, but after they got big, and this company was still pretty small. So this experience was not at the right stage, not at the same stage.

B2B versus B2C is also really important. The skills and practices that are good for one are not directly transferable all the time, the scale is different. How you engage with customers is different. In this case, it was B2B on both sides so it wasn’t a problem. And there seemed to be a bit of a mismatch there in terms of what the VP was focused on.

Usually I do an interview, but I didn’t have to ask him because while I was visiting the company, he did an ‘all hands’ meeting where he described what his team was up to. And I’m like, “Great, tell me what your team is working on.” But here’s a bunch of slides, he’s telling me what the team is working on. Well, it seemed the gist of the slides was, “We closed a lot of Jira tickets.” And that was a red flag for me because it was a measure of productivity or throughput, rather than a measure of customer value, or changing the numbers anywhere in the business, or solving problems, or anything like that. It was all just about, :We run an efficient, engineering shop.” But he wasn’t in charge of engineering. So that was a red flag for me too.

So it’s partly about leadership. I want you to talk about the customer, I want you to talk about what we’re going to solve for the customer, I don’t want you to talk about the internal metrics. And it’s partly about structure also. structure of the team is actually more important than you would think. I’ll throw a few numbers at you right now and then we’ll move on. There’s been a big evolution in the role of Product Management. Over time, it’s become more and more central more and more important as a coordinating leading function. And if you go back 10 years, the average product manager was managing three products. There’s been surveys from organisations in the states like Pragmatik marketing and organisations like the Product Management festival in Europe every year on these kinds of stats. So I’ve been tracking the changes. Now, with the advent of a few different product titles like Product Owner or Product Analyst, it’s usually more like 1:1. If you’ve got a team on a product, it should have its own dedicated product person of some title or other. Product marketing, it used to be that you’d have lots of product managers and maybe one product marketer. And that’s going to 1:1, which gives the product manager a partner in go to market so they can focus more on the strategy. And the ‘What are we building, for who’ sorts of questions.

Then PM and UX, it used to be a very high ratio of not enough designers for the number of product managers or product teams, that’s moving to 1:1 as well, where you can set up your product teams with a few engineers, a product manager and a designer. And that forms a nice cross functional squad. That’s very effective in being able to understand and meet the customer’s needs. And then also the ratio of product managers – or product people – to engineers has shifted over time to give more product managers per engineer so that you can have tightly coordinated teams.

The other thing about this structure is what do those teams own? What are they attached to? Now, at the company that we’ve been talking about? They were attached to functions within the organisation. That is, there was a team that was attached to data collection. There was a team that was attached to the user interface. And there was a team that was attached to the professional services. They had a team of analysts that sometimes used or advise the customers on using the interface with the data that was collected. And so they were organised in that fashion, but the really successful teams – some of whom you may have heard of: eBay, TripAdvisor – organise their teams by customer, or user, or customer need. So eBay is famous for having been around a long time, but also for having separate teams for the buyers and the sellers. They’re separate product teams entirely, not just the product managers, but cross functionally, engineers, designers too because they have different needs. They’re complementary, they got to come together in the marketplace, but they’re separate.

TripAdvisor – a Boston Area company – they have a team for the hotel listings, a team for the rentals, a team for things to do, and a team for restaurants, and so on. Every different area, with a different customer, with different use cases, has their own independent team. And they actually, for the longest time, didn’t even have a chief product officer for those teams to report to. They were totally autonomous from each other.

This ecommerce platform, they were organised by component – like payments or something else. But I just had a conversation a week ago with their new head of product. And his plan is to reorganise the entire product team and all the engineering teams and all of design, to focus on the different user types: consumers who want to buy things, store associates who want to help them buy things, merchandisers in the back office who are populating the catalogue with the prices and the descriptions and so on, and back office operations as well. Because it focuses the effort of the teams on making the customer successful. That’s the model I really like. It usually involves some kind of matrix organisation. You know, you have a head of product, who has these product managers in blue, and you have parallel organisations separate in all these other functions, whatever functions you need – maybe data science would be there in a lot of teams today – but they are organised horizontally into cross functional teams. They take their day to day direction about what they’re working on, who’s the customer and what are we trying to build horizontally rather than vertically.

So those are the kind of structure things that I’m thinking about optimising. As I mentioned, this company that I came in to take a look at was not organised in that way at all. They really had separated things into: things that they could touch and feel and grasp, into departments really: data collection department, software department, services department.

So now I want to talk about those cultural aspects. I think Saielle, you’ll see some familiar themes here. I was really happy that you went right before me and talked about hiring practices, because we are looking for not just skills, and “Oh, I know how to do Agile.” Not just expertise with tools or technology, or the ability to deal with or experience with OKRs or KPIs. Product culture, a good product culture, is not limited to product management. Although that was often my title. As I said, I was often officially or unofficially in charge of engineering, or design, or agile, or partnerships or whatever. Because when it comes down to business – I’m sure a lot of you, business owners and executives in here will agree – it doesn’t really matter what your title is, it matters if we get the job done. It matters if we get the results for the customer and for the business. So I want to say, sure all of this is a given, we have got to have these things. But what culture is and what is more basic to success is shared assumptions about why we’re here and what we’re trying to accomplish. They’re the habits of mind, the shortcuts and the phrases and the stories that we all refer back to. My working definition – I keep changing this every few months – of product culture is that it’s an emergent quality when many functions come together, they share a mission to scalability, make their customers successful, and that in turn makes the company successful. So I want engineering and design and product all coming together to figure it out together. How do we make the customer successful in a way that makes us profitable?

So okay, unlike the ratio numbers, how do we figure out whether the culture is good? You know, I said with this company that I was talking to, on paper, it all looked fine. But how do I discover the cultural health or lack of health? As I go? Well, I asked a lot of questions. My job is to go in and interview, not just the VP of product, but maybe a dozen people all around multiple teams inside and outside of product development, I want to talk to marketing and sales and finance.

And it’s difficult to measure culture, but you can observe behaviours. And these are the behaviours of a good healthy product culture, in my opinion. Number one: we’re focusing on the customer. And we’re focusing on making the customer not just successful, not just satisfied, but awesome. Really feeling – like Kathy Sierra would say – like, they’re badass, because they have your product, and they can do great things. Also, internally, we share a vision of the future where the customer is successful, and our product is out there leading the way and making them successful. And we are successful as an organisation. As a result, we’re on the same mission, we’re on the same boat. And also, I want to see the behaviour that we are empowering, we, as leaders in the company are empowering teams, cross functional teams, to pursue that vision. We’re not telling them what to do, we’re saying, “Here’s the goal, you guys figure it out.”

And then also – this is a little bit producty in particular – I think a lot of these behaviours should be true for anything. But in a company, in a scale up in particular, we’re looking for behaviour that is figuring out what it’s going to take to scale, leveraging ways of scaling, whether it’s automation, or AI, or partnerships, business of build versus buy decisions. I want always to be figuring out how are we going to make this – whatever it is – scale.

So let me give you some examples. What I do is all these interviews, and I’m going to ask a lot of questions, I’m going to ask questions around “Who is the target customer, for example?” And I’m going to compare the answers. I’m going to ask the CEO, and the head of marketing, and somebody from product and somebody from engineering, “Who’s the customer?” Now I did that with this company. And I got like five different answers. One person said, “We serve enterprise customers. That’s our core customer. And it’s a very high touch service oriented.” Okay, great. Another person said, “We serve anybody who will pay us.” You can guess what department they were in. Another person said, “Well, we were serving mostly and exclusively enterprise customers, but we’re trying to move down market. And that’s why we’re building some of the automation features that we’re building.” And I thought, “Oh, that’s a pretty good answer.” But I only got that from one person. And that was disturbing. That was a concern that, broadly speaking, there was no agreement on who we were serving.

After discovering this, I put together a little bit of a workshop on the value proposition and the high level strategic roadmap. And it took us the first two hours of that workshop to agree on the definition of the customer among the executive team. So it wasn’t just that not everybody got the memo, it was that there really was not alignment inside the organisation. I thought that was also a red flag about this VP, because that’s that person’s job, to drive alignment on who’s the customer and how will we win in that space. I also want to know that there’s a regular process of talking to the customers and getting feedback on what’s working and what’s not working for them. And that was missing here as well. The product owners were really busy serving engineering, and just didn’t have time. They said to talk to the customers, and they had a services organisation whose job it was to talk to the customers and who unfortunately did not have a good relationship with product or engineering and didn’t want those people talking to their customers.

So this was also a red flag: the division of the future. So I also like to ask, I’d like to ask really softball questions, seemingly softball questions. So just tell me what you’re working on. What’s the goal right now. And in this case, when I talked to engineering or product, it was all about features, we’re working on this feature, we’re working on shipping this thing we need to get, we need to get it out the door. Now, I think that there was a time in the company’s history where they felt like, features were being shipped too slowly. And so that was understandable. But pressing them and saying, okay, so what will happen when we ship this feature? There wasn’t much of an answer, it was sort of like, we’ll be done, we’ll get to the next one. And that, again, was a red flag. If there’s no common vision of where we’re trying to get, how do we know if this is the right feature? And how do we know if that feature was successful? And how do we know what the next one is? Except that maybe the executive team tells us or we have a list of customer requests, and we’re just going to go down them in the recency or the frequency? of them? I would much rather have you thinking about that common vision and saying, Well, if we’re gonna get there, these are the things we got to accomplish. These are the the hurdles, we have to we have to get over another company that I work with, when I asked what what are the teams that you what are the things that you’re working on, unfortunately, a lot of it was we need to fix Tech debt, we need to improve our reliability, and our scalability, and we need to retire a lot of tech debt. And that was, that was, again, because of a lack of vision that had persisted over many years. And they had just built everything anyone requested. And so the stack was just kind of a mess of half built features. And there was no leadership saying, this is where we’re going to things outside of this can’t wait. And if you can focus on where we’re going, then you can you can not try to build build the ocean, is that sort of the the equivalent of boiling the ocean. And, and not spread yourself too thin. And then there’s this notion of, of empowered teams now. Marty Kagan, big product management guru talks a lot about empowered teams. And I think he would agree focusing the team on a particular customer and a particular customers problems, and giving the team that permission to figure it out for themselves would be good. So I like to just ask, when I’m starting the interview, I pretend I don’t know anything. Usually, I have seen the person’s LinkedIn. And I’ve been told their position in the company and things to look out for, but I pretend I don’t know anything. And I just say, oh, okay, Jane, What team are you on? And I’m just taking notes. And the answer to that question can be very revealing. Sometimes Jane will say I’m on the engineering team, or I’m on the testing team. Sometimes they’ll say, a better answer would be I’m on the, the team that serves this customer. Or that the at least the team that works on this product, which is oriented to a particular customer goes back to that cross functional thing. If I think of myself primarily as part of the engineering team, or as part of the product team, or as part of the UX team, I’m not as focused on the customer and the vision, I’m focused on my job, my particular role, and I don’t mean to say that you shouldn’t want to be good at your job, or that you shouldn’t hang out with the other UX people. I’m saying, at this particular company that we’re talking about, again, the data collection team sat off in one corner, and the product team sat in a different corner. And the services team that was actually talking to the customers were in a completely different part of the building. And they really did not talk to each other. In fact, the while I was there that week, I put together a meeting between the product team and a bunch of leaders in the services team. That was the first time they had gotten together. Ever, as far as I know, to talk about stuff, the services team felt like the product team wasn’t listening to them. They there was a forum where they could regularly submit Feature Ideas and they had no idea what the status of any of those were.

And the analyst team, I gradually learned was the primary user of the software. Most of the customers actually couldn’t make heads or tails of the software. And so the analyst aim was using it on behalf of the customer. So their customers were in the building, and they weren’t talking to them on a regular basis. Eventually, I’ll tell you about how we reorganise things to work a little bit better. And then there’s this business about enablers of scale, what we’re looking for here is that is the software model, you know, build once sell many times. And yet, a lot of SaaS companies in particular are finding that, because SaaS forces you to in order to keep the customer subscribing over time, it forces you to go beyond the code, the actual deliverable of software to whatever it takes to make the customer happy and successful, to make them want to renew. It actually, there are a lot of sass companies out there now whose margins aren’t as good as they could be, whose scalability isn’t as good as it could be. Because they are adding a layer of services on top of the actual software that they have written of various kinds, maybe it’s education, maybe it’s do it for you, maybe it’s advising, but some sort of services to fully deliver the value of the software. And I like to understand what are those places where it’s not a pure build at once so many times, so I’ll ask questions about, do you make customizations for your customer? And when what was the last one that you did? And how did it go? And why did you do it? And are you shipping that feature to everyone? Because it was on your roadmap anyway? Or did just did you just do it to get the deal? In this particular company. There was a interesting phenomenon going on. I’ve talked about the three different functions, data collection, user interface, and analysis. Because those were three different worlds, the product managers kind of thought, well, we just control the user interface part. That’s our job. And we can’t really do anything about the other parts. But they had a business problem, which was margin. Their margin was not great, because they had a large analyst team that served the customers using the software with the data that they collected. And also, the data collection, it turned out was expensive. So I talked to the data collection team. And they were saying, Yeah, we we have our own server farm, that we’ve developed proprietary algorithms for scraping to get the data that we need. And I said to other companies do this right, commercially for lots of clients. wouldn’t, wouldn’t that be more? I mean, why? Why did you choose to build it yourself instead of just use these commodity services that exist? And they said, well, those services are too expensive. We can’t afford it. I said, but your product is an analysis layer on top of the data. You’ve got to have a really complete dataset, or it’s theirs, the analysis is going to be incomplete. And they said, Well, yeah, but it’s too expensive. And I talked to the services team. And I found out that the reason the services team was so large, was that the data was always incomplete. And the services team needed to go out and find the data themselves and force it into the product before they could produce a report and analysis that the customer would value. So the they didn’t want to spend the money on the data, but they were spending more money on the analysts. And they couldn’t scale because they couldn’t hire enough analysts and they couldn’t scale because they couldn’t pay for enough analysts. So this was not visible within the organisation because there was no place at which those three functions came together. The the VP of product on down through all the product managers was just focused on optimising the user experience within the software, ignoring the data, ignoring the services. The was only because I came in and asked a bunch of dumb questions, a bunch of newbie questions that emerged.

But if you think about it, if you were to set up the teams in the first place with ownership of all of the components of value for the customer, from the customer’s point of view, then that would have been obvious. Well, of course, the data is a piece of it. Of course, the analysts are a piece of it. Of course, the software is a piece of it, they all have to come together. So this particular company didn’t work that way. And it was It was the root of their problem if you asked me. So these, these behaviours really came out when we when I looked into or failed to come out when I looked into all of the details. Now that I’ve told you a sad story about a company that seemed on the brink of failure, but in fact, we got together the different functions into one room, the executive team, we did a strategy and roadmapping exercise. And we made a bunch of changes. I’ll read you directly from my notes, because I interviewed some people. A year later from it. We agreed on focusing on enterprise customers, we focused on making their problems go away through a proprietary analysis technique, with the data that we developed, we reorganised the teams around customer use cases, we added data collection and services people to those product teams. So the teams were focused on full stack, from data collection infrastructure all the way through to serving the customer based on different use cases. So they had ended up with three or four teams in parallel based on the different use cases. We let that VP go. Unfortunately, for him, but it worked out well for the company, but one of the founders, who had a real sense for the customer and the customer, what the customer saw as value holistically, because they had been there from the very beginning back in charge of product. And this worked, it reunite reignited growth for the company, improved margins, they were able to grow without increasing the size of the analysts team. I don’t know if they actually let anybody go. But you know, they, they had greater revenues on a fixed cost basis. And they sold the company a year later to to another company to a larger competitor. Unfortunately, as part of that larger company, they’ve undone since since I’ve since learned many of the things that they fixed, that got them to that point by separating out the functions again. But for a year there, it was really working well. And it got them the exit that they were looking for. That’s really the story.

So I’ve got tonnes of other examples if anybody is interested. But I thought it would be useful if you’re thinking about how do I judge my own team, or, or the teams of other companies, how I how I gather this data, because it is hard to do.

I’ve borrowed my own customer research techniques from when I was a product manager to do this, and one is you don’t just interview one person. And you don’t just talk to the the person who are the team that you’re actually just evaluating. So I don’t talk to just the product people. I also talk to the engineers. And as I mentioned, sales and marketing and finance, and design, and the data people and whoever I can talk to. And I ask them all kind of the same questions and see if I get consistent answers. And that’s really useful is I don’t tell them what Joe said, I just asked them their opinion. And then I write it down. And then I compare them. I also ask them a lot of open ended questions I just, I’m really fishing for what is on their minds. And that’s useful to one uncover problems that I that would not otherwise have been visible, and to to find out what their values are. What they think I want to know. Is is interesting. So the first question I asked them after, what’s your name? And What team are you on? is telling me on a scale of one to five? How awesome is it being in your job right now? Where five is best job I ever had. I’m lucky that they pay me. And one is we’ve wrapped this up. I’m meeting with a recruiter in half an hour.

And depending on what number they give me, I then ask that actually doesn’t even matter what number they give me. I then asked them, can you tell me why you told me that number? Whatever it is. So it’s the ultimate open ended question. I want to know what’s on their mind. And often, especially if they’ve given me like a two or something they just go on a rant and that’s super great material for what is not working in the company right now. I also have lots of follow up questions. So I’m asking about all those five behaviours that I listed out and So if I don’t get the information right away, I want to know, tell me about a time when that’s also my, my favourite prompt or question is, tell me about the last time that you it’s a good interview question to, to get at behaviours, it’s not hypothetical. It’s it’s real world. And then they can caveat it, they can say, but but but that’s not really you know what we would ideally do. But that is what the company really did. So that’s, that’s useful. I take super detailed notes, I type really badly, really fast. And then I’ve got 12 sets of notes, and I can start to pull out quotes. There’s no more powerful technique for proving your what you’ve discovered than being able to give three verbatim quotes from people around the company who said basically the same thing. I don’t have to put names on them. I usually try to protect people in that way. But they’re unedited. And I think that’s, that’s, that’s better evidence than my opinion.

I’m working on a way to take the same questions and turn them into a survey that I’m hoping that could be a quick screener to sort of detect where we should look in more detail. Because the only downside of this, I was speaking to a VC two weeks ago, I gave them the same talk. And they said, Well, that’s great, Bruce, but we have an hour with the VP of product as part of due diligence. How do I, how do we do this a little bit more quickly than 1245 minute interviews, which is what I typically do. So I’m hoping that a screener can make it possible for me to just talk to two fewer people and know what to get to in in those conversations. So that’s all I have for slides. But if this was interesting, we can have a conversation questions. And also I have a weekly what I call nano letter. It’s called a nano letter, because it’s super short. It really is as short as you see on the phone. So you can just glance at it while you’re making coffee. And people tell me, it’s the only newsletter that they get that they actually read, because it’s quicker to read it then to put it in your read later folder.

So, questions. Okay,

Mark Littlewood
First, if you’ve got questions, put your hands up, and then I’ll make sure there’s a mic ready for you.

Audience Member
Try and keep it short, two questions about the matrix. So the first is the horizontal oriented around the customer or the product streams? Do you have a view as to how long lasting a healthy product culture that those entities, yes to that horizontal stripe? Related question is, who does the hiring – the vertical columns or the rows?

Bruce McCarthy
Yeah, great question. So first, to the first question, the longevity much longer than you think. We’re talking years may be for those teams to continue to exist, especially if you’ve oriented them to the customer. Well, how often does your customer you who your target market is, how often does that change? Not very often. So the longer that a team stays on a particular customer and a particular problem space, the better that they the smarter they get, you know, we it seemed like this feature, or this use case, or this workflow was perfect. But we tested it and it didn’t work. And we learned that it’s counterintuitive. But here’s here’s what we learned. And this is really working for us now. And so we’ve taken that that forward. So now that doesn’t mean necessarily that the exact same people are on that team forever, right? People like to move around people change jobs, you hire new people. But the core of the team, it’s sort of like the Ship of Theseus, right? If you change all the boards in a ship, is it the same ship? Well, yes, it is, even if over time, there’s nobody on the team that was there two years ago. But I would still have those kinds of changes happening slowly over the order on the order of quarters. So that there’s some continuity on the team. The other thing the other reason to have teams last longer is they get to act. They get to know each other as people and how they work and how they work better together. There, I’ve been working with the same person in my company on marketing and content for the past four years. And we make each other’s copy better. Quickly, really quickly. We just did this a couple of days ago. And I said, here’s the outline. She wrote it, I rewrote one paragraph. And then she wrote my rewrite, rewrote my rewrite. And it was better than either of us could have done it. And that’s the kind of example that we’re talking about. And the whole, the whole thing took place over like 10 hours. So that’s my, that’s my answer to the first question much longer than you think. Oh, now, sometimes people say just on that question, well, yes, but sometimes the mission is reduced in importance, or the big milestone is met. Wouldn’t you disband the team at that point? And I would say, if it’s really like that, if it’s really milestone and accomplishment based it bring the next project to the same team, rather than reforming the teams around the project, because again, they’ve learned how to work together. So why you’re going to break up the band. So okay, that was the first question.

Your second question – I’ve forgotten already…

Right, I’ll give you two answers to that question. So for the most part, it’s top down the head of a function is hiring the people in that function and then assigning them to those teams. And then when they move from team to team, they don’t work for somebody different, right. But there is an emerging practice in larger software companies for creating kind of little mini divisions within the organisation and putting a GM at the head of that division. Usually a product person who’s been promoted from VP product to General Manager, HubSpot uses this model TripAdvisor one of the examples, I showed us this model. And that that GMs job includes p&l for that product or product line. And they will hire their product managers, and somebody else is hiring product managers in a different area. In some cases, they are also hiring other functions, marketing and sales and engineering. And it almost becomes a separate division within the company.

Audience Member
I have one question. When making product and you have your team? How did you align that team? Because a lot of developers want to wander around you. You said make this feature or make this product part of the product, and then just wandering around, like because they can and just that and just that and just that and who knows when

Bruce McCarthy
You say wandering around you mean developing features? Because they’re cool. They interest them personally?

Audience Member
Yes. They have, like a request feature. They detail on feature, what feature must have? And so but they add the extra feature today, because they can do they will be nice, or this will be nice. So how scope us Yes, how to scope them and say Okay, in this week, or this day or month? Don’t do anything else. Just that

Bruce McCarthy
Well, there are a few techniques.

One is as the whoever is sort of the holder of the vision, the teller of the story of who’s the customer, and what problem are we trying to solve for them? Maybe that’s the product person, maybe it’s a designer, but whoever it is, their job is to really compellingly make the case for what it’s going to take to solve this customer’s problem. And if we’re focused on that, then when someone says, Well, it will just take me a couple of extra days to add this other thing. But that other thing is not something that’s really focused on the customer need. It’s the product managers job to say not now. Maybe later, but not right now. Sometimes, I worked with this one company where the VP of Product said I think that my team should be focused on the customer, 80% and 20% on working directly with engineering. And the engineering manager was happy with that answer because it gave his team more control and autonomy. But the downside of that would be that that product team would not necessarily even know if the engineering team was adding stuff that might be interesting, but isn’t really in In the scope, the engineering manager was like, Yeah, you know, we can really play the role of PO/product owner for you, if you want. And the head of product was like great 100% with the customer and 0% with engineering. I need a sweet spot there. I need a balance where they come together and say, what is the scope of this thing? What’s in what’s out. And let’s be crisp about it. There’s a prioritisation bucketing technique called the Moscow framework. Does anybody know this one? I’m seeing Yeah, hands go up. It’s must have, could have should have won’t have is nothing to do with the city in Russia. It’s just the acronym. And so being explicit about won’t have I think is important. Does that answer your question? Thanks. Okay. All right.

Audience Member
Do you how much how much challenge do you see in terms of getting buy in across all the teams for that for that structure? So it sounds like in your example, the CEO leadership were really kind of bought into to making a change to to improve the situation? Yeah. I’m not sure that’s always the case, in terms of autonomy, particularly. That’s right. But then also for other teams like engineering and other folks like, Yeah, can you just talk a bit about that, and whether in that example, they were chatting?,

Bruce McCarthy
Usually, the pushback is not from the product, or the UX people. They are big advocates, usually, for the customer, where you’ll get pushback is from usually from engineering. And it’s usually on the grounds of efficiency, and specialisation. That is what we have experts in certain components or layers of the stack, and we want them there. They’re the experts. And we want them to focus on the most highly leveraged tasks for them.

So, organise the rest of the team however you like, but then just give us the tickets, and we’ll parcel them out to the experts. That was the case in this company, where the data collection team very specific skill set, very specific technology stack was separate from the rest of the engineering team that was building the software that the users actually used. And the and they actually worked for two different VPS. And they never talked to each other. And so when we first started talking about this, this was exactly the objection was I can’t have front end devs working on data collection scrapers, and things like that, they just the skill sets just don’t match up. And that’s true. But that doesn’t mean that you couldn’t put one data collection person and one business logic person and one front end dev together on a team that was focused on a customer who cares about manipulating that type of data that that person is in charge of scraping. And that’s what we ended up doing. But there was initial resistance. I think it was a combination of everybody else saying, Yeah, this, this idea of focusing on the customer seems like the right thing to do for the company. And maybe the resultant peer pressure. But the underlying the underlying difference is what you’re optimising for, if you are, it’s understandable that engineering is a scarce resource. It’s all we all know how hard it is to hire engineers. If that’s your constrained resource, then efficient use of that constrained resource seems like a good idea, except that you end up building a bunch of stuff that doesn’t solve the problem. Like to his question, right? You’ve been to building the wrong thing. And you don’t find out until late because it’s already done. Whereas if you’ve got the teams organised differently, well, then you’re efficiently pursuing the goal, which is making the customer successful. Shipping the features is not the goal. You know that Melissa Perry wrote a book called escaping the build trap, and it’s all about that. It’s all about let’s focus on the customer and the results that the customer gets and we get as a result of the customers success. Let’s optimise the teams for that. It’s a bit of a sales job. So that’s why I’m talking about it.

Audience Member
Yeah, hi, the story about the customer services and resonated quite a lot with what I’m seeing. And one of the things that I’ve noticed is since we all started working from home it’s increasing be difficult to get to a customer services people. And never, they just don’t come into the office. And they’re like, it’s a real kind of issue with getting the content, even if like the Head of Customer Services is totally kind of, yeah, let’s get together and work out what you know, our customers want. It’s actually making it happen. That’s really difficult. Yeah, no comments, advice.

Bruce McCarthy
What we did in this company was to put together a meeting with a bunch of the people that I mentioned, and let the customer service people talk about what challenges their customers were facing, with the product managers and some engineering leadership in the room. And to acknowledge that they were were the customer in some ways, or at least a real close proxy, to the customer. And you can do that on zoom in group sessions, when people aren’t in the office, but you get, I think you’ve sort of put your finger on, you’ve got to give them the motivation. To do that. I think one of the reasons that hadn’t happened in this particular company is the services team had given up on getting the attention of product or engineering, they just didn’t think they were interested. And they might have been right. But when we had this, this, this talk about who’s the real customer, and that recognising that services was at least one of the customers, and we said, we want with the services team to treat you like customers and do customer interviews, they responded really well to that. They, they were like, Oh, you’re actually going to listen. And you’re not just going to take my spreadsheet of Features/Ideas and say, we’ll get around to it. I was coaching the product team, to do a good customer interview with their own internal people do the same sort of interview that I do when I’m trying to understand what’s going on inside of a company going on inside of a company. Tell me your job. Tell me what you’re working on. And what does success look like for that thing? And that you’re working on? And where is that? Where are your frustrations or your worries right now about succeeding? That’s the essence of a customer interview. It’s not about your product. It’s about them and their job and success and obstacles. So when we started doing that, they all all of a sudden, which was initially it was kind of a quiet room. All of a sudden, when we started asking those kinds of questions, everybody sat up in their chairs and was like, Well, let me add something. Yeah, this part sucks. We really need to see what we can do about that. I think they need to trust that something will come of it. And maybe you just need a couple of successful examples to get them reengaged. Do we have time for one more? I think we should wrap up. You’re gonna be here for lunch and yes. Come find me at lunch. complaining, private, I think. All right, let’s talk about your teams.

Thank you

Bruce McCarthy

Founder, Product Culture

Bruce founded Product Culture to help communicate the key principles underlying consistently successful product-focused organizations.

He and his team help companies like NewStore, Camunda, hyperexponential, Socure, and Toast achieve their product visions through Advising, Accelerator programs, and the Product Culture Community. Bruce is a serial entrepreneur and team leader. He literally wrote the book on roadmapping: Product Roadmaps Relaunched: How to Set Direction While Embracing Uncertainty. His next book, Aligned: Stakeholder Management for Product Leaders is expected summer 2024.

His previous talks at BoS Conference have been instrumental in helping our attendees unblock some of the significant challenges that all companies face as they grow. You can watch them here.

Next Events

BoS Europe 2025 🇬🇧

🗓️ 31 March – 1 April 2025
📍 Cambridge, UK

Spend time with other smart people in a supportive community of SaaS & software entrepreneurs who want to build great products and companies.

Save your Spot

BoS USA 2025 🇺🇸

🗓️ To be announced soon
📍 Raleigh, NC

Learn how great software companies are built at an extraordinary conference run since 2007 to help you build long term, profitable, sustainable businesses.

More Details