Ask Women in Product: How do I establish a compelling value narrative for my product?

Stephanie Muxfeld, Tyler Pietri, and Victoria Pacchiana demonstrate how they showcase the value of products that do not lend themselves naturally to traditional quantitative measures.

Photo by shanti via Twenty20

This week’s question: How do I establish a compelling value narrative for a product that doesn’t lend itself to traditional quantitative measures? An internal product, for instance, that doesn’t contribute to revenue?

Answer from Stephanie Muxfeld, Delivery Leadership Consultant at Slalom

Many products have an easily-defined value proposition. For products that increase sales or generate their own revenue, the value is very easy to quantify. For the purposes of this article, we’ll call those traditional-value products. What we’ll be discussing in this article are products that don’t have such an easily-defined value proposition. We’ll call those non-traditional-value products.

As product managers, we sometimes have a product that isn’t easy to place a traditional value on. For example, I once worked on a suite of products focused solely on reducing phone calls into a business. The product met this requirement by allowing customers to perform self-service transactions instead of calling customer service on the phone. Non-traditional value products like this self-service suite require PMs to take a fresh look at how to define value, both from the perspective of the business and of the customer.

Questions to ask when you determine value

What problem are you solving?

In the case I described earlier, the customer’s phone calls were coming into a department that was a cost center for the business, and the company wanted to better manage its operating costs by reducing the number of calls that required a call center agent. While there was no opportunity to generate revenue by reducing the number of calls, a lower incoming call volume for agents meant that the call center needed a smaller staff and a smaller office space even as the business continued to grow.

What is the value to the customer and the value to the business?

Both value propositions are important. In product management, we often get caught in the trap of thinking we should only advocate for the customer value. While the customer should always be at the front of our minds, there needs to be a balance. Often the business value is an increase in the efficiency of the business because routine tasks are automated. Rarely is the customer directly concerned with the efficiency of an organization. Thus, it is reasonable to call out both types of value when they are different.

In my earlier product example, a customer who was making the call would get value from the new product because they spent less time waiting on hold. Another increase in value for the customer was the ability to answer their questions through the self-service option at any time of day, whether or not the call center was staffed.

Some other examples of non-traditional value that you might use:

  • Time savings
  • Eliminating single points of failure / improving business continuity
  • Improvements in fraud detection
  • Increase in productivity through a decrease in non-value-adding tasks
  • Reduction in paper costs through digitization
  • Increase in the customer’s value perception

How will you measure the value?

If you can’t measure it, don’t bother to claim it. Even when you’re dealing with non-traditional value, you must be able to measure it. Time savings can be measured by monitoring improvements in transaction times. Improvements in business continuity can be measured by time elapsed since the last failure event. We can count the number of fraudulent cases detected and calculate the length of time that has elapsed from the fraudulent act to detection. An increase in productivity or throughput can be measured by counting the number of transactions processed per unit of time. A customer’s value perception can be measured through quick and simple online surveys. You must be able to measure the value, and sometimes this requires an immense amount of creativity on your part!

Decide on your key performance indicators (KPIs)

Why do you need key performance indicators? The KPIs will be your way of demonstrating the value of your product. Since you want to deliver value either to your customers or to the company, your KPIs should be aligned with the goals of your business. KPIs let you communicate the value of your product in terms that your co-workers and leaders can easily understand. Use the SMART criteria to help make your KPIs a valuable tool for both your product and your business.

Specific. What, specifically, will your product achieve? For example:

  • Reduce inbound phone calls by 20%
  • Reduce mailing costs by $10,000
  • Generate 30,000 completed transactions

Measurable. How, exactly, will you measure your progress?

  • Reduce inbound phone calls by 20% (measured by monitoring inbound call report)
  • Reduce mailing costs by $10,000 (measured by analyzing mailing cost expenditures)
  • Generate 30,000 completed transactions (measured by system data)

Attainable. It’s great to be aggressive when defining your goals, but they do need to have a reasonable chance of being achieved. Measures that you or your team have no chance of attaining are bad for your morale and the morale of your team. Unrealistic goals also undermine the confidence that your leaders have in your ability to deliver results. When you formulate your measures, estimate the benefit your product will provide. What is reasonable? For example, you are not likely to eliminate all phone calls; however, is it reasonable to reduce them by 20 percent? The answer depends on your customer demographics, how entrenched their phone habits are, and how much functionality your product can replace. After thorough research and testing, often you are left making an informed guess.

