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. 
 

Read More

Process for Prioritising the Product Backlog

I’ve spent the past year bringing a new product to market, as a consultant Head of Product for a start-up business unit that’s owned by a multi-national. I had the opportunity to pretty much start at the beginning: pulling together the vision, setting up a product council/steering group, talking to users about the initial concepts and shape the overall product direction.

After launching V1 of the product I ran a number of prioritisation meetings with key business stakeholders.

I’ve chaired and been involved in many different types of prioritisation meetings before. Somewhere there were up to 12 frustrated web editors (who managed sites where advertising was the major revenue stream) all had to bid for a slice of the scarce development resource. Prioritisation was done purely based on revenue: those sites whose demand for inventory was higher than what they were supplying won out.

Other prioritisation meetings comprised of me (the product manager) having to present and persuade senior stakeholders of the validity of a pre-prioritised backlog and drive consensus.

 Recently I decided to use the following process to not only prioritise the backlog but to aid in building unity among a group of stakeholders and win their confidence and trust:

1. We agreed on the goal for the next quarter – in this case it was to build our user base as opposed to driving revenue. A hard sell for an ad funded business. 
2. We went through the backlog and as a group agreed on the category of every item: User engagement, revenue, contractual, audience, acquisition etc... Most where no-brainers,  but the key was that the group felt that it had categorised the backlog. 
3. By common consent a champion was assigned to represent each backlog item (represented in the meeting was: Heads of Marketing, Ad Operations, Head of Product, Tech Team Lead and the MD/General Manager of the business unit). 
4. The champion would then give an elevator pitch on the importance of their backlog item followed by a brief Q&A cum discussion. 
5. We would then vote (in the same way you play poker in scrum) on how the item would best fulfill the goal we all agreed on. Each score is then entered into the spread sheet. 
6. When we get to the end of the backlog click ‘sort’ and hey presto we have a prioritised backlog.

Everyone embraces the outcome because: they participated, there was total transparency and we all bought into the goal for the coming quarter.

Finally I would present the prioritised backlog to the product council/steering group – in general it’s well accepted because either those present participated in its prioritisation or one of their subordinates was involved and reported back to them.

The quality of the prioritisation is directly related to the product manager’s ability to keep everyone on track, focused on the agreed goal as you vote on each backlog item.

Read More