At Stride Consulting, we define the capabilities we expect of our product managers (PMs) and call out one of the jobs of the PM as Translate Value to Work. What does that mean?
We list a number of behaviors that we would like to see our PMs exhibiting:
- Collaborates with the team to define work and align the work to value (e.g., product backlog, engagement map).
- Regularly shares insights around user and business value with the team through ceremonies and artifacts.
- Traces the impact of individual items of work back to the product vision for the team, and champions the “why.”
- Enables team to understand how individual work items achieve desired outcomes (e.g., acceptance criteria, gherkins formatted)
While these behaviors are good indicators that one is performing this project-critical function, I prefer to define it in these three phases:
- Defining value
- Translating value into work
- Mapping work back to value
Defining value
Defining value starts with the work of helping the client to articulate the value that they imagine this product will provide. This step can be divided into the search to uncover user value and the identification of business value.
User value
As product managers, we are trained to identify user value. With our partners in UX and Design, we drill down on feature concepts to isolate and align functionality to the actual value that a given feature will deliver to a particular user.
Through user interviews and personas, we identify different types of users and start to understand how their needs may be served by proposed product features. Through customer journey maps and other exercises (such as jobs to be done) we identify the scenarios that our users might find themselves in and which product features will help them achieve their desired outcomes.
Often, this phase is about bringing user needs and desires to the fore for our clients. They have an idea of who their potential users are, they know what they want to provide them, but they may not have thought through the pain points of their users or what really motivates them to use a product.
Sometimes, the client has all the right ideas, but they just need user input to understand how to prioritize them. There’s a big difference between the feature that your user thinks is cute versus the one that they can’t live without.
This work, whether done through rapid prototyping or competitor analysis, will help you and your client get more focused on the value that this product or feature will deliver to your potential users.
Business value
But you’re not done defining value there. While you need users to adopt your product, to love it enough to pay for it, and to tell their friends about it, you also need to understand the business well enough to ensure that the product satisfies the business’s needs.
This conversation is different from the user conversation and will likely boil down to one of two outcomes: either this product feature will make the company more money, or it will reduce cost or risk.
Opportunities to increase revenue can take on many forms. This feature could allow the company to charge more for its services, or it could increase the number of paying customers who are interested in it. It could help the company by expanding its offerings and enabling it to enter a new market. These benefits could accrue through designing the product to better serve its users, but your focus here is different; any benefits to the user will be incidental to the main goal of increasing revenue.
Decreasing costs and risk is another way that a product can benefit a company’s bottom line.
- Maybe the feature you’re building will reduce the number of calls to customer service and save the company money.
- Maybe you’re shoring up infrastructure that will make the product more secure or scalable.
- Maybe your client wants to build a prototype that will never be delivered to customers, but will unlock the doors to more funding.
All of these and a thousand of other ideas could represent the value that your product feature delivers to the business.
Weighing Values
It is critical to understand both types of value, because often they will need to be balanced against each other. Including that amazing feature that users love could push your delivery out by a month and cause you to miss making a big splash at that industry conference.
Maximizing revenue may impair the experience for some of your users. As PM, you’ll need to help your client weigh the costs and benefits of these choices. And you cannot do that unless you understand their value, both in real and relative terms.
Translating value to work
Which brings us to the translation part of the job. Once you’ve come to an agreement with the client on the values that are animating the project—the reasons this was greenlit and funded in the first place—you need to work with your team to determine how best to design and develop the product features.
Here, too, many tools abound. The agile PM skills of breaking ideas into units of work come into play here: identifying themes and epics, writing user stories, grooming stories with the team, and putting them in priority order. The critical relationship to preserve is between the work and the values identified with the client.
Every story that gets prioritized must be align-able to a product value that has been identified. And, more than that, these connections must be made clear to every member of the team.
- How do you know if you’re succeeding? When every team member, working on any user story, can explain why that task has been prioritized and how it relates to the overall goals of the project.
- How do you know you’re going off track? When you see long-lived stories with no visible progress, or difficulty in explaining the value of a story to the stakeholders in a demo, or low morale on the team.
One of the best drivers of a healthy, high-performing team is a clear understanding of the “why” behind the “what.” Members who understand their contribution to the overall value know how to direct their own work in the most effective way possible.
What’s the PM’s role in all this? Keeping the value and work tied together. They can do this as proxies for users or stakeholders, by bringing together stakeholders and the team at regular intervals, and by reminding everyone on a daily basis of the “why.” Individual designers or engineers on a project team are trying to solve the problem in front of them, and the PM can support them by connecting their work to the larger goal.
They also play a critical role in helping the team prioritize their tasks. By keeping the definitions of value ever present in people’s minds, the PM can act as a check that the highest-priority work is getting done first. Whether that’s heading off a lengthy exploration into a new technology or preventing a stakeholder from introducing new, nonessential features, the PM’s ownership of the value-to-work connection allows them to keep the team on track.
Continuously translating value to work
Inevitably, the time comes when the client wants to see tangible evidence of what they paid for. And this is when the PM needs to jump into the third mode: mapping work back to value.
On agile Scrum projects, the primary occasion for marking this delivery of value is in the iteration review or demo. A well-run demo isn’t merely a run-through of what tasks or stories were completed; it should be a chance for the team to tie their work back to value.
The reason why demos happen infrequently (weekly or biweekly) is that teams may have a difficult time tying individual work items back to value on a daily basis. After 5-10 days of work, they should be able to show progress toward delivering value in a way that is meaningful to their stakeholders.
There are many ways for this value to be demonstrated. Whatever language you and your client are using to define value (OKRs, KPIs, revenue increases, hours saved, etc.), the demonstrated work can and should be tied back to those measurable values.
For example, a shopping cart screen may not be interesting to a stakeholder, until they understand that the new streamlined flow will reduce cart abandonment. A nontechnical client may not appreciate the work that goes into improving API response time, but they will certainly appreciate a site that addresses users’ complaints of slowness.
Client value
It is essential to tie the work and value together for clients and other stakeholders. By showing how the team’s work has led to the delivery of features valuable to the client and their business, the PM validates the client’s choice to hire this team and provides evidence that the team’s processes are working.
The client can start to understand their own impact on delivery: how their presence in weekly reviews or daily standups has helped the team align on what they value and deliver a product that will serve their needs. It helps clients begin to understand (if they don’t already) how their participation in the iterative feedback process leads to better results.
And, crucially, it gives them the confidence that the team understands the needs of their customers and business and can be trusted to make decisions more autonomously.
Team value
For the team, connecting the dots between their day-to-day work and the value it produces gives them a sense of accomplishment that their hard work will actually make a difference to their users or stakeholders. It reassures them that they are on the right track, validates their decisions, and gives them greater confidence that they understand the “why” behind what they are building.
This in turn will reduce second-guessing and allow the team to proceed more quickly, leading to more results, more validations, and greater engagement success.
Stride is hiring Designers and Product Managers, learn more here!
Michael Kellman
