Product management has often been considered as “requirements gathering.”
In the 1980s and 90s, most organizations got custom software applications developed to automate their business processes (this was before IT products started to gain traction in the late 1990s and early 2000s.)
It was assumed that the client organization has done adequate research to identify the customer pain points.
A key role that the business analyst played in this environment was to document these requirements, and act as a facilitator translating the requirements from the customer and conveying it to the developers. In this environment, the business analyst was responsible for managing the scope and the project manager was responsible for the schedule and costs.
However, in an IT products scenario, if you were to interview all your current customers and internal stakeholders, get a bucket list of features, and build a product - it wouldn’t necesarily lead to product success in the marketplace.
This boils down to the fundamental differences between IT products and Services companies.
How is the world of IT products different from that of IT Services?
The IT product world is different from IT services for these reasons:
You are not building the product for one user or one customer.
Every user or customer has a slightly different interpretation for the same “requirement.”
Many organizations and users won’t have clarity about what they really want and why they want it.
I’ve come across several situations where stakeholders approach product managers to build a product using their list of requirements.
Take a look at this real-world example and how I solved it:
A senior stakeholder in a B2B SaaS client (which offers a platform for online coaching centers to stream videos) approached us with a request that one of their top customers needs identity validation using www.UIDAI.org for all their students! We asked our favorite question “Why do they want it?” Turns out they faced video piracy issues with some students downloading and distributing videos of the conducted classes. Instead of identity validation which would have helped sue students who downloaded and sold videos, we implemented digital rights management, which prevents the download of videos. This happened to be the best possible solution in this situation.
In that context:
What is the Role of a Product Manager (If It’s Not Requirements Gathering?)
An ideal product manager has to understand the problems faced by the end user, and their unmet needs rather than collect “requirements.”
A product manager has to:
1. Clearly understand the problem that the user or customer faces. It is critical to get a well-rounded perspective of the problem by conducting user and market research to understand the users problem, and asking the right questions.
Some of the questions a product manager should ask are:
Are there financial implications?
Is it just an irritant?
What do the users gain if we solve this problem?
What do they lose if we don’t solve this problem?
What’s in it for us if we solve this problem?
And what do we lose if we don’t solve it?
The product manager can also get powerful insights from actual customer behaviour analytics to arrive at the customer’s problem.
2. Once this process of discovery is done, the product manager should have:
Brought all stakeholders to the same page and set the right expectations.
Added context to what each feature is for, and what problem it solves. It shouldn't be too instructive or prescriptive that it stifles design freedom.
3. Determine the critical success factors for solution evaluation.
4. Get feedback from different stakeholders to come up with various solutions and evaluate these against the defined success factors. The solution expectations from different stakeholders would be different. For example, your tech team might be thinking of a solution that is impractical to build. There may also be several conflicting requirements from different teams.
5. The product manager should then prioritize requirements to eliminate wasteful processes and deliver value in the quickest way possible. These requirements should fit the vision and strategy for the product.
6. Once all of this is done, the product manager needs to work with the product development team to define the requirements.
The product manager explains the problem to the development team, gets them to empathize with the user, go through the proposed solution at a high level, and work with the team to create the user stories.
The solution is jointly owned by the team and product manager.
In a gist, the product manager should be able to collaborate with various stakeholders, analyze the true problems of the users, and prioritize the requirements. The technology team should then come up with the optimal technical solutions which may be discussed with the product manager in case there are tradeoffs to be made.
In other words, Product Managers should be, like Marty Cagan said, operating at the intersection of users, technology and business.
Goes way beyond merely gathering requirements, right? So, by considering product managers as requirement gatherers your organization would be missing out on the opportunity to leverage their skills and inadvertently hampering product success.
Now, if your organization wants to streamline it’s product management and delivery organisation ...