Many years ago, I was assigned a project where I was to meet my fourth client in my career as a Business Analyst (BA). I was brimming with confidence as a young BA with the experience from the previous three projects.
I was to meet a senior executive from the client team to gather requirements for a new application they wanted my team to build. Armed with enthusiasm and good spirits, I reached the client’s office well before time and prepared myself for the session. There were no presentations from my end, since the plan was to interview the client team, discuss their business requirement and take notes.
After a few minutes, the team members from the client started walking in one by one. Finally, the big boss himself arrived. We went through the process of initial introductions. Soon after that, the senior executive asked one of his team members to showcase a presentation about the business plan so that I was aware of the context.
The team member opened her laptop and switched on the projector to display the presentation on to the big screen in the meeting room. The projector got powered on, the familiar blue screen was displayed on the screen. But how much ever she tried, the presentation failed to load on to the screen. The screen seemed to be silently screaming in blue!
A few moments went by. The blue screen seemed to stare at all of us with nothing getting displayed. I could sense everyone getting impatient in the room, especially the boss. A couple of minutes later came a statement that redefined my concepts of working in IT. He said, ‘You are in IT, you must be able to fix the projector!’
Whether the senior executive truly meant that statement or not, that was my first of many experiences, with some of the clients I had worked with since then, about how ill-informed can people be about the roles and responsibilities of folks who worked in the vast world of Information Technology. For many, just like the boss in the above incident, a Business Analyst and a Hardware expert who could fix issues with a projector were both from IT and hence they can both do the job irrespective of their specialisation.
A decade later, as the world moved from Waterfall to Agile ways of working, I could see similar arguments manifested in a different manner. When I met clients in the capacity of a Product Manager, one of the biggest challenges I faced was on the boundaries defined for the Product I owned. This was especially true from operational teams for whom, dilution of the nature of Product was never really a problem. Their sole objective seemed to be addressing a business problem through the Product, irrespective of whether it really was a part of the core capability of the Product.
There were multiple instances where clients had asked for features that rightly belonged to another Product to be brought into the one, I handled. It required a great deal of persuasion and at times even helping them see how logically the ask was a misfit helped in bringing back the conversations on track. If it was not for the pushback, what would have guaranteed were multiple Products in the organization with capabilities getting duplicated. Unfortunately, this remains a sad reality in many companies.
The Big Question: Is there a way to avoid this situation? While there is not a simple and straight forward answer, I will still say, we need to have a Push & Pull Strategy that needs to be applied here. We need Product Managers to be clearly aware of the bigger picture with respect to their Product. They really need to know their Product in-depth and realize exactly when the boundaries are threatened to be crossed. It is also important to have a high-level understanding of related Products and how they are designed to have a logical discussion and convincing a client on why it is important not to dilute your Product with a feature that really did not belong.
Equally important is the fact that clients need to be educated to ‘Think Product’. This is not a one-time effort. It will always be a battle between Operational Convenience Vs Product Strategy.
Do not get disheartened. The good news is, most of the clients we from Product world must deal with, are logical in nature and they understand if presented with meaningful and logical reasons. That alone is the way to sustain a better way of working with Products and avoid costly overlaps which otherwise will result in a phenomenon called ‘Product Overhead’ which unfortunately remains largely undetected, especially if it is an organization with hundreds of Products.
So, next time when someone asks you for a feature to be added, first ask yourself this question and then challenge your client. Does this feature really belong to the Product and adds value to the client? More importantly do we avoid overlaps with other Products thereby making the Product landscape of the organization more streamlined and better managed.
Cheers to all sensible Product managers out there as well as rational clients who understand the reason when you challenge the requirement to add a new feature!
