Are you talking to the right stakeholders?

We were way off. It started by hearing a customer requirement from an internal stakeholder. The customer was apparently pissed and threatening to leave for a competitor. They spent over $100k monthly and were trending higher– but if we didn’t get our act together and produce what they needed, we could kiss that revenue goodbye.

The internal stakeholder – owning both the relationship with the customer and the P&L for their product line was frustrated. Three meetings into the week, we were back at square one.  This should have been an easy request. The meetings grew in size as we tried to determine the overall impact & cost to produce the solution.

Why? Many legacy systems would be impacted to get the desired experience. Roadmap items would have to be shifted, with a reset of expectations across many other customers. The quick and dirty experience agreed to had a caveat of “we must do the long-term solution as soon as we can after launch”. The short-term would work for one product line but not another. We would scrape by on compliance requirements this year, but extra effort would need to be expended to pass next years. It was a large cost, anyway you look at it.

And with little bang. Until the internal stakeholder brought us more customers asking for the same thing. Revenue at risk went up.

Fire-drill. We had to execute on the short-term. Two and half months and a mountain of technical debt later, we delivered a saving catch. We were heroes. Saved the company and there should a parade for us, right?

Upon delivery, the internal stakeholder presented us with another critical priority to save the same customers.

So where did we go wrong?

1. We were talking with the wrong stakeholder. Throughout this time, the customer expectation was that their exact request was “coming soon”. The 2-3 items that would’ve delighted the same customer in the 2.5 month time period were pushed out on the roadmap and not part of the conversation. The gaps in product-line coverage were also not part of the conversation.
2. So why didn’t the customers leave? The internal stakeholder did not understand the voice of the customer. Perhaps there was an unfounded fear of churn that should’ve been vetted, or perhaps politics were at play between two very different orgs to see who would jump the highest. Or perhaps the pain-of-the-day subsided with the customer through a work-around and they moved on. In any case, forming a relationship with the high-profile customer would’ve produced clear, vetted requirements and valuation.
3. The delivery teams went into defensive mode. “Why does it take 2.5 mos to deliver something simple?” “Why can’t we do xyz instead?”. These are great questions for teams to answer, in a comfortable setting without the overbearing frustration of the internal stakeholder present. Design sessions should be shielded from the fires of the day, otherwise you’d only be solving for the fire… without seeing the arsonist. “Let us hash this out and we’ll get back to you tomorrow” was the answer we should’ve given.

The next time around with the internal stakeholder, we took a different approach. We became customer-centered and formed relationships with the most revenue-generating customers. We became data-driven – determining what value the features really brought and if it was worth the cost of the trade-off.

It isn’t features that will retain customers… although those help. It is the service and support you show – even as a product manager. Roadmap reviews, a deep look into what is being built, betas, and detailed RCAs – all of those build trust.