Imagine this: You are developing a new product feature, requested by one of your company’s most important customers. After nearly a fortnight of work, you’ve almost finished the work – a couple more days and it will be ready for release. This morning your manager asked you to temporarily drop that work so that you can urgently work on a different feature, for a different customer.
When you look at your git branch history, you see that this is the fifth time you’ve put work aside to complete later in the last six months. Worse, you’ve never returned to any of those feature branches – so the very urgent feature work you were doing 5 months ago has never been completed, let alone released. Maybe that feature wasn’t so important anyway, it was for a customer who isn’t a customer anymore.
Complaint Driven Development is when your product roadmap is controlled by “which customer is complaining the loudest” instead of by a specific plan for how you’re going to develop and improve the product.
Very Important Customers occupy a very particular place in the life of any product.
On the one hand, you absolutely need to land a few large customers to validate the product you’re developing, and to bring in enough income for the company (or the product group) to survive.
But on the other hand, the demands of these customers can sometimes be extreme. They know full well that their business is far more important to you than it is to them – and they’ll use that as a lever to get the things they need at your expense.
If the things they’re demanding fit in with your product roadmap, then all is well – if a bit more stressful than you’d like. But all too often, the demands will be for very particular features that won’t really be very much use for other customers, or even for changes that will negatively impact the product by making it confusing for other users.
Maybe you’re building an ecommerce website toolkit, aimed at allowing small businesses to move quickly and easily to selling their goods and services online – and your major customer is insisting on an SAP integration.
Or, maybe you’re building the next big turn-by-turn navigation mobile app, smart enough to recognize traffic congestion faster so that you can redirect your users to alternative routes before they become congested as well – and you’ve been approached by a major fast-food retailer who wants your app to route drivers past their restaurants and to suggest taking a break when traffic is delayed.
The balancing act is to work out what you’re willing to do to keep these major customers happy enough that they stay as paying customers, but without ceding too much control over your product roadmap.
If you do agree to build a feature for a specific customer, you need to ensure you deliver on the promise. Fail on that and the customer will be more unhappy (and more likely to leave) than if you said “No” up front.
Where possible, build generic features that enhance the product for all stakeholders, instead of something custom for one situation.
For example, …
Instead of an SAP integration, implement an industry standard interface that allows any of your customers to integrate your ecommerce product with their back-end system, regardless of the vendor. Bonus points if the interface you adopt has native SAP support.
Provide your users with multiple options for reroutes and places to take a break by building a way to integrate with multiple places of interests – not just fast-food restaurants, but local tourist destinations, places to park, and children’s playgrounds as well. Keep your users happy by using opt-in, increase your bottom line by allowing multiple advertisers to pay for listings, and built community engagement by bringing tourists into town instead of routing them around it.
I think you get the idea.
Your important customers will naturally request features that make their life easier, not yours. Find the balance point where you can keep them happy while still building features that improve your product and attract other customers as well.