Collaborating with enterprise customers — tips 1-4

In this video, we’re going to talk about collaborating with Enterprise customers. If you’re operating at that higher level of abstraction and that’s your customer, this will help you very directly. If you’re down there dealing with customer request that you’re not sure is such a great idea, this may help you kind of manage upward a little bit. Why do big customers buy things through smaller companies? There’s lots of good reasons. In Act I of this little play, we get the deal.

And the big customer says, yeah, we’re going to have this specialist company do this thing for us because that’s their focus, and it’ll get it done faster for us, and cheaper, and better, and it’s just a better way to solve that problem.

In Act II, things start to get a little weird. The big company, not on purpose, but they just start managing you, their vendor, as they would their internal team that was going to do this. And things start to get a little bit, kind of strange. You’re not sure about some of the feature requests, and maybe neither are they. But you’re not sure, and the product direction feels like it’s getting kind of shaky. Act III, they are like, hey, we don’t like this product because you did all this weird stuff. And then you say, but you asked us to do those things. And that’s a sad ending that happens sometimes not infrequently to these relationships.

So how do we avoid this happening? Because, believe me, it’s very much your job as the product manager to help with this, because your job is to creep the right balance with the product and make sure that you’re helping this big customer get what they want. But you’re doing it with a product that they’re actually going to like in the end. And it’s not easy, it’s hard. Sales and marketing probably has a number that they need to hit. Consulting and support are out there trying to make things work for the customer. And development’s trying to hit deadlines and meet all these feature requests while keeping their technology infrastructure flexible and robust enough to keep the pipeline open for new features.

So it’s hard. You’ve got a really powerful, and you’ve got a very big customer here exerting a lot of potentially very strange gravity on some of these things. Here’s some ideas. 1, anchor to problems, not solutions, which we’ve already talked about. And I think you’ll find that really helpful. Here, the twin anti-poles of design failure, I call them. One is doing precisely what the user asks. The other one is assuming you know what’s best and ignoring the user. And these have one thing in common which is that neither of them work. They’re a failure mode, and the way that you resolve this is that you use the techniques that we talk about. You make sure you’re solving the right problem.

You make sure you get what the customer wants. If they want something that doesn’t make sense, you ask them about it. They say, you must make all the screens yellow. And you say, okay, well we want to make sure you get what you want. How will we know if that’s working? What problem do we want to solve here? So we go back a step with them and they say, well, all our staff are colorblind. Or we need to be really bright because they have to work in dark rooms. And then maybe that allows you to come back and say, well, maybe there’s a different way to solve this problem that’s even better.

This is particularly useful in the context of a large customer, because you can’t go back to them and be like, no, we’re not [LAUGH] going to do that. because they’re a big, huge customer, so you’re either going to get clobbered or, worse, kicked out of the account. And that’s not workable for the company. Probably, that’s not good for either of you. You need to get them what they want, but you need to help them through that, because it’s your job to make a good product. So make sure you anchor their request and problems, you’ll have a lot easier time getting them to a good solution. Write really great user stories.

And I wouldn’t necessarily show them directly to the big customer, but these are a great tool for helping you operationalize the thing we just talked about. So it’s a lot easier to, if the customer says, I don’t like what you did here. It’s a lot easier to go back a step and say, all right, well let’s talk about what we were trying to achieve with the user’s story from this product and talk about whether that’s the right thing or not. And then we’ll move forward and talk about the specifics of the product. Should you have to do that? Yeah, probably. I mean, your correspondent, the customer, probably isn’t a software developer, or a designer, or person doing software.

They’re trying to do a good job. They see something that they don’t think it makes sense and they’re worried about, take them through your process, help them understand. And maybe you are wrong. That’s the other thing here is, if you really have built the wrong thing for them, which is of course going to happen, this is a much better way for you to figure out exactly where you went wrong and to course-correct in the right way rather than kind of over-correct or over-correct in a weird way. 3rd, work in prioritized, relatively small batches.

Big companies, if it’s enterprise software, big companies often monkey bar between one disastrous enterprise software implementation to the next. because they’re always hoping the next enterprise software solves the problem. Instead, work in prioritized, outcome-based batches, and make sure

that you’re getting the outcome that you want before you move to the next thing. Or, if you’re forced to move to the next thing because of schedule or it takes a while to realize the outcome, make sure you’re looping back and looking at the outcome you both wanted and seeing if you got there or not and, if not, why. Test appropriately and test often. We talked about the difference between usability and motivation. Hold webinars. Make sure you’re getting a chance to interact with the actual users of your product at the big customer through some way. Really depends on the situation.

When I ran my last company and I went to go see a customer, they would say, hey, you’re going to sit down with the vice president of support. And that’s [LAUGH] good, that’s a very important stakeholder for me. But I also need to make sure that I see their actual support people and I watch how they do their jobs, because if they’re not happy, the vice president of support is not going to be happy. So make sure you have the right access, and then test appropriately. This isn’t necessarily exactly the right thing for you to do, but this is one view of that.

At -1 Day, we’ll call it, just sort of the whole period before you actually decide to start building something or configuring something, make sure that it’s really important to the users. And, as we talked about with Agile, front-load the value. So pick the stuff that’s going to be most useful and do it first. Let that drive the schedule to the greatest extent possible, because that’ll allow you to hit doubles and make friends. Then, before you roll the thing out, do some usability testing. Make sure you get really, if it’s software, make sure you get really good sample data.

So not just an arbitrary super-controlled version, but get them to put some real data into the system and see if it works. See if they do it the way you expect before you roll it out to all the users. And at the end of around 30 days, that’s a good time to look at, does it stick? I mean, are they still using it. Are they still using it in the way you expect, because just because you’re okay here doesn’t mean you’re going to be okay here. Why? Habits have to form, if you remember. And we have to get the users in the right habits.

Plus, you’re only testing with a small subset of people here, where you’re testing with a big bunch of people here. And then, finally, we have the outcome. If the forecasting was supposed to get easier or the contract process was supposed to be faster and more error free, is that actually happening?. It’s kind of a scary question, but you’ll be better off with your product and you’ll be better off with your customer if you instrument some observation into that and you make sure it’s really working. Those are a few ideas about how to make things better with these big customers so you both get what you want.

And you have a hard job here, but you have an important job if that’s the kind of customer you sell to. because you really need to work with a customer to create the right balance between the sales people who sold this thing, the support, the consulting people, that need to make it work for the customer. And development, which is going to build the stuff for the customer. It’s a challenging job, but be diligent, stay focused, and you’ll be fine.