Decoding Careers: the art of saying No by saying Yes.

A big challenge for the modern product manager is today creating roadmaps together with the development team and at the same time staying out of commitments to features that are not compatible with the vision of the product. How do you do that? How do you say to a customer that a feature they are requesting is not relevant or how do you say that the feature they want is valid but the way they want into your product is not the way that fit the product vision? Even worse, what if your own management team asks you to build something you believe it is not relevant to the product? Essentially, how do you say No by saying Yes?

The very first important point is that as a product manager you are expected to be the spider in the web, i.e. you should be on top of all situations. You cannot be surprised by getting a call from someone in sales or from an executive saying: “We have committed feature A, B, and C by that date. Good luck and make it happen!”. That is too late. If you get involved in the decision process you can always influence to your advantage. I am aware that there are situations where you cannot say No, but influencing the decisions is key. Maybe you have to commit to a feature, but you can influence the delivery date or you can request additional investments for your product line, which would be very beneficial.

Secondly, the biggest mistake product managers or management do, in general, is to release 3-5 years roadmaps: this is so anachronistic, it does not fit the modern times of software engineering anymore. Instead, there is a window or I call it “an outlook” of 6-12 months and the rest is a vision which is flexible to change based on insights at that time. Nobody can predict what will happen in three years. You just need to watch and be flexible to adapt. But there is something that can help the product manager today and that is the agile development methodology that engineering teams are more and more adopting. While some pretend to do, the true agile methodology allows every time the planning of a feature set by relooking at the backlog and change the priorities based on incoming requests. A product manager has today that flexibility which in the past it was not possible with the classical waterfall methodology where the development kitchen was closed for a year or so baking some releases. With a caveat: with the introduction of single-code base products in the enterprise software world, there is no customer-specific version anymore. And there is no “build this feature on my version”. While in the B2C is widely accepted (see App stores), in the B2B lots of CIOs lives in the traditional “custom” world.

I would like to give some guidelines how to get the best negotiation points:

1. If a customer or prospect asks you to build something that is not relevant, I would politely explain why you think the feature is not important and how their business problem can be solved in a different way. Many people and enterprises have worked in a certain way for years and while the world is moving on, people still want to work in the same way. It is time to move on and the product manager should explain it and sell it;
2. If it is something valid and missing in your product line, then it’s all about negotiating;
3. Never ever commit a feature without involving your development team. You always have a wild card to play that you need to consult your development team. And you should! You need help to identify the what, how, architecture, timing, etc. Also, while the feature is being figured out by different people, this period allows the product manager to take time and influence the scope to his/her convenience. Time to reflect and find opportunities to slightly change things is key;
4. As soon as the feature has been defined and agreed, decompose it in different iterations to fit the agile model. Lock the iterations and get a sign off of the customer. Any deviation will change the plan and dates. Many customers may get late insights and will come with a lot of change requests, all need to be managed. The sad part that not many people realizes is that roadmaps managed by “who you talk that day” are the worst thing that can happen to a product;
5. Allocate time to develop the committed feature, but never ever allocate your entire capacity to that feature. You need room to build other functionalities and serve other customers too. A product needs to move for multiple customers, not just for one.  If you don’t, you are building a custom product for one customer;

Massimo