One of the mistakes I see repeated over and over by product managers, product owners, and business analysts, is using features as their “unit of analysis”.
It doesn’t help that books and online resources reinforce this notion all the time:
If the focus of your work is to define and prioritize features, chances are you’re missing huge opportunities to address important and underserved needs for your internal or external customers.
To increase the value you deliver to direct or indirect users of a software application, change your “unit of analysis” from feature to problem statement.
Here’s an example from a content management tool used by marketers to store and publish content to blogs and social media.
The product team is looking for opportunities to improve the quality of the product with the goal of increasing user adoption. It plots an “importance and satisfaction” graph and identifies an opportunity to improve the widget used to upload images and videos to the content management tool that will save users some clicks and make the upload process faster and more delightful.
- Analysis at feature level: A usability test is performed for the new upload widget. All goes well, and the feature is prioritized for the next release.
- Analysis at problem statement level: By performing “problem interviews”, the product manager identifies an obstacle that is preventing more users from adopting the tool: marketers can’t see the number of times a piece of content has been published, and prefer to use their own spreadsheet to keep track of when/where content was published so they can avoid content fatigue. Until this barrier to product adoption is overcome, there’s little point in continuing to improve the service dimension, as a faster and more delightful method to upload images is not going to convince non-users to adopt the content management tool.
When you shift from feature to problem statement as your unit of analysis, you develop a more holistic view of value and increase the odds of delivering a product that people want to use. One useful way to arrive at a valid problem statement is to use the following framework:
Service: The work the application does or help users do.
Barriers to success: The circumstances or obstacles that prevent the service from being successfully delivered or the application from being adopted by its intended audience.
Desired outcomes: The measures of performance that customers use to judge its value and are inherent to the execution of the service.
Here’s the framework applied to our case study:
Application: Content Management tool
Who is it for: Marketers publishing content to blogs and social media
- Service: Store text, images and video, and publish content to blogs and social media.
- Barrier to success: Lack of visibility into how many times a piece of content was already been used and when causes marketers to prefer the use of a spreadsheet to keep track of their content in order to avoid the risk of content fatigue.
- Desired outcome: Minimize effort to publish content to blogs and social media while preventing content fatigue.
Problem statement (in the format of a key question): How can we remove the barriers keeping marketers from using our content management tool in order to increase user adoption?
Given that the new file upload widget would merely help improve the service dimension without supporting the achievement of the desired outcome, it would not be prioritized until the barrier to success was removed. A capability that may not have been requested by users yet–a counter of how many times a piece of content had already been used, and in which channel–, would be given a higher priority because of its higher potential to produce the desired outcomes for the customer and the business.
This kind of analysis can be applied to all sorts of software initiatives, from small enhancements to entirely new products. By shifting your attention away from prioritizing individual features and concentrating instead on solving a problem end-to-end for a group of users with the customers’ and business’ desired outcomes in mind, product teams can pave the way for the evolution of their product toward much higher levels of customer satisfaction and value delivery.
You may also like:
Stop prioritizing features