Last week Rich, the product manager of a B2B enterprise product, had finished the release planning of the 1.0 version of the brand new product line that he was managing. The release of the product was two quarters away and this week he was busy interacting with the engineering team on the finer details of the interaction design since the first iteration had just been kicked off. Rich was in general happy that content for the first release was more or less firmed up after a series of research on the competitive landscape, customer needs, technology evolutions and others.
Rich reported to Sunita, Director of Product Management and they had good working relationship. On Thursday when Rich was about to leave for the day, Sunita came over to his office and asked him if they can meet on something urgent. Sunita said the company was about to sign a contract with a huge customer who committed revenues for 2 years if the new product was delivered with the specified content and timeline. That was really music to Rich’s ears and he asked for a copy of the contract to see the specifics. Rich left for home and started skimming through the contract that Sunita bounced him by email. As he read the finer details of the contract, Rich was a worried man.
Most details of the contract had dictated for features that were custom features applicable only to that particular customer and hence orthogonal to the goals of the new product that he was working on. He called Sunita and spoke to her at length about this. He insisted that, this appears to be a different product by itself. Sunita said that the customer is dangling the carrot in terms of the huge contract and there is no possibility of us not taking it up. She insisted that it is very encouraging to see a customer who is ready to commit even before the first line of code has been written and after-all any product has to evolve and this could well be the evolution. Rich was upset because:
- One customer was hijacking the roadmap of the product to suit one particular need which does not align with the original goal of the product
- The USP (or core value) of the product gets diluted as short-term benefits seems to take precedence over the long term goals
- An iterative way to develop the Minimum Viable Product gets derailed as one would build as per the contract and not as per the user story/requirement
What choices does Rich (and Sunita?) have when a product roadmap gets hijacked in such a fashion:
- Build the custom features around the main features of the product as something that gets exposed only to this particular customer. Taking this approach means the product becomes heavy with lot of features custom built for one customer and the associated huge nightmare as inheriting a feature, as explained rightly in getting real is like adopting a child.
- Candidly explain to the senior management that we must believe in our original roadmap and not to fall for something like this; that is simply do not sign up this customer under the present terms. If the company sees definite revenue and is not cash rich it is very likely that this option would be shot down instantaneously
- Explain to the senior management that this contract cannot be for the product that is being worked on. It should be considered a off-shoot of this product as a custom professional services and rework the contract with the customer that the maintenance of the software would be at the customer’s cost. This option looks more of a win-win situation wherein the roadmap is more or less saved from being mauled and at the same time the company wins the contract (albeit with modifications).
What according to you could Rich have done to salvage such a situation where the roadmap is almost getting hijacked?
The Product Mantra 
This is a classic case of confusing customer requirements with product requirements.
It is a very common scenario, where product managers have to hand out specials to
customers who are willing to pay lots of cash.
In order to get this right, Rich will have to work with senior management and clearly indicate
this does not fit in with the vision of the product and is not in the best interest of the product.
I also think as a product manager Rich has the responisbility to work with the customer to
understand the real problem and offer them another solution, which might be even better.
Rich can also consider if it will add value to make the product extensible i.e customers/solution providers can write custom code to extend the product.
Thanks Annu for your comment. I really like your view that Rich must work with the customer to understand the real problem rather than opposing it in the guise of not falling in-line with product goals. Making it extensible is also a good idea if there are more prospects.