One of the significant challenges that project managers experience, especially in product-based projects, is the (usually large) gap between what was promised to the customer at the sales stage, and reality.
The tendency to beautify things at this point, coupled with the fact that we don't really go into the details of each feature (and we know God is in the details), causes the customer to mark "V" for capabilities that later turn out, to say the least, inaccurate.
This gap is usually revealed in what is also known as the end of the honeymoon, the stage of discovery or scoping (the stage in which the processes are characterized in detail),
And somehow even though it's a pretty common dynamic, everyone's surprised.
The customer, because he thought things are working one way and discovered that they work completely differently,
The development teams are surprised by the customer's surprise,
And the project manager from the fact that it's happening again, and we learned nothing.
The dilemma is not simple. On the one hand, it is impossible to continue to maintain the gap, this is the stage where the customer needs to know exactly what he is getting, On the other hand, it is impossible to withdrew blatantly from things that have been presented or said, and it is impossible to cause the customer too much disappointment.
Anyone who has led a B2B product-based project knows exactly what I'm talking about.
Many product companies, have learned to integrate the project managers or development teams in the sales stages, And it does minimize the problem but does not completely solve it, again mainly because of the level of details to which it goes down.
So what should project managers do?
First of all, the expectation of most companies is that the project manager will represent the product and will continue to sell it even during the implementation stages, that is, he will not expose the gaps as gaps. (This is not a bug, this is a feature ...)
At the same time, in my experience it actually works better when the project manager represents the customer side. Of course in a logical and balanced way, but if the project manager “takes the side” of the product’s advocacy, the customer feels misunderstood, not represented, and the sense of gap grows.
When the project manager takes the customer's side (again - to a logical limit), identifies with him, and represents him within the company, the customer will at least feel that there is someone who understands him and fights for him. The gap will narrow.
Another thing that helps is to know within the company which gaps are critical - and they strive to find solutions whether they are through product development or another way, and gaps that are less critical and with which, even though he thought otherwise, the customer could live.
Of course the bigger the gap, the more complex it is to manage, But yes, the project manager needs to know how to manage the gap, and engage the groups internally in the company to reduce it.
Sales people after all will always be sales people, and delivery people will always have to manage reality.
It reminds me of a funny story about meeting with a customer I participated in a few years ago. The CEO of the company I worked for invited the customer to visit our offices and told him how stunning the offices are, right on the beach, with an amazing view of the sea. The company's chief architect who was also at the meeting immediately jumped in and corrected it - a wide and busy road separates the beach from the office, the building is old, and the windows are really small so the view is very partial.
The customer laughed and said - And that sums up the difference between a salesperson, and an architect