Relevant. Your KPIs need to matter. If no one in your organization cares about reducing inbound phone calls, will anyone care when you meet that goal? By aligning your product KPIs to the goals of your business, you ensure that your measures are relevant. Examples of relevant KPIs would be an overall reduction in inbound phone calls, or a desire to reduce mailing costs.

Time-specific. In agile software development, we often talk about getting rid of timelines and letting the team focus. But with KPIs, your audience needs to know when you will achieve the results. What’s the general time frame? For example:

  • Reduce inbound phone calls by 20% in the first month
  • Reduce mailing costs by $10,000 in the first year
  • Generate 30,000 completed transactions per month


Every product that solves a problem has the potential to deliver value to the right customer or the right business. When you’re working on a non-traditional-value product, you need to start with a clear idea of the problem you are solving and who you’re solving it for. Call out all the benefits that arise from solving the problem, then define the key performance indicators that will help you measure that value. Be SMART about your measures; doing so will ensure that your work is aligned with business needs and will enable you to deliver what you’ve promised within the committed time.

I hope this article and the additional resources below help you communicate the impact of your work and the value of your product.

Use these resources to learn more

Answer from Tyler Pietri, Product Manager at Klaviyo

There’s a special place in my heart for what many would call “unsexy” work. These are projects that are typically internal, are time- and resource-intensive, and have no direct or easily discernible customer impact of their own. In short, they’re not the obvious picks. However, as a product manager, it is not your job to pursue the obvious. Your job is to pursue value. So while customer-facing features will always outshine time-intensive internal projects, there is value in unsexy work, and this value can be quantified and evangelized.

I am a product manager for a team that owns several of Klaviyo’s older product areas. Most were hurriedly made to meet the business needs of the time and all of them are in need of unsexy work like code optimization, testing infrastructure, and “tech debt cleanup.” When I’m creating value propositions for projects like these — ones that often don’t lend themselves to traditional quantitative measures — I focus on these three things:

  • What kind of engineering value does your project generate?
  • Does your project have any inter-team dependencies?
  • Does your project align with product principles?

Let’s look at each question in more detail.

What kind of engineering value does your project generate?

The most effective way to evaluate an unsexy project is to talk to the people who have to build it. Developers are keenly aware of the shortcomings of your company’s code stack and system architecture; you should use this knowledge to your advantage. Good PMs understand their company’s technology, but great ones take it a step further. They know how their devs feel about that technology. If you ask engineers what frustrates them most about their job, they will provide you with compelling narratives in support of unsexy work.

In my experience, these narratives fall into three camps: Velocity, Confidence, and Ease.

Increase developer velocity

Developers want to use their time effectively. Ensuring that they do is your highest priority. Code refactors and other similarly unsexy projects may have little direct customer-facing value, but they can make notable improvements in your devs’ velocity, which means your team can create more value and at a faster rate later on.

When creating value propositions, talk to your devs and see if the project has any impact on code cleanliness, code extensibility, or code readability. If your project strikes at one or more of these areas, it will have positive downstream effects on your ability to ship value. Dedicating a few months to a code overhaul may mean you can release six customer-facing features as opposed to three because your engineers are unencumbered by unruly code. It can also help new developers onboard faster, allowing them to make meaningful contributions to the team sooner.

Improve developer confidence

Much like you, your devs deeply care about the customer experience. No engineer wants to be liable for causing customer pain. The value proposition of an unsexy project can lie in its ability to let your developers ship with confidence. In the early days of my team, my devs were reluctant to ship optimizations to a particular feature. Their trepidation was born of an inability to ensure the release wouldn’t break the feature and other core functionalities that relied on it. Building an end-to-end test infrastructure, a long and decidedly unsexy project, allowed my devs to ship with confidence because they knew they could identify issues at scale prior to release.

So was the optimization delivered behind schedule? Definitely.

But did the optimization work well? Exceedingly so.

The test infrastructure caught a number of breaking bugs pre-release and has reiterated its worth with every subsequent expansion to that feature. Aside from that, the infrastructure also set the groundwork for other teams to create their own automated testing. Though this unsexy project did not explicitly impact our users, it improved my team’s and my company’s ability to reliably provide value to our customers.

Make development easier

