Product Managers need to help stakeholders define the problems as opposed to solutions

As a Product Manager I’m responsible for ensuring that stakeholders express their requests in terms of  business problems as opposed to a pet feature, so that their real needs are met  and do not get lost sight of when backlog items are aggregated into common themes as the product team figure out the best solution.

Albert Einstein said “If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it,”

Product Managers tend to spend a lot of time listening to internal stakeholder requests, from the business, as well as external stakeholders, customers and users. Ultimately product development needs to be driven by data: we know, from experience, that data beats opinions.   

Like all Product Managers I’ve experienced receiving pet feature requests from both external and internal sources.

I’ve had external requests usually via the sales team for a customer special e.g.:

“If you add an additional ad format then I’ll sponsor a channel”

and from internal stakeholder:

    “I want to display nonstandard content in the playlist player”

With respect to the internal requests the Product Manager needs to be able to help stakeholders express their requests in such a way that the underlying problem/user need is articulated as opposed to a solution/ per feature request.

This is how I helped one stakeholder change from a mind-set of requesting a list of pet features to identifying a list of business problems and user needs.  

• Prepare the way:  Before I’d received any requests I spent time understanding the stakeholder.  I discussed, in an informal way (e.g. at the cooler fountain etc…) what their aims and objectives were for the year, what challenges they faced, what their past experiences were.  In this instance the stakeholder was the web-editor and they were tasked with building audience and increasing traffic to the site.  I would use a slightly different approach for a more senior stakeholder but still prepare the way as early as possible. 

• Explain the problems with submitting a list of pet features as opposed to identifying the problem.  I explained to the web editor (who happened to be a new hire) that there was a constant stream of requests from several sources. Therefore their feature requests would most likely get lost when the product team worked on combining individual problems, on the product backlog, into common themes ready for a resolution. 

•  Set the context of their input- I explained that a feature fulfills a need and problem for the user.  We need to identify the users needs if we want to solve the right problems. I did this by quickly sketching out the ‘needs, feature, requirements’ pyramid.  

• Assist in re-framing each request.  I discussed each request in light of the web editors overall goal and helped him re-frame each one as a problem/user need, as opposed to a pet feature cum solution. I did this by using the card part of the user story:  “As a I so that .” After a few iterations we finally got there – there was a realisation that it would take a change in mind set. I then went on to explain that we were working at the Epic level which is akin to an individual scene in a film – as opposed to writing out the individual lines each actor would say in a particular scene.  

• Demonstrate the cases in point:  We eventually reversed engineered the list of feature requests into a list of business problems. I then picked a few problems and quickly sketched out 2 to 3 possible solutions to the defined business problem.  I did this, in a humble way, in order to illustrate the point that there are many solutions to any given problem and that the product team would come up with the final solution based upon aggregated problems (the big picture) as opposed to an individual problem (an isolated instance).   I also stressed the importance developing the product in such a way that the user has a consistent experience which would only be achieved if development was done with the big picture in mind at all times.  Which is the job of the product team.  

Once the requests were properly re-framed they were entered onto the backlog ready for prioritisation. See blog post: Process for Prioritising the Product Backlog

It goes without saying that different stakeholders will need to be managed differently: depending on their pay scale, personality and knowledge of product development. 

Hopefully this blog post will serve as a catalyst to help you think how to best go about changing the mind-set of the stakeholders in your organisation.