Having joined an in-progress Release with work related to a feature request from a single (but high-valued) customer, I decided to scale back the implementation and promotion of the team’s work.
The 1-off customer request is a familiar challenge for Product Managers. It often appears in tough times, like when the Sales team hits a rough patch and starts to relax the deal qualification criteria a bit. Or when the company's Customer Support team is at the end of their rope trying to rescue an unhappy customer. My predecessor had saddled me, in my new PM role, with the latter. When I stepped in, Engineering had already begun development on a feature request intended to satisfy a single customer in peril.
What drove this decision
As a rule, I don't release software to my customers that I haven't first validated with a set of sample users. And while I appreciate that a business needs to listen and respond to its customers, when I hear “we need to do xyz because this (big) customer needs it”, alarm bells go off in my head. As Product Managers, we know better than to respond with some hasty enhancement - especially if we know only one customer is likely to need or use it.
So when I sat down with the Developers to review this request, I realized that we were about to build (and later release!) some terrible software. It was fairly obvious that we had cut almost every corner to get it done quickly. We did not have sufficient insight into how we could properly address what was likely a more recurring customer issue. What was currently scoped was only narrowly solving this particular customer's current pain and on top of that, they had given the new feature a misleading name that would have created even more challenges down the road.
The decision: Restrict the new, hastily built feature
In a single ruling, I effectively downgraded the feature for the current release and postponed its full arrival indefinitely pending additional customer input.
Rather than disappoint our customer by pulling the feature entirely, I re-scoped the development work to produce an adequate but scaled-down solution. Through subsequent testing, we confirmed that this indeed satisfied our customer's pain. But perhaps more importantly, we found a clean way to deploy the software so that it would NOT be accessible to any of our other customers.
Actually it took a few more steps to get us back on track.
Plan of attack
As I mentioned earlier, this train had already left the station. I was joining the project mid-stream so I needed a way to unwind some of the activity that was already in motion.
Limited feature preview
Our company regularly shares the ongoing engineering progress with a larger audience. In order to limit exposure, I chose to pull the feature from any and all company-wide previews. Instead, we invited only our internal Account Reps who work directly with the customer to preview and validate the work. And with their approval, we moved forward with the customer who ultimately gave us a thumbs up and who completely understood our decision to pause any additional work until we could do more discovery around the greater problem.
Schedule additional discovery
Realizing that the team could use more time to research this feature with other customers, I assigned a Product Manager to work with our Customer Success team to identify other customers with similar needs. Having addressed the immediate pain of this first and only customer, we could now proceed with proper requirements gathering and look to build the product feature correctly.
Bury the feature in the official Release
And finally, so that I could hide this premature feature from our other customers and even from our Marketing and Sales teams, I concealed the feature by leaving it out of the external facing Release Notes.
The outcome of this decision was favorable to all. We had effectively addressed a real pain for this customer - even if they were currently the only one who seemed so far to have the problem. Our Customer Support team who had prompted the work was... not unhappy and now had some homework to do to find more pain in the customer base. And the Engineering team, who tends to favor intentional and rational decisions, was pleased, if not impressed.
Look for more reports from theProductPath around feature scoping and the need for customer research here on PM Decisions.