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 internal or external customers of a software application, change your “unit of analysis” from feature to problem statement.
Here’s an example that illustrates why this distinction is so important.
Imagine that you are the product manager for a SaaS product used by employees to submit expense reports. A popular request from users is a photo import for physical receipts so that amount spent doesn’t need to be entered manually.
The feature has an obvious potential to deliver value by reducing the amount of time submitting expenses, but reducing time spent on the task is not the only objective employees have. Suppose that due to technical constraints the photo import only produces an accurate report of expenses 50% of the time. In half the cases, it captures the wrong value for the expense, causing delays in reimbursement when the total from the actual receipts doesn’t match the total calculated by the app.
The employees’ desired outcomes are:
- Minimize the time spent submitting expense reports.
- Ensure expense reports are accurate to prevent delays in reimbursement.
With these two desired outcomes in mind, your problem statement (described in the form of a key question) becomes, How can we minimize the time employees spend submitting expense reports while ensuring the reports are accurate to prevent delays in reimbursement?
A potential solution given the existing technical constraint could be to add an additional step during photo import:
- User takes a photo of the receipt.
- Application asks the user to validate the amount the application extracted from the receipt, correcting the value if the system interpreted it incorrectly.
Now, one could argue that this is just a matter of improving the design of the “photo import” feature by adding an extra step to ensure accuracy. But if you keep your analysis at feature level, you could still be failing to solve the real problem for users. Compare the two situations here:
- Analysis at feature level: An usability test is performed for “Photo import” with the amount validation step to take care of the accuracy issue. All goes well, and the feature is prioritized for the next release.
- Analysis at problem statement level: A comparison test is performed between “Photo import” with the validation step and current state of users having to enter the value of each receipt manually. Photo + validation turns out to take more time than manual entry of receipt. Based on the problem statement How do we minimize the time employees spend submitting expense reports while ensuring the reports are accurate to prevent delays in reimbursement?, the decision is to leave the “photo import” feature out of scope for now, and investigate other options (including new technologies) to address the stated problem.
Value is delivered when actors achieve a desired outcome, not when features become available to them.
Here’s another example — 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 continue to deliver value to users with the purpose 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 a few clicks and make the upload process faster and more delightful.
- Analysis at feature level: An 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 upload service, as a faster and more delightful method for image upload is not going to convince non-users to adopt the content management tool.
KEY TAKEAWAY
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. I like to describe value using three dimensions:
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.
See below how apply this framework to our two examples.
Example #1
Application: Expense report
Who is it for: Employees who need to be reimbursed for a business expense.
- Service: Submit expense reports.
- Barriers to success: Inaccurate reporting gets in the way of timely reimbursement.
- Desired outcomes: Minimize time to report expenses, maximize accuracy of reports.
The ultimate goal is to deliver the desired outcomes. In order to achieve this ultimate goal, the service needs to be performed, and the barriers to success must be removed. Unless we can validate that “photo import” feature contributes to the end goal, it doesn’t deserve to be prioritized.
Example #2
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.
- Barriers 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.
- Desired outcomes: Minimize effort to publish content to blogs and social media while preventing content fatigue.
In order to achieve the desired outcome, not only the service needs to be performed, but the barriers to success must be removed. Features that continue to improve the service dimension, like the improved widget to upload images and videos would not be prioritized here until the barriers to success have been removed.
Related: