The importance of teamwork, here comes the science bit & managing customer requests
One of the things that really bothers me about product development is the dynamic that can exist between product management and other teams... the constant back and forth where developers are fighting with designers who are fighting with product managers (or product owners 🥲) and you seem to be in the situation where everyone's just blaming each other and no one's really happy with how things are going.
Now even the most parochial team members will probably admit that this doesn't sound like the best way to work. None of this product stuff works if we don't succeed (or fail) as a team. So try this... the next time you feel compelled to defend yourself or blame others, take a breath and have a think. There's no one way to fix cross-team dynamics but you absolutely need to find a way to try - you might start out by having a coffee with the colleague in question and see if you can find common ground. As with anything, small issues become big ones if left to fester.
New podcast episodes
Here are the podcast episodes I've released since the last newsletter!
First up is a fantastic chat I had with Holly Schroeder. Holly is a senior UX researcher and passionate accessibility advocate who wants us all to make better product design decisions and be inclusive of users regardless of disability or impairment. You can check out Holly's episode here. She's also got a great list of resources which you can check out to get some inspiration for how you might make your products more accessible.
Next up we have Moustapha Seck, an African-Canadian entrepreneur who built up his product management muscles in Canada before being inspired by Zero to One to go back to Africa and build a startup to solve problems for the poorest Africans. You can check out the episode here and hopefully get some inspiration for solving some hard problems yourselves.
The (Product) Science Bit!
I was delighted to join One Knight in Product alumna Holly Hester-Reilly, founder of H2R Product Science and host of the H2R Product Science podcast as she took the mic and asked me some tough questions about how to navigate B2B product management. Check out our episode here.
You can also check Holly's appearance on my podcast right here.
Handling Direct Customer Requests
Ah “professional services”… the typical product management comeback whenever anyone mentions a specific customer request. That’s professional services! How dare anyone request things!
It’s no secret why product managers don’t want to do this. Specific customer requests can be problematic; they are likely to be poorly validated solutions rather than problems to solve. You’re being asked to assume a few things:
This specific customer has a specific need that all other customers need just as much as they do
This specific customer has enough knowledge about how your solutions work and how you might solve the need they have
This specific customer has enough product management & design expertise to design the best solution
You’re also being asked to prioritise things based on nothing other than the order in which sales teams speak to customers, or that renewals are due.
But…
If you’re operating in a B2B world, there are reasons that you might be pushed towards doing this. Ideally not all the time, but “just say no” doesn’t work when (for example):
The vast majority of your revenue comes from a handful of customers
The signing (or renewal) of a deal is existential to the company and the customer is making demands as part of the deal
We can argue all day about whether you have actual product/market fit in these cases. Or whether it was a good decision to have put all your eggs in so few baskets. Or whether that extra feature will really win the deal. But it’s not unknown for these situations to happen and you need a plan of attack for when they do.
Get Boolean
If you have to do this work, make sure you’re explicit that everything’s an OR not an AND. Technically it’s an XOR.
What does this mean? You have other initiatives ongoing. Some of these are not going to get done as planned if you do this new thing instead. Get specific about what is being bumped, and hold the line as firmly as possible. You might think that this will protect the roadmap and make the customer request go away because we all bow down to the awesome power of our product strategy and roadmap.
Think again!
Maybe that happens sometimes, but not all the time. The most important thing is to be explicit and steer clear of “it’s only” or “it’s just” type conversations. It’s never only, and it’s never just!
Treat customer requests as input for discovery
First things first, don’t just shoot down a customer request just because it’s a customer request, or because you didn’t unearth it yourself in your perfectly planned discovery sessions. In B2B product management you’ve got a bunch of people you should take input from. You want to get in front of customers & users regularly but Sales & Customer Success people are speaking to them all the time. It’s not your job to mindlessly start building whatever the last customer said to someone, but you absolutely can’t just ignore it.
So, do a little digging and find out if there’s an actual unmet need here. Speak directly to the customer or the prospect and do the Jobs To Be Done dance. What are they looking to achieve? Is this the best way to achieve it? Ask yourself whether there’s a valuable, generic feature you can make out of this request.
And remember to speak to other customers too, not just the one who asked for it.
Make it generic
One of the worst things you can do when building a feature that has been requested by a customer is just building a hard-coded, specific feature that only works for that one customer. You’re building yourself down a blind alley and making the product harder to maintain. Worse still, you’re leaving money on the table because other customers might want to pay for that feature too!
Make sure that the feature you’re building is at least potentially usable by other customers. Maybe this is a little more work to get right, but you’ll end up in a better place when the next customer asks for something similar.
Get tight on the scope
Quite often, this sort of request will come with a date attached. You want to avoid this as much as possible, but if there are timeline expectations you need to avoid promising the world. Building products doesn’t work like that. If time and team size is fixed then scope or quality are your only levers.
We don’t want to compromise on quality, so let’s focus on the scope. Work out the smallest version of the thing that could claim to answer the customer request with a straight face, build that and then pause. MVP the heck out of it. Remember, it’s fair for customers to want things, but they aren’t necessarily going to propose the best solution. They might also be completely happy with way less than they originally asked for.
But who’s doing the work?
Companies that offer bespoke consultancy and custom development generally charge a premium for doing that. That’s not a bad business model and there are pretty successful consultancies out there, but when we build products we want to build something that can scale.
Sometimes, people recommend allocating X% of time to customer requests. This seems like a neat option, better than random chaos at least. The problem here is that it’s easy to get pushed outside of X% and anything with percentage allocations can quickly add to more than 100%. So, by all means, try this but be careful.
Another option is to build a separate professional services team. They’re either developing stuff alongside the product team or hopefully just doing configuration customisations. This is potentially neater and protects product development time but there’s also a potential problem with product consistency; if we’re just randomly slamming stuff into the product you may end up in a poor state. This needs governance, or maybe even multiple installations of products on different tenants. Both of these could be problematic. Also, if you don’t have enough work for this team, you could be paying for people to sit around doing not much (which your CFO will dislike at the very least!)
A potentially great option, if it’s more about bespoke integrations and client customisation, is to strike up a relationship with an integration partner. They get trained (and maybe certified) in your stuff and then they can go out and do all the shovelling for you! You at least get the recurring licence money, as well as potentially a revenue share or certification fee. I like this as an idea as it protects the product development team and keeps you from having to entertain ideas that you just don’t want to do.
Whatever you do, you need to track the success of these “initiatives”. Did you actually win the sale? What other stuff didn’t happen? How did that impact product health? What happened to retention or satisfaction or any other metrics that you care about? You need to represent the true cost of custom work and make the impact clear to non-product development stakeholders. Very few leaders want their teams to make deliberately bad products — but you need to step away from the soapbox and get real with leadership in terms that resonate with them.
You haven’t failed if you have to do this
Remember — things like this happen in B2B product management all the time. You haven’t failed because you had to do custom work every once in a while. Maybe the market dynamics are against you. Maybe your revenue concentration is out of whack. Maybe you just missed something in discovery (or maybe your discovery was just “whatever our first clients asked for”). These are all fixable but fixing them takes time. Try to make incremental improvements, do what you can, and don’t stress the outliers.
That's all folks!
Thanks for reading. Hopefully this has been helpful or at least entertaining. Please share with any product management friends or frenemies, and I'll be back soon with more hot takes and barely considered advice. Ciao for now!