Product value metrics: Drive business outcomes
Establish guiding principles for the application in the product vision document (also known as the product charter) and then reference them throughout the software’s lifecycle. For example, a car loan application product enables customers to self-service with features like remote contract signing and comparison of interest rates. The process saves the customer and business ops team time. Leverage an iterative build-measure-learn approach to evaluate success after each release and reincorporate learnings from recent releases back into the product.
The build-measure-learn loop is the governing technique to assure that product teams focus on what drives successful outcomes.
Avoid relying on a deep reporting hierarchy that wastes time and money. Instead, use value metrics for the team to self-inform and understand priorities. Measure the impact of a particular feature on a customer, while staying nimble enough to pivot when not achieving optimal results. Localizing decision-making empowers the team to:
take full ownership of the product’s successes or failures;
make decisions faster to reach of desired outcome; and
eliminate overhead (e.g., churn between the business sponsors and technology delivery teams).
Identify the metrics necessary to launch the product and align the team after the product hits the market. Upon achieving the initial outcomes, evaluate the following:
how to quantify marginal improvement;
how to monitor customer health;
what financial metrics to include for ongoing investment;
how much product debt exists; and
what denotes value for accelerating delivery and reducing debt.
Defining realistic outcomes
Establish specific, measurable, and achievable outcomes.
Don't: Capture 50 percent of total market share. This likely won’t happen because the expectation is too high and broad.
Do: Automate approvals for 30 percent of all incoming loan applications. A proven best practice is to start by setting and measuring small goals as a point to validate the product.
Set three to five outcomes to start. The team needs to easily recall the target outcomes and recalibrate based on the metrics established in the product charter. When the time comes to release the product, adjust and evolve the desired outcomes.
Enabling customer success
Balance the interests of business with customer expectations. Include metrics to evaluate how and if the desired business outcomes affect (positively or negatively) the customer experience. Select metrics in line with the type of product that measure customer detractors and promoters.
Don't. A lackluster experience and poorly performing internal company product inevitably causes frustration, damaging engagement and productivity.
Do. Ease of onboarding increases adoption (e.g., auto-filling forms, natural language forms).
Use metrics that evaluate the customer experience.
| Metric | Measurement |
|---|---|
| Net promoter score (NPS) | Notes the likelihood of customers recommending the product, predicting customer loyalty, and lifetime customer value. |
| Customer satisfaction score (CSAT) | Evaluates customer sentiment, which helps the business focus on implementing highly desirable features or pinpointing pressing issues to remedy. |
| Churn | Tracks the percentage of customers quitting the product in a given period of time, measuring retention or the lack thereof. |
| Expansion revenue | Calculates the percentage of new revenue coming from existing customers, measuring customer growth within the product. |
Managing product debt
Product debt is the accumulation of product decisions that have a negative impact on the customer and business. Building successful custom software always leads to:
a large backlog of desired features by business and customers;
competing priorities, limited time, limited funding; and
and a struggle between the core product roadmap and customizations for each client.
Keep a prioritized backlog of product debt from the release of the first version. Flag product debt stories initially compromised for one reason or another (e.g., speed, cost) for improvement. Once the product hits the market, review the immediate product roadmap, the technical debt backlog, and the product debt backlog captured during the planning session. Identified, estimated work is easier to manage, plan, and complete successfully.
Don't: A bank leaves a mainframe system alone, paying licensing fees to run an old version that lacks modern security functionality or leaves system in a fragile state (i.e., customer data in a vulnerable state).
Do: A bank maintains system software with the latest patches (e.g., security, functionality) keeping the software current (i.e., customer information is kept safe, system is easier to maintain).