Product Management Skills - Articulating value risk
Value risk is the risk that the solution is not valuable to the end user or customer.
As a product manager, you have to be able to articulate, separate, and define your risks - the potential negative effects of whatever you are trying to do. Articulating them helps you frame and compare them appropriately - ignoring low risks and mitigating higher ones.
These are the levers you use and the plates you balance as a product manager to create and deliver value.
If your users and customers don’t get value from your solution, then it likely won’t have the effect you want. Identify the risks before you spend the cost to build it.
$1,125,000 in development costs. Nine months of development. This centralized, curated, tagged database of every single possible customer in the country was going to drive forward expansion like never before. With precision information, the sales force could go directly to the largest, most valuable customers and capture large swaths of the market - customers we didn’t even know existed before. We could compare our user performance with the centralized database to identify what markets were under-served, over-served, and adjust the sales strategy accordingly, and bake these insights into the product.
The project, dubbed TAMMY (Total Addressable Market Maximizing Yield), was the brainchild of Jen, the product manager working closely with the executive team and the sales oganization. It was the largest technical integration the company ever undertook.
A year after release, the project had achieved none of its desired results. Nobody was using it except a couple of data analysts who already had access to the underlying data even before the project started. It hadn’t driven strategy, and the intended users weren’t using it at all.
In short, it wasn’t valuable - a huge waste of money, time, and effort because it solved a problem nobody actually had.
Value risk
Value risk is the risk that your users and customers don’t get value from your solution.
It’s often conflated with adoption risk because what people don’t get value out of, they likely won’t use or buy. Product Managers instead spend all their efforts focusing on increasing adoption.
Value risk is a distinct risk area with different levers to mitigate and address.
Mitigating value risks
Mitigation of value risk requires significant skill by the product manager:
Deeply understand your product
Deeply understand your users and customers
Identify and understand the problem spaces and levers
Be able to quantify the value
Move in small iterative, increments
Avoid over-indexing
Deeply understand your product
Your product has a set of features that provide capabilities to solve problems that the users and customers have.
Can you articulate those problems? Can you name and understand the capabilities and how they solve those problems? Do you know how to configure, use and set up those features to leverage those capabilities? Do you know how it is being discussed and sold to potential customers? Do you know how users use the product? Do you know where it fits into your company’s narrative?
If not, you need to educate yourself on the product.
Use the product yourself. There’s no replacement for using the product yourself. Eat your own dog-food. Familiarize yourself with its capabilities and limitations. Feel the pain your users feel.
Read documentation. Take advantage of any articulated knowledge that has been written in the past. Requirements documentation, meeting notes, decision logs, marketing collateral, historical Slack/Teams messages, specifications - these are all valuable context to build an understanding of why things were done, and how things behave under the hood. Just keep in mind they might not be accurate.
Watch users use it. If you have access to user session playback tools like Fullstory, or recorded user testing sessions, watch them! If you have access to a user, ask if you can shadow them as they use the product. Keep in mind that users can change behavior when they know they are being watched.
Look at product analytics. Product analytics tools like Amplitude, Mixpanel, etc. are great. If the tool has proper instrumentation, you can piece together funnels of user behavior. Identify whether there’s an up-to-date lexicon so you can see which event goes to which page, or if one doesn’t exist, create one. If not properly instrumented, you can still look at the URL properties of events, which most analytics tools automatically track to construct rudimentary funnels.
Read the code. If you’re somewhat technical and have access to the codebase, you can read the code to identify what’s happening. The code is the truth of how things behave in the product. If you can’t read code, you can at least read change logs, commit messages, or Pull Request discussions to gain context.
Talk to engineering. Engineering built the product, so they likely can tell you all the messy details of how it behaves. Build relationships with engineering partners so you can ask questions and gain deeper understanding. Just be sure to do your leg work first, and take notes!
Talk to support. Support is an excellent source of nuances. Just keep in mind that they often operate without technical support, so workarounds and explanations they have for why things are the way they are may not be reflect of the reality, but are more cargo-cult in nature*.
Talk to anyone else. Don’t disregard knowledge others might have. From Account Management to Sales to Marketing - identify the keepers of knowledge and invite them to chat.
You have many sources to understand your product - there’s no excuses: get at it!
*Cargo cults
The term “cargo cult” come from World War II. Indigenous tribes saw American troops build and operate air fields and receive supply drops. After they left, the indigenous people built their own air towers out of wood, copied the motions of the soldiers, and went through rituals of marching up and down, expecting that this summoned the planes to bring down equipment.
Obviously, the planes never arrived. The term refers to ritualized behavior that people do because they mis-interpret the chain of cause and effect - continually taking actions that don’t actually lead to the effect they desire.
Deeply understand your users and customers
It’s not enough to understand your product. You have to understand and get into the minds of the people buying and using your product if you want to create value.
Your product is just a small sliver of your users’ and customers’ daily, weekly, and monthly experience. If you over-emphasize your current product, you might think everything is fine because they are generally happy with your product and there’s no complaints, only to see mass migration once a competitor solves an intense pain point you weren’t even aware existed.
There’s no replacement for deeply understanding the user and cusomer.
Talk to them, a lot
Deep understanding requires you to talk to them frequently.
A lot of product managers fall down here, opting to look purely at quantitative data, or do external-focused industry and market research. Don’t get me wrong - these are valuable, but data will never tell you why something occurred, only what has occurred.
To truly understand the why, you need to build and cultivate consistent feedback loops with your users. customers, and intended audience.
Remember - it’s not just about their experience with your product. It’s about understanding their total experience, period.
What does the user’s day look like?
What are their pain points in their day-to-day?
What part of your product is used during what part of their day?
What are users doing in other products, or outside your product?
What do they actually want to accomplish and do every day?
What is the long-term desires and goals of the user or customer?
What constraints is the user or customer operating under?
There’s a lot of frameworks and practices that help you articulate and map this knowledge out into something insightful and actionable.
Jobs To Be Done
Process Mapping (User and Business)
Value stream mapping
If these frameworks are too complex or too daunting to start using, then start simple. You don’t have to get fancy.
A quick-start guide to gaining understanding
If you find frameworks complex, then do a simple process:
Create a table, with columns for every day of the week, or month Sunday through Saturday.
Create four rows:
Morning
Noon
Afternoon
Evening
Talk to your users an customers. Ask them what their day and week looks like. Be specific - ask open-ended questions like“what do you do in the morning?” or “do you do that every day, or only on Mondays”. Ask them what the most painful and time consuming parts of their days are. Ask them what tools they use during what parts of the day. Ask what business processes are done, when, and why.
Find commonalities and put them in the appropriate cell - one line for each thing they mention.
Soon, you’ll have filled the table with a general picture of the week or month consisting of activities, pain they’ve highlighted, and even possible mentions of other tools they use.
Identify and understand the problem spaces and levers
At this point - you should have an understanding of your existing product, and you should at least have a general understanding of your users and customers.
Use that understanding as your starting point. Now that you know what your users’ and customers days looks like at a high level, you can drill down into specific points of interest, and start mapping where your product fits in or doesn’t fit in. If you see that an item in a day has a particular applicability for something your product can address - either a pain point or an opportunity - congratulations! You’ve just identified a potential problem space.
Is there anything in your product today that is causing pain? Create a list of these pain points of existing items. Identify the simplest, lowest-cost solutions to remediate as many of those pain points as possible, and then deliver on them. These are low-hangers, and are often table-stakes - the 1% incremental units of friction that aren’t valuable independently, but collectively causes decreased user satisfaction. Solving them in one go helps you create momentum and avoid their future distractions as you focus on larger problems.
Identify the biggest problem spaces. What are the parts of the journey (both within and outside of your product) have been brought up? Pay attention to items that have been:
Mentioned the most frequently
Take up the most time
Take up the most attention
Are the most important to get right
Have the lowest success rate
Are the most complicated to do
Require high skill to do
Require many steps to do
These are opportunities to streamline processes, remove pain, decrease needs, etc. The more users and customers in common that feel it, the more you reduce value risk. The more intense the pain, the more likely it is a solution that solves that pain will be valuable.
Identify what you’re trying to do for the customer or user - these are your levers to pull to solve the problems they are encountering:
Save them time? Find the items that take up the most time in their day to do. Reduce steps, streamline them, or make it so they don’t have to do them at all. Sometimes users do a large time-consuming process just to calculate a value or find a piece of information you could have displayed in the product easily.
Save them focus? Continued focus on something can be mentally draining. What are they focused on? Can you create some sort of alerting mechanism so they “fire and forget” and switch attention to something else?
Save them repetition? Identify things you can automate or reduce the steps on. Tasks that are mechanical and wrote, such as updating records with the same set of steps or same value, or checking for discrepancies for review, are great candidates for bulk modification enhancements or automated difference highlighting.
Prevent them from making mistakes? Errors can cause rework or have downstream consequences. Find out what the most common mistakes made are, and create in-product guardrails to help automatically detect and prevent them.
Allow them to delegate? Sometimes a user does a combination of things with your product. Perhaps they select a set of records, download the data, slice and dice to a set of columns, and then upload that back into the system. Doing this correctly requires skill and knowledge they may not have been able to reliably impart on others. Automating that process or creating a guided mechanism can allow them to delegate that task to other people.
Give them a new capability? If you allow your users or customers to do something they’ve never been able to do before, that opens up a new area your product can fit into their day-to-day. Sometimes you don’t even have to give them the power to do it, but the information to do it.
From there, you can quantify the user value in terms of time saved, errors reduced, capabilities created, steps reduced, etc. This can also translate into customer value from a revenue and cost perspective depending on the kind of organization you’re in.
Be able to quantify the value
You could, if desired, back this into a currency value for your users and customers.
Let’s suppose there’s a 12-step process a customer has their users to use in your product:
Keep reading with a 7-day free trial
Subscribe to Joseph Gefroh to keep reading this post and get 7 days of free access to the full post archives.