Key Points
- How to use qualitative interviews to find problem areas and new opportunities for our product
- How to avoid introducing biases during our interviewing
- How to approach opportunity sizing
- Segmenting markets around needs
- The usefulness of interactive mockups to get validation and candid feedback
- Cross-team collaboration with customer-facing teams (Sales, Support, etc)
- Getting access to customers when the organization doesn’t let PMs get to them
- How to convince “busy customers” to talk to us
Transcript
Daniel:
Can you tell me a little bit about yourself and your background in product management?
Bruce:
Sure. I’ve been doing product management and related product development roles for over 20 years. I worked in big companies, like Oracle, with hundreds of thousands of employees, and small companies, like startups. I was employee number 25 at NetProspex, for example. I started my own company three times, at this point. I’ve worked in a variety of different industries: e-commerce software at ATG, information at the intersection of information and technology at both NetProspex and iMarket, a variety of different industries. I’ve also played a variety of different roles.
As you know, product management is a very broad role, it’s very different wherever you go, and it’s very much a sort of a coordinating role. You’ve got to coordinate all the different functions within the organizations to deliver value to your customer, and if some of those functions are not existing at your company because it’s a small one, or they’re not being done the way you need them done for the success of your product, then you have to fill in yourself, or you have to find someone. As a result, I’ve done everything from being a Scrum Master, to doing business development and partnerships, and M&A, to being an engineering manager, to being a UX designer, you name it. Other than writing production code, which I haven’t done, I’ve done a lot, written SQL scripts and stuff like that. I’ve done most of those roles.
I found myself, over time, increasingly in generalist-type roles, where my job, in addition to creating value within product management, is to be an advisor to the whole business on how do we do this product development and product delivery bit.
Daniel:
Perfect. Currently, you’re a consultant, working for different companies and trying to bring all of that expertise for them, right?
Bruce:
That’s right. For the last two and a half years [now 4 years as of Dec 2017], I’ve been doing consulting, training, coaching, and mentoring for product development team: everything from the product management side of things, to the go-to market, to how do we organize the product development team cross-functionally, for success. That’s where I think my experience really provides the most value in helping organize and motivate and direct the efforts of cross-functional teams.
Daniel:
Excellent. In your experience, what is customer feedback, and how important is it for your work as a PM?
Bruce:
It’s absolutely critical. If it would be 100% possible, and it has happened many times in the history of business, to very thoughtfully put together a cross-functional team of people to build an exquisite product that absolutely nobody wants to buy, and with a missing ingredient that most often gets you that result is customer input. If you don’t understand, you can’t put yourself in the shoes of the customer, then you’re very likely to build yourself a better mousetrap in a place where there’s no mice.
I don’t know if you want me to get into detail, but I’ve developed—.
Daniel:
Definitely, we will get into details a bit. I have a few questions on that topic. Let’s maybe start with the discovery side of things, and when you have a running product and you’re trying to find out about problem areas, or new things that you could be building, and you’re actively seeking customer feedback, what are you looking for? What kind of methods or techniques do you use to get this kind of input?
Bruce:
My favorite tool in the toolbox is, in a situation like that, it’s qualitative interviews, where I call and speak with customers, or other people who I suspect should be customers, but aren’t. Rather than ask them a … Rather than treat it like a survey, where I have a canned list of 20 questions that are mostly about my product, I try to have conversations with them. I try to have a 45-minute to an hour conversation about, not my product, about their job in the B2B space, or in their life in the B2B space. I want to ask them about their job so that when I am thinking about what my product should be, I can put myself in their shoes because they’ve told me about themselves, about what they are trying to accomplish in their job, and how they are measured; how their boss rates them, and what metrics are they trying to optimize.
Then, I ask them, “Okay, what are the hard things about accomplishing those goals, about doing your job?” Notice I haven’t said anything about my product, although usually they kind of know what my product is, and they’ll kind of tailor any answers to fit the area that I’m asking about. I’m asking them where are the challenges, where did they… What are the risks to them of, in terms of delivering on their goal, and what are the consequences that they don’t see. I’m trying to identify which of their various goals are most important and most at-risk, and most consequential if they fail as goals.
This allows me to dial in on their most important need, most important unmet need. I will also ask them a lot of questions about what they’re doing now to try to do that, whether they are doing something completely manually, or they’ve got a product that maybe changed their mind, or they’ve built something in-house, or they’re maybe actively searching for a product. That starts to shift the conversation, from “Tell me about your job” into the solutions phase, and where my product is.
At that point, once I have enough background, I can start to ask, “Well, how do you view our product now? How does it solve your problem? In what ways is it not positioned to solve your problem?” I try to ask questions that would have been much more difficult to ask at the beginning, like, “If we don’t have such and such feature, if we add it on top of our existing product would that solve your unmet need?” I can evaluate their answer based on everything they’ve told me about their needs to that point.
The one question you can never ask and get a useful answer is, “Do you like my product?,” or, “Do you like my product idea?” The answer to that, 80% of the time, will be “Yes”, and yet that yes doesn’t necessarily translate into a purchase, so you can’t really do anything with it; it’s not really actionable information. If you have a complete picture of this person’s job, and their frustrations and challenges in meeting their goals, then you can … They can’t really BS you. They’re in a position to say, “I told you that my goal was to paint the room red, and you guys only sell blue paint, so I’d like the paint, it’s a pretty color, but I can’t really use it as is, and if you tell me that you’re going to develop some new purple paint, or some new paint that has low fumes, that’s still not solving my problem. I need the room to be red.”
Daniel:
As you are exploring the problem space, it’s tricky to avoid leading the person to some preconceived of the idea of a problem that you think they might be having. Are there ways to avoid this kind of bias on our end?
Bruce:
Yes. First of all, the main method for that is starting with open-ended questions, starting with “Tell me about your job”, and even asking personal questions, like, “How long have you been in the job, and do you like the job; what’s the most personally frustrating thing about the job?” What you’re doing there is you’re developing a rapport with the person. You’re almost acting a little bit like their therapist, and they become much more transparent and honest with you because they realize that you’re not there to sell them something, that you’re really there for them… You start to get much more honesty from them in the first place.
The second thing is, you want to really be … You want to really be sure not to ask them about your product idea until you’ve asked them about the underlying problem, and you’re not asking, “Do you have this problem”, you’re asking, “What problem do you have?” Eventually, if you don’t hear that they have a problem that you are kind of hunting for, at some point … A half an hour, 40 minutes … You can ask them, “do you also have this problem?”. If you’ve got enough of a background on the rest of their problem, you ask them, “Can you rank [this problem that you are hunting for] on a list of your problems?” If this is a very important problem or other problems needs more attention. And then you’re taking it up a level of abstraction, and you’ve already got them so thoroughly into talking about their problems in general that hopefully it’s not a… Hopefully you’re not leading them.
There are other techniques… I wish I could give you an example, but sometimes I will be deliberately misleading about what I’m asking about. It’s usually opportunistic, something they say that I dig in, but I try. I can’t help with an example right now. The one other important thing to avoid is avoiding the “Do you like my idea” trap, and you’ll always get caught in answers to that, so you … You’re going to present some ideas of “do you have this problem”, or “do you like this solution”. It would be much better to ask them as a career issue, or, as I mentioned, you can ask about problems: “You mentioned these three problems. Can you rank them for me, and here’s a fourth problem that some people have. Do you have this problem, and if so where does it fit with the others?”
You can do the same thing with features. You can say, “You’ve asked me for two or three features in the course of this interview, and we have a list of features that other people have asked about that we’re considering. Let’s combine those lists, and now we’ve got a list of six things. Can you rank those for me? Can you tell me which ones resolve your problems best?” Importantly, ask them to explain why they believe each thing should be in the position it should be. It’s not just making up the numbers, but why they believe it. Again, this is really important.
I attended a focus group once, and… More than once, but a particular one I’m thinking of, and in this focus group there was one person who didn’t really have the problem that we were looking for. It became clear after the first ten minutes or so that this person was in a slightly different position than the other people, and they weren’t really going to be able to give us the information they wanted. Unfortunately, they were also the most talkative person in the room, so they, everything they were saying was speculation. They were like, “I imagine that a person in this position would want or need this,” and that’s completely useless information, so we asked that person to step out of the focus group.
Daniel:
All right.
Bruce:
My point in telling you this is, you want to make sure that you’re speaking within the bounds of this person’s reality, this person’s job, with their questions, and not asking them to speculate about what other people might want in different positions. People who are in product management or product development speculate about other people’s wants and needs a lot, but they’re the toughest interview, in some ways, and I’ve done a bunch of those, because I try and have product in development for product managers. It’s important, in order avoid leading the witness, to always ask them to repeat and explain any claim that they make, and preference that they express, back to their own jobs or their own life, what would make a difference for them. That keeps the conversation awesome.
Daniel:
The next conversation I had on that topic is, how do you go from a few people that you’ve talked to to understanding that there’s a real opportunity for the larger market? How do you size that opportunity in a way that gives you a lot more comfort or assurance that you’re making the right decision?
Bruce:
Great questions. I have two answers for you. One is that it takes surprisingly few of these qualitative interviews to begin to start hearing the same things over and over again, and to develop a set of needs that you’re pretty sure are real and consistent, that you understand. Jakob Nielsen had an article some years ago, where he said that in UX testing you start to get seriously diminishing returns after five or so interviews, and I believe that’s often true in market research, as well. I usually shoot for eight or so, we have maybe ten in a given customer segment, to be sure that I have gotten the whole story, but if it’s a relatively homogenous market, eight is plenty.
That doesn’t give you a scientifically valid, projectable sample, and so the second stage, after you’ve done your qualitative interviews, usually, is some sort of quantitative survey. You might be lucky and somebody’s already done a survey, and if the audience for the survey is pretty much the market that you’re going after, then you might be able to use that information, but often you have to do a survey, you have to create a survey for your own customers, your own prospects, and the biggest mistake I see people …
Before we get to the mistakes, the purpose of the survey is to size the insights that you come up with. You’ve come up with an idea of the target market, based on your eight or so interviews, you have a description of the type of person who is potentially a customer, and you have a list of problems and potential solutions, at that point, that you can test in a survey, and you can use the survey to quantify and rank those problems. You can use the survey to find out if problem A is really more common than problem B. It turned out it was more common in your interviews, but that’s not a scientifically valid survey in terms of the sample size, so you want to validate that across a larger sample size. You can also try to sample adjacent markets and see if they have the same problems, or if they don’t resonate as well, to get an idea of the size of the market or segment of the market.
The biggest mistake that I want to come back to, that I see people making and doing surveys, is doing surveys before the interviews. They figure, “We’ll get inside the information, and then we’ll zero in on the most promising prospect, and we’ll interview them,” but that’s backwards. The primary reason is that I don’t think you can write a really good survey that will get meaningful answers from your target market, until you get to know a few people in that target market better, you can’t understand how they categorize things in their mind before… You can’t write a survey, a multiple choice answer question until you understand how they categorize things, and you can’t phrase a question unambiguously until you know how they talk; until you know the words that they use and what they mean, their contact.
We’ve all taken surveys where it seems like every question none of the four answers are correct.
Daniel:
All right. Yeah. You were talking about addressing a market, or maybe addressing an adjacent market, to where you think an opportunity might be. That comes with segmentation, and how we define a market. In your view, what’s a proper way to define customer segments or market segments in a way that makes sense, both for user research and understanding customer feedback that might be coming in later?
Bruce:
Everybody has a different opinion about this. My favorite way of doing it is by needs. I want to group people by common sets of needs, so the people who, we’re going to use the car industry, the people who have a need for basic transportation are a different group of people who are then those who have a need for family, moving a large family around, and they’re different from people who are looking for prestige. They want an expensive car that looks expensive. They all need to get from point A to point B, but the auto manufacturers have become very good at segmenting their customer base by those secondary needs, and the brands are built around that.
Daniel:
Right. When you’re moving to building the product, what kind of customer input are you seeking at that point?
Bruce:
Mostly validation. I’m a big proponent of the Lean Startup methodology, which I think applies equally well to a new product or existing product, and you’re looking for validation and traction. The important thing, in order to get that, from customers during the development process is to have something to show them, something they can interact with and react to. Waterfall process, you would write the whole stack and do all this design, architecture design and then implement every bit of version one of the product, and then launch it with a lot of fanfare, but that gets back to the problem of lack of product-market fit. No matter how good your research was, your initial ideas of what might hit the market needs are going to be deficient in some way, and possibly some critical way. In fact, likely in a critical way, given how often new products fail.
The way to de-risk that is, at every stage, first of all, have rapid iterations where you have something to show frequently to potential customers. Secondly, just build it in such a way that you’ve always got something new and more refined to show, no matter how narrow that is. It might be that, initially, you just had wireframes, but I actually much prefer a clickable mockup to a wireframe, because a potential user can interact with a clickable mockup, and you can tell them that you can give them a task and see if they can accomplish that task, and talk with you while they’re attempting to accomplish that task, about the experience, and whether it’s meeting their expectations, and in what ways it is used. You get the real high-fidelity feedback from a clickable mockup, where a bunch of Powerpoints with some wireframes don’t have that same interacting with this, and it’s working for me or it’s not kind of reaction for customers.
Daniel:
Right. A question I would have on that front is, is there a difference between a reaction from a potential customer and an existing customer when you’re showing them mockups, even clickable mockups?
Bruce:
Actually, I find that existing customers are sometimes tougher on you, because they know how the product works now, and hopefully they’re satisfied with it, and so anything you show them is a change, and people don’t really love change, in general, unless they’re in pain, unless they really… The reason they’re willing to participate is that they told you frequently that there’s some significant deficiency in your product, and you’re showing them a potential solution. That’d be helpful… It sounded like you had something in mind. Was there some question?
Daniel:
The question was a bit more on how do you approach that in a way that disarms that disbelief or that negative reaction on a first level so that you can get their insights on a new version that you might be trying to build.
Bruce:
Right. I will say there are a few techniques I use to put the person at ease, and one of them is to make sure they understand that we’re testing the software, not them. I know this wasn’t exactly what you were asking about, but in a lot of usability tests people who have never done it before are kind of nervous, and they’re like, “I hope I do okay.” You have to reassure them that it’s about the product, not about them, and that the best thing they can do is tell you that they think is not intuitive, or they can’t figure it out or whatever, because that’s actually what we’re looking for. And the second closely related thing is, again, people have a tendency to be nice about your product and not tell you what is not working for them, and so you actually really want to push them to be critical and tell you when something is not working for them, or doesn’t fit quite correct with them, or is confusing. It can be… I find you often have to remind people multiple times about that.
That depends on the person. Sometimes you just get somebody who’s cantankerous, and doesn’t want things to change, and so with that person, in order to set them at ease, what I’m thinking about is saying, “We’re just trying out some ideas. This is early days, early stages. It’s not working software.” If I know that person is possibly going to have that kind of a reaction, I want to set the expectation that this is not finished software. There are some things you could do in the presentation of the software to make that clear. If you want to make it look like it’s really done and high-fidelity, you can do that these days: you can make clickable mockups with HTML, with really snazzy CSS that looks like it’s production code, and it looks like it’s a prototype rather than just a static mockup; or you can do a paper prototype technique, either really using paper or using something like Balsamiq, where it looks like a drawing. You’ve ever used that?
Daniel:
Yeah.
Bruce:
With a paper prototype you can, or with Balsamiq you can still simulate interaction. You just have to do it through non-traditional means. Take the prototype, you have to … You’re the computer. You replace one piece of paper with another, or you remove a sticker and uncover a new state of a button, or whatever, and it takes a little bit longer to conduct the test, but it’s really easy to set up for the test, because you’re just drawing, and it’s really easy to iterate on it, because you get out your eraser and draw something else between tests. Balsamiq is almost … You can set up links in Balsamic so that if a user clicks on something it goes to another screen, and there’s also something called Powerpoint Prototyping. I don’t know if you’ve ever heard that phrase.
Daniel:
Yeah.
Bruce:
You do the same thing: you put screen mockups in Powerpoint and you link them together into a flow and you walk the user through a scenario.
Daniel:
All right. After building the thing and getting notes, it starts to produce a lot of quantitative and qualitative data, and in terms of what we’re tracking and what we’re receiving from users. It’s very difficult to know where to focus and where to look at, so do you have a general approach into the day to day analysis of metrics and qualitative feedback that comes in?
Bruce:
Right. Customer requests are simultaneously a blessing and curse. You have an existing customer base and you’re going to get requests for features or other kinds of changes to the product, and sometimes you could get lots of them, hundreds of them, thousands of them, depending on how many customers you have, or even if you have a small number of customers, but they’re enterprise customers and its’ somebody’s job to interface with your company, and so they feel like part of their value-add is to give you an endless list of requests. You’ve got all of these customer requests, what do you do with them? The biggest mistake that you can make, I think, as product manager, is just to take those requests as-is and figure out a way to prioritize them by, say, frequency, or revenue, or size of customer, and just put them into the backlog and do them without any further examination.
Many products have become really bloated and difficult to use because they’ve become overloaded with features that nobody really uses. There was somebody’s bright idea, but there really wasn’t a real need or a good solution to a need. We need only look at Microsoft Word, which has 80 gazillion features, 80% of which nobody uses. You just want to be able to create a neat document, and Microsoft, actually, they’re on record of saying that 80%, some very high percentage, I’m not sure, but of the requests that they get for new features are features they already have. People are not discovering those features, either.
What do you do about this? The way I think about it is, in any list of, say, 100 feature requests, there are probably three to five underlying needs, and the job is to figure out what those underlying needs are, and so when you look at the actual requests as written, it was probably given to a sales person or a support person by a customer, and then written down, and so it’s a little bit like a game of telephone. You’re not really getting the whole story. It’s a secondhand translation of somebody’s best guess as to the solution to a problem, but the problem is not stated in the request. Not usually. You’ve got all these various requests: they’re underlying problems, but they’re not stated there, so what I usually do is I try to group the requests into what I think are maybe different ideas for solving the same problem, but then to call up some of those customers and try to validate my assumptions. What I’m asking those customers is, why did you ask for this change or this petition for the product? What problem were you hoping to solve?
I have a blog about this I can send you later. Often, you end up digging under multiple layers of why. Have you heard the expression: “Five levels of why”?
Daniel:
Yeah.
Bruce:
The idea is you sometimes have to ask why does somebody want something, and then, why does somebody want that. The next thing that they say, up to five times, before you get to the real, underlying problem they want solved. The idea is you can get to that underlying problem. As I said, there are usually fewer of them in any long list of requests. Then you can take those problem statements back to your development team, you can say, “All right: let’s figure out the best way to solve this group of problems,” and if you do that then all of those customer requests will usually evaporate, because you found the best way to solve the problem, rather than just six different ways that other people came up with. You can do that with less engineering time and effort, because instead of having to make 100 changes, you’re only making three to five changes.
Daniel:
You touched on two topics, there, that I wanted to try to expand a bit more on, which are, first, the issue of cross-team collaboration with sales support, account managers, and eventually other customer-facing teams. How can we set up a process so that our relationship as product managers with those teams is productive and effective, and in a way that also gets them the same page as we are, in terms of what we’re looking for?
Bruce:
Good question. There are a variety of techniques that I think are necessary. The core thing that a product manager needs to do, I think, in an organization, is talk to everybody, is have good collaborative relationships with all the different departments.
My friend, Neil Baron has this concept he calls “Circles of Value”, which places the customer at the center of a circle of all the different functions within the organization that are involved in delivering value to that customer. That’s everybody from, obviously, product development, but also sales and marketing, and even finance, where they’re involved in the purchase, in the pricing decisions and the supply chain decisions. Even HR, where the right kinds of people need to be hired for customer support, for example, like background and profile.
Every department is involved, and since the customer can’t be there every day to do this coordination job, the product manager becomes the stand-in for the customer in the center of the Circle of Value, making sure that all of these different parts of the organization are coordinated to deliver that value. That puts a lot of pressure on the product manager to really have effective relationships with all the different functions, and as I said, there are a variety of things you can do. The first, most important one, is you’ve got to make friends with those guys.
You’ve got to actually show up on the sales floor, or in the support departments, and just get to know the people and find out what’s going on, and help them out now and then with challenges that they’re having, because you’re the product guy who wanders through the department, you will get questions, and if you’re too busy to answer people’s questions or set up a meeting with me, then you’re not establishing a good relationship: a good, collaborative, casual relationship.
If you’re like, “Sure, I’ve got five minutes. Let’s talk about that,” or if salespeople are asking, “How do we handle this competitor or that competitor,” go off and volunteer to do a little research and get back to them that afternoon with a little bit tidbit: “This is how I might position to get that competitor. They seem to have this weakness or that weakness, compared to us.” Be willing to engage in these informal conversations. That’s one.
Another thing that I find is really helpful is to have a little bit of a formal process, where you get together with other departments on a regular basis. Some companies have a product counsel, with representation from different departments. Both the product management team gets in front periodically, to present the current thinking about priorities and roadmap, and the current status on projects, and they’ll do that monthly, or quarterly, or something like that. That’s useful.
Another thing that I believe in, in any sufficiently complex situation is a prioritization scorecard. My product Reqqs incorporates this because I developed one over time, in Excel, and the model quickly got beyond Excel’s capabilities. The scorecard basically provides a transparent way to come up with and explain and collaborate on prioritization. If we’ve got a list of 50 initiatives that we want to do, and we’ve got the bandwidth to fund ten of them, we need a process for designing which are the ten winners for this. I prefer a scorecarding approach when you have a number of stakeholders, because we can make clear what the logic is.
Scorecarding approach basically compares the ROI of any different, of proposed features or initiatives based on the goals you’re trying to achieve versus some level of effort. If your goals are strictly revenue, then you can put that up at the top; if you’ve got a market share goal, you can put that up at the top; if you’ve got, getting your first ten customers for a new product, you can put that up at the top, but some measurable goal can… Usually there’s between three and five of these goals, and you score every idea for something you might do that’s going to take some effort.
As to how much it will contribute to those goals, add that stuff up, divide by level of effort, and I usually have a competence score that takes it to account risk, an uncertainty, and we derive a number from that that you can use to prioritize. The critical piece of that scorecarding methodology is that product manager can’t do it in isolation they can’t just fill in all the scores and then publish it and say, “It is done.” Instead, it becomes a framework for having a conversation with all the stakeholders.
What I’ve done in the past is I’ve taken my scorecard around to all the stakeholders and I’ve asked them to give me whatever ideas they have that they think we should be doing. I put them into the scorecard, I sit with them, and I do the scoring with them. I said, “All right: based on the goals that we all agreed on at the executive meetings, I think this score’s a two on a scale, and a one on this one, and a zero on the other one,” and we have a discussion about whether we agree on those scores, and how certain we are of those numbers.
We come to some sort of alignment, even if they don’t completely agree with the score that I put down in the end. I believe we’ve heard them out, given them an opportunity to tell them what they think. Then, I repeat that with all the other stakeholders, one on one, and get everybody on the same page about how the scoring is coming out. What that does is it really, it gives everybody a shared context for how we’re making these decisions, and if something that a project of theirs did not highly prioritize, at least they feel heard and they know why.
Daniel:
The issue there would be how to set the waits for the different goals that you’re trying to shoot for. That’s the baseline for the prioritization strategy: getting everyone to buy into the fact that you need X percent of investment on growth, or X percent of investment on bug fixing, or whatever, some other goal might be, right?
Bruce:
Right. There’s frequently argumentation about that, as well, but you have to start with that. I actually find it, the model that I use, the mathematical model I use is a very simple scale. It doesn’t require weighting between the different goals, because I use a simple scale of one or two. You know what I mean? That’s how the score is. One means it helps some, two means it helps a lot. Those, not just the what is “some” and what is “a lot” are not defined, and also the weighting between the goals is not defined.
With that simple scale, I find that you get a good separation, as long as you have a few different goals. Usually, like I said, there’s three to five, and if you incorporate things like confidence, then you usually get a reasonable outcome without having to set weights. The reason I don’t want to have a very granular scale for completing goals, like one to ten or one to one hundred, is that I want to avoid those arguments, because, in the end, they don’t matter. In the end, it turns out that you can do a pretty good job of prioritizing with a very simple scale.
Daniel:
Going back to the other topic that I wanted to dive into from a previous answer of yours was the fact that we need access to customers, and when you were talking about how you were to understand what the problems were behind some customer requests, you would then try to talk to a few of those customers, but in many large organizations, usually PMs have a problem with getting access to customers for different reasons. Why do you think that is, and how can they try to overcome that?
Bruce:
It’s usually a problem of departmental silos. It’s usually a problem of territory. One, the executive who’s in charge of sales is a different person than the executive who’s in charge of product management, usually, and… They don’t feel like natural allies. It’s just an unfortunate, in a large company… The salespeople’s job is to control the relationship, to manage the relationship with the customer, and to make sure that it goes well, and that the chance for renewal, or whatever it is that they’re striving for is maximized, and the product manager can be an unknown variable in that process.
Product managers sometimes ask questions that seem like they’re out of left field, don’t necessarily support the sales conversation that the salesperson is trying to have. There are different kinds of products and services where this is more or less true. In an enterprise sale, where the customer is very invested in the success of the product, and the implementation of the product, the product manager can add a great deal of inside information and credibility to the conversation, and I find that in enterprise sales, salespeople, are much more likely to want a product manager to be interacting with the customer.
They still probably want to be on the call with you, as a product manager, to make sure everything goes well and expectations are set properly, but they’re much more willing to make that introduction; where I find it’s much, much harder to get on the phone with a customer where the product that you offer is just a very small part of their job. They’re busy, and that’s not … They don’t have time for you. They’re not as invested or in the B2C sense. If it’s not a product that they use to care about every day, if you’re selling smartphones … People are addicted to those things. They want to give you as much of their opinion and point of view as possible, but I suppose if you were selling garden hoses to somebody who doesn’t think that much about yard work, they probably would have a harder time finding time for you.
That’s one aspect of it. Going back to the internal picture: there’s kind of two or three ways you can go about this, and it depends on your organization, which ones are going to get you the most traction. The first one is I go back to just developing informal relationships with the actual salespeople, the actual support people, where you become helpful to them and they start to view you as an ally, and as someone who can help them with their sales problem. If they see you as a trusted advisor, someone who adds value to them, then they will trust you to do that with the customer, as well. That handling is at the grassroots level, where a salesperson, an individual salesperson, might be willing to bring you in, and if you, if they’ve asked you to come in and help them with demo, or to answer some tough questions, or to tell the customer no at a critical time, then when you ask them, “Can you introduce me to a couple of customers in this area,” they’ll be much more likely to go ahead and do that.
If word gets around that you’re this helpful person, then that bubbles up not only to the other salespeople, but up to management, and then it becomes an institutionalized policy that of course Product Managers talk to customers.
The other way to go about this is VP to VP, to somehow see if you can get an agreement between the VP of product and the VP of sales, that product managers can talk to customers, and get the ground rules agreed to what the conditions are. I’ve been in companies where, because the salespeople were just so under the gun, and that the… To make a lot of outbound calls, the agreement was that the product team could call any customer, any time, on their own without having to involve a salesperson. They needed to log into Salesforce, but they didn’t need to go through the salesperson, because they didn’t want to distract the salesperson. It was a very transactional business. I thought that was actually… That made it easy. I could just call the customers directly.
Other companies I’ve been in where the two VPs agree on the ground rules, and the ground rules are that the salesperson needs to make the introductions, and then maybe ground rules will include the salesperson being on the phone, or maybe they won’t. I’ve tried to avoid having the salesperson on the phone, because I feel like I’ve yet … There’s two challenges, I find, having a salesperson on the phone with you. One is that the customer won’t always be completely honest and open with you if they know the salesperson is listening, because they always … Customers always feel a little vulnerable in front of salespeople: they’re ready to pounce on any sign of weakness, and so they can’t … They’ve got to be a little careful about what they say.
The second problem, I find, is that salespeople will sometimes jump in and answer the questions for the customers, because they want to … They’re just trying to be helpful. They have background on the account, they’ve known this person for years or whatever, and they just want to contribute, but, in fact, I don’t want to hear the salesperson’s digested version of the situation: I want to hear it in the customer’s own words, and the customer’s situation may have evolved since the last time the salesperson talked to them, as well, and we just lost the opportunity for me to get that real, direct information, because salesperson jumped in and tried to answer.
Daniel:
The issue of busy customers, and the fact that they don’t have the same availability of time for you, any particular tips on how to try to overcome that?
Bruce:
In a way, it’s like any sales job. You just, they say that it takes seven touches, on average, to get a decision on a product, and that, unfortunately, most salespeople give up after three or four, and so it’s the same thing in product management. You have to use a bunch of business development rep, EDR-type techniques to just continually, but respectfully, go after a person and try to get on their calendar. You call them, and then you alternate with e-mail, and you call them again, leave them a voicemail. If you just keep at it until you get enough of the interviews that you need …
I keep a spreadsheet where I write down, if I think I want eight interviews, then I’ve got ten times as many customers as I need. I’ve got 80 people lined up, and I’m just going to go down the spreadsheet, and on day one I’m going to make a bunch of calls, and then on day two I’m going to call more people, and then on day three I might try to call back some of the initial people, and I’ll mark all of that in my spreadsheet, and I’ll mark when I get an appointment, and so on.
Sometimes, product managers don’t have time for all of that, and so I have sometimes had good luck with actually hiring a temp to make the calls and send the e-mails to try to set up appointments, whereas, having an associate product manager, somebody who’s new to the role, make the, outbound calls. I think it’s a good technique, and then when we set up an appointment and I get on the phone with them.
The other thing is, is you do have a good relationship with sales, or … Here’s a sneaky back door with support, you can leverage the fact that they need to talk to these people regularly, and you can just say, “Hey, I’m looking for eight interviews with this kind of customer. Do you have any of those kind of people that you’re looking for an excuse to call them, anyway?” Then, I get the salesperson or the support person to make the call, and the reason is because they want to introduce them to their product manager.
Daniel:
Excellent. Bruce, I’m guessing that you’re probably at the site that you need to get to right now? Yeah? Thank you very much for your time. It was great talking to you, and I hope it was also good for you.
Bruce:
It’s always fun to talk about this stuff. I hope it was useful.