See if your project eliminates any requests that are frequently asked of your developers. These requests are typically small tasks that other departments can’t do on their own. There’s a strong likelihood that your devs have already pondered optimizing these tasks, if not automating them altogether. If this is the case, you can quickly quantify a few things, including (a) How often the developers do this task, (b) How long it takes them to do, and (c) How much it irritates them to do it.

The customer pain that prompts these requests may be low, but there is a hidden and very real compounding cost in context switching. The less energy your devs waste on monotonous work, the more time they can dedicate to things that matter. Monotonous work can also include unoptimized engineering-specific processes like setting up development or testing environments, installing dependencies, or merging and deploying code. If there are unsexy process improvements that can increase developer velocity across your entire organization, you have a great value proposition for prioritizing that work.

Does your project have any inter-team dependencies?

The best PMs are invested in the success of the entire product and not just their particular area of responsibility. You can build a more holistic view of your entire product by looking to your company’s roadmap. Familiarize yourself with what other teams are working on and understand the intersection between your product area and theirs. This larger context will keep you attuned to any reverse dependencies. Brandon Shu put it well,

There are times when you have a project that will really help other teams to achieve their goals.

The best value proposition for an unsexy project is that it sets the foundation for another team to resolve key customer issues. I personally build this inter-team context by hosting weekly one-on-ones with the other PMs on Klaviyo’s product team. This is an opportunity for both of us to learn about each other’s plans and get high-level insights into the technical specs and product designs for one another’s upcoming features. The benefit of these PM-to-PM sessions is that they reveal inter-team dependencies early in the speccing process. You may find that an unsexy project you planned to tackle next quarter will help another team with a customer-facing feature they’d like to begin next month. You might even learn that it unencumbers them to resolve a larger issue that they’ve been putting off due to technical limitations.

The end goal is to figure out if your unsexy project allows another team to release faster, more sustainably, or frees them up to attack higher priority issues sooner. If your project lets them ship faster, you can quantify by how much and what that additional time means for revenue, dev cycles, or other traditional measures. If it lets them attack higher priority issues, you can calculate the amount of churn or NPS that’s impacted by unblocking them. When reverse dependencies are involved, it means your unsexy project gets to adopt the value proposition of whatever it unblocks or aids. So if another team’s feature impacts $500K worth of additional revenue, your unsexy project just became far more enticing.

Does your project align with product principles?

Internal projects are not the only forms of work that can be hard to justify. Many customer-facing endeavors have little quantifiable impact. These projects are usually small UI/UX endeavors like redesigning a page or reducing the number of clicks it takes to do an operation. They don’t take terribly long to do, but they don’t have an outsize impact on traditional measures like revenue, churn, or NPS either.

When I have a customer-facing change that I believe is valuable, but doesn’t rank high on the usual measures of success, I look toward my company’s product principles. Your product principles define both how you develop products and what ideals to strive for as you build. They exist to ensure your product is coherent and provides the best possible experience for your end user. If a feature is inconsistent with your product principles, it’s likely falling short in one of those two categories.

To create value propositions for unsexy customer-facing features, look toward your product principles and determine how many and to what extent the project addresses them. This exercise can help you understand how far out of alignment a given feature is, so you can prioritize it accordingly. If you have a session replay tool or a means to interview customers, you can further validate how many users get tripped up on the UI/UX that you’d like to change. You may only be updating an icon or removing a bit of friction from a process, but it could make a world of difference in the usability of that feature.

My team and I recently used this approach when we proposed adding a new drop-down menu to our product area. Like most unsexy UI/UX work, the proposal was met with resistance. Not only was the change not supported by traditional measures, but to make matters worse, it was a departure from current design standards. To justify our proposal, we looked to Klaviyo’s product principles to build our value proposition. In particular, we used Klaviyo’s principle of “making the complex simple” to argue that the new menu would make for a more intuitive user experience. The change was ultimately approved and several customers subsequently shared that it was easier to find their menu options. Our new drop-down style — an unsexy mini-project that met a fair amount of initial resistance — is now used in several places throughout the platform.

Although this small tweak may seem unimportant relative to other projects, it’s changes like this that make the difference between good product experiences and delightful ones. They’re the type of changes that are worth making time for. By building a familiarity with your company’s product principles, you can better prioritize and evangelize the value of smaller UI/UX features.


Ultimately, there are many ways to create a compelling value proposition for odd, unsexy projects. The approaches I described have worked well for me, but feel free to explore. Keep an eye toward your devs, be quick to recognize how your work benefits those around you, and internalize your company’s product principles. You’ll soon find yourself on the right path to evaluating and justifying any project, no matter how unsexy.

Answer from Victoria Pacchiana, Senior Product Manager at SchoolMint

This is a great question and you are definitely not alone — many product managers work on internal tools that, while really important, require some explanation when citing impact. There is, however, a lot you can “measure,” and it starts with digging into the essential tasks of a product manager:

  1. Understand your users
  2. Identify their pain points
  3. Determine possible solutions and execute
  4. Extrapolate the impact

By gathering metrics in steps one and two, you can craft a compelling value narrative in steps three and four with data that will complement the qualitative data you’re already presenting.

A Customer Support Specialist (CSS) example

Let’s say you work on internal tools to support a Customer Success Specialist team. The queue of support tickets is consistently backlogged, team members are stressed, and the prevailing thought is that the company simply needs to hire more people to solve the problem. While hiring certainly helps, it adds to the overhead cost and diverts funds that could perhaps be spent in another department that leads to growth (R&D, partnerships, L&R, etc.). Hiring more people also fails to get to the root of the problem — why is the queue so long, and why are employees so stressed?

1. Understand your users

Here are some questions and their purely hypothetical answers to illustrate an approach:

  • How many Customer Success Specialists are there?
  • How many hours per week does a Customer Success Specialist work?
    40 hours a week, 5 days a week
  • How many tickets are received each week?
  • Roughly how long does it take for tickets to move from receipt to resolution?
    On average, 3 hours per ticket
  • What is the nature of the tickets being received, and how are tickets distributed across those categorizations?
    40% — Answer questions about the product
    25% — Routing leads to sales
    20% — Escalating issues and routing ideas to R&D
    15% — Tech support
  • What is the goal and purpose of the Customer Success Specialist team?
    To provide unparalleled service and support to customers and represent their voice in the company.
A hypothetical breakdown of CSS cases by type

2. Identify their pain points

Given the above hypothetical (and admittedly over-simplified) data, we can determine the following:

  • Each Customer Success Specialist has around 20 tickets each week to process.
  • If the average time to process a single ticket is 3 hours, then 2.6 tickets can be processed each day, equivalent to 13 tickets per week. This means that there is a gap of 7 tickets each week that carry into the next week or go unresolved.
  • Each Customer Success Specialist is spending around 16 hours a week, or 2 business days, answering questions about the product.
  • Each Customer Success Specialist is spending around 10 hours a week, or 1.25 business days, routing leads to sales.

3. Determine possible solutions and execute

As a product owner looking at the above, one clear avenue to explore is reducing the length of time Customer Success Specialists spend answering basic questions about the product, especially when it’s taking up almost half of their time. A reduction in this type of task can be achieved through FAQs, better customer onboarding, a learning community, automated ticket responses with templated answers, etc.

Implementing one or a combination of these solutions will allow you to say something like — “Impact: Reduced time to resolution by X%” — which is awesome, and your first metric!

4. Extrapolate the impact

And there’s another thing we can consider, which is that by not doing A, Customer Success Specialists get to do more of B. The “B” is something important. It should connect back to an overall company goal that moves the business forward. In the above scenario, our “B” is “routing leads to sales” or “escalating issues and routing ideas to R&D” since both types of tasks connect to the overall goal of the Customer Success Specialist team to “provide unparalleled service and support to customers and represent their voice in the company.”

By reducing the amount of time that Customer Success Specialists spend answering customer questions, we enable them to spend more time routing leads to sales, which can lead to more sales, or routing ideas to R&D, which can lead to product growth (and thus more sales).

Given these factors, your final value proposition might take the following form:

  • Reduced time for resolution by X% through help portal and internal tools for Customer Success Specialists to quickly send templated answers to common questions
  • Improved NPS score by Y points by identifying product gaps through improved reporting around customer inquiries
  • Increased monthly sales by Z% by streamlining the pipeline between qualified customer inquiries and the appropriate sales agent


This article provides a fairly simplified example, and there are many more inputs you’d take into consideration, but by grounding your first questions in numbers, analyzing root causes, building out actual solutions, and extrapolating their impact, you can craft a compelling case around your product’s value and your contribution to achieving overall company goals.

A global community of women working in Product Management.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store