Tag Archives: product strategy

Your #1 KPI as a product manager

What’s the #1 metric you need to track as a product manager?

What’s the #1 KPI you should sign up for as a product manager?

It’s not on-time delivery, the number of bugs or features per release, innovation success, speed-to-market, sprint velocity, uptime, or even customer satisfaction.

Those are interesting to track, but none of them are #1.

It’s important to remember that our primary job as product managers is to drive sustainable business growth.

To do this, it’s not just important for us to deliver customer value, but monetizable customer value — products, features, capabilities, services that customers will pay for and continue to pay for.

Product management as a function is about sustainably managing and growing the customer value monetization process.

Meaning the process by which we create and deliver monetizable customer value.

And so as product managers we need to deliver monetizable customer value in a way that drives sustainable business growth.

On-time delivery, features or bug per release, sprint velocity, uptime, etc. — none of these metrics help us measure how successful we are in doing this.

So if our job is to drive business growth through the delivery of monetizable customer value, then the #1 KPI a product manager needs to track is sustainable growth.

That means product management and product managers should sign up for the business metrics that best measure customer demand and market growth for our products.

For a SaaS product, that boils down to two key metrics:

  1. Monthly/Annual Recurring Revenue (MRR/ARR) or its cousin Annual Contract Value (ACV) Bookings
  2. Customer Lifetime Value (LTV or CLTV)

The first is a measure of the demand and growth of your product.

The second is a measure of its sustainability.

I introduced these in an earlier post. In this post, let’s take a deeper look at MRR and Bookings. I’ll discuss LTV in another post.

Let’s start with MRR.

Monthly Recurring Revenue (MRR)

Monthly recurring revenue is the total amount of predictable revenue a company expects on a monthly basis.

Annual recurring revenue or ARR is simply MRR multipled by 12.

MRR is typical for a monthly subscription business, and many SaaS companies follow this model: MailChimp, Hubspot, Basecamp, Jira, ConvertKit, Aha.io to name just a few.

MRR is the purest measure of revenue and a key indicator of growth for a SaaS product. The month-over-month percentages give a good status check of whether momentum for your product is building or waning over time.

When MRR is relatively consistent and predictable, it’s a crucial financial metric to use in financial forecasting and planning. For example, to use as part of your ROI analysis when putting together the business case for a product idea.

How To Properly Calculate MRR

At first, calculating MRR may seem as simple as multiplying the total number of customers by the average amount they’re paying per month.

But if that’s all you do, you’ll be making a BIG mistake.

Not calculating your MRR/ARR correctly can cause you to misjudge the true health and trajectory of your product.

The calculation is as follows:

MRR at the beginning of the month
MRR gained from new customers during that month
Additional MRR gained from existing customers who upgraded that month

MRR lost from customers who downgraded that month

MRR lost from customers who churned that month

ARR = MRR * 12

Things to include in your MRR calculation:

  • All recurring revenue, including monthly subscription fees and any additional recurring charges for extra users, seats, etc. (based on your pricing model).
  • Upgrades — i.e., customers who upgrade to a higher paying plan.
  • Downgrades — i.e., customers who downgrade to a lower paying plan.
  • All lost recurring revenue — i.e., customers you’ve lost, including any additional recurring fees they were paying for extra users, seats, etc. (based on your pricing model).
  • Discounts — for example, if your customer is on a $100/month plan, but pays a discounted rate of $75/month, that customer’s MRR contribution is $75, not $100.

Things NOT to include in your MRR calculation:

  • One-time charges — like setup fees, implementation charges, one-time upgrade fees, etc. They’re not recurring. You don’t expect to receive them on a regular basis.
  • Non-recurring add-ons — again, not recurring.
  • Subtracting transaction fees and delinquent charges. This may be tempting in order to be more conservative and “accurate”. But while well intentioned, it will result in misleading results. Transaction fees are an expense, not a loss in revenue. A delinquent charge technically means you didn’t collect the subscription from the customer. Both should be separated out and represent optimization opportunities.
  • Recurring costs, COGS and other expenses — MRR is a revenue growth metric, not a profitability metric, so don’t include costs.
  • Trialers — these are folks who have signed up to trial your product. They haven’t paid you yet, have they? So they don’t count toward MRR. Once they pay you, they count.
  • Bookings — This a common mistake. We’ll discuss bookings in a bit.

It’s important to understand that MRR is a metric that allows you to measure momentum and growth, and so should be kept as pure as possible. That means non-recurring fees and expenses should be kept out of it.

Product Teams Need to Focus on Net MRR/ARR Growth

Sales and marketing teams will typically be incentivized to focus on new MRR/ARR — meaning adding new customers every month (or year).

Customer Success teams will typically be incentivized to defend against MRR churn by focusing on retention and/or expansion MRR/ARR (i.e., getting existing customers to pay more).

Product teams need to be incentivized to develop features and experiences that drive both new MRR and defend against MRR churn — i.e., net MRR growth.

Product teams need to focus on net MRR growth – from SaaS Metrics for Product Managers

This is where we get to the heart of the matter.

By focusing solely on new MRR, it could lead the product team to believe MRR is growing at 30%. But that would be misleading!

The more accurate growth rate is 15%. So the product team needs to focus on downgrades and churn as well.

What’s the point of building new features if new customers aren’t subscribing or existing subscribers don’t keep paying every month?

How do you know if those features are attracting new customers or keeping the existing ones happy?

And BTW, by “happy” I mean “continuing to pay you money for your product”!

Bottom line: For a subscription based SaaS product, your #1 KPI as a product manager should be net MRR growth.

Next, let’s talk about Bookings and ACV Bookings.

Bookings and Annual Contract Value

Simply put, a booking happens when a customer agrees to spend money with you.

In B2B enterprise SaaS businesses, it’s typical for a customer to sign a contract. The booking exists when the customer signs the contract.

So bookings are the total dollar value of all new signed contracts — it’s the sum of all revenue promised to your business through any contracts signed.

It’s typically expressed as an annualized number even if the agreement period is longer than a year. Hence, Annual Contract Value or ACV.

A contract doesn’t have to exist, though, to have a booking. In a month-to-month subscription model, a booking exists when the subscriber signs up for a month of your SaaS offering — the subscriber has committed to that month of service without having signed anything.

In this case, bookings are typically an annualized recognition of expected recurring revenue, i.e., MRR/ARR. (And so ACV is pretty much the same as ARR.)

Why ACV Bookings is a Critical Metric

ACV bookings are a measure of the market demand for your product.

In other words, bookings tell you how the market is responding and committing to your product. As such it’s an important metric for measuring the growth and success of your product.

In other words, how do you know the features and user experience you’re delivering are actually resonating with customers? That’s what ACV bookings tell you. Because if those features and experience don’t resonate with customers, they won’t commit to spending money on your product.

Bookings also allows you to understand your expected revenue and cash flow. For example:

  • Let’s say in a given month 20 customers sign 1-year agreements committing to pay $20K each.
  • This means you know you can expect $400,000 in revenue over the course of the next 12 months.
  • You add some cool new features to the product, and the following month 30 customers sign $20K one-year agreements
  • This means you can expect $600,000 in additional revenue over 12 months from these customers.
  • So ACV bookings went up 50%, expected revenue went up 50%, which means the business is growing!
  • This is a great indication of the value your product (and your efforts) are delivering to the business.

In addition, for a SaaS product requiring customer contracts, tracking ACV bookings allows you to track growth without having to worry about when the customer actually pays (i.e., the precise payment terms, which can vary contact-to-contract). Let your accounting department worry about that.

The things to include and exclude in calculating bookings are the same as those for MRR.

Difference Between Bookings, MRR, and Billings (or Cash)

It’s important to understand the difference between these metrics so you don’t get tripped up with how your finance department looks at revenue.

Let’s take the following example:

In the table above:

  • Customer A signed up for the $50/month Basic plan and decided to pay monthly.
  • Customers B and C signed up for the $100/month Premium plan and decided to pay annually.
  • Customers D and F signed up for the $100/month Premium plan and decided to pay monthly.
  • Customer E signed up for the $50/month Basic plan and decided to pay annually.

Here are what the metrics look like:

Can you see the difference? Customers A and B were acquired in January. Their accounts represent ACVs of $600 and $1,200 respectively. So that’s a bookings of $1,800 in January. Customers C and D were acquired in February. So

Customers A and B were acquired in January. Their accounts represent ACVs of $600 and $1,200 respectively. So that’s a bookings of $1,800 in January.Customers C and D were acquired in February. So

Customers C and D were acquired in February. So that’s a total ACV bookings of $2,400 in February.

In February, there was no churn and two customers were acquired. So MRR went up to $350.

Unlike Bookings or MRR, Billings is when you actually collect money from your customers. Customer A paid $50 for January, but customer B paid $1,200 for the entire year. That’s a cash inflow of $1,250.In February, customer A paid $50, because that customer is making monthly payments. Customer B

In February, customer A paid $50, because that customer is making monthly payments. Customer B paid nothing because that customer already paid for the entire year in January. Customer C signed up and paid $1,200 for the entire year. Customer D signed up, but only paid for that month. So Billings for February $1,350.

Product Teams Need to Focus on ACV Bookings

The nice thing about ACV Bookings is it aligns the interests of both sales and product teams. Because bookings is a measure of market demand and acceptance, it’s a relevant business metric to use to motivate the product team to continuously develop amazing features and user experiences to increase committed contracts.

Bottom line: While applicable for any SaaS product, particularly for contract-based SaaS products, your #1 KPI as a product manager should be ACV Bookings growth.

Key Takeaway

Remember: Your primary job as a product manager is to drive business growth through the delivery of monetizable customer value.

So the #1 KPI a product manager needs to track is sustainable growth.

For a SaaS product, that boils down to two key metrics:

  1. Monthly/Annual Recurring Revenue (MRR/ARR) or its cousin Annual Contract Value (ACV) Bookings
  2. Customer Lifetime Value (LTV or CLTV)

So for a subscription based SaaS product, your #1 KPI as a product manager should be net MRR growth.

And for a contract-based SaaS products, your #1 KPI as a product manager should be ACV Bookings growth.

BTW, I’ve created this helpful 2-page SaaS Metrics Quick Reference Guide for Product Managers that you can download totally for free. Print it out, post it on the wall of your cube or office so that way you’ll have it conveniently available as a reference at all times.

Get the SaaS Metrics Quick Reference Guide for Product Managers >>

SaaS product management

It’s amazing how often product managers forget a simple, yet fundamental truth:

Our job as product managers is not just to build features users want…

Not just to prioritize the roadmap…

Not just to spend time talking with customers…

Not just to ensure a successful release…

Those activities are important, of course.

But they don’t represent our primary job.

They don’t speak to the thing that enables us as product managers to deliver value to the organization.

So here’s the thing many product managers forget:

Your primary job as a product manager is to help drive the business.

Our job as product managers is to find ways to drive the growth and profitability of the business.


Now, we’re not sales people. We’re not in marketing. We’re not in customer success or support.So you’re not directly held to meeting a sales quota, or a lead gen goal, or a customer satisfaction score.

So we’re not directly held to meeting a sales quota, or a lead gen goal, or a customer satisfaction score.

So the way we drive business growth is by being strategic in how we decide to add new features and enhance existing ones, build new products and expand existing ones.

This goes beyond just validating feature requests and prioritizing and building them. This is much more fundamental than that.

In order to be strategic about your product, you must understand your product’s business model.

In other words, you need to understand:

  • How your business acquires, retains and expands customers; and
  • The key goals for your product’s business model.

Furthermore, you need to know the right set of metrics to focus on to drive the success of your product — not just metrics for the sake of metrics, but the metrics that are actionable.

Actionable metrics, combined with an understand of your product’s business goals and business model, provide you with the core foundation you can use to make strategic decisions about how to grow your product and measure its performance.

Let’s get specific. Let’s take a SaaS product as an example. Lots of product managers manage SaaS products. And there’s plenty of range here, from SaaS products targeted to individuals and small teams to those targeted to B2B enterprises.

Let’s look the high-level goals of a SaaS product and drill down from there to discuss the kinds of business metrics we all need to be focused on to measure the performance of our SaaS products, and use them to be strategic in how not only we manage and grow our products, but deliver monetizable customer value.

Primary SaaS Business Goals

At the most fundamental level, there are three primary business goals for any SaaS product:

  • Profitability. Duh.
  • Growth. Meaning sustainable revenue growth through the acquisition of new customers, and retention and expansion of existing customers.
  • Cash. This is a top concern for your CEO. Ultimately, cash inflows must be > cash outflows. No cash = no business (regardless of how good other metrics may be). Cash is heavily impacted by months to recover the cost of acquiring a customer.

For the purposes of this post, we’ll focus on the first two: profitability and growth. The good news is that by impacting these two goals, as a product manager you’ll be helping the third one too.

There are three ways to look at profitability and growth:

  • Revenue
  • COGS and Gross Margins
  • Unit economics

Let’s talk about each in turn.

Revenue Growth and Profitability

For a SaaS product, the key revenue metric is Monthly Recurring Revenue (MRR) or Annual Contract Value (ACV).

Monthly Recurring Revenue (MRR)

Many SaaS products are sold requiring no long-term contractual commitment from the customer. The customer signs up for a monthly payment plan and has the convenience of unsubscribing any time.

The recurring amount the customer pays every month is called Monthly Recurring Revenue or MRR is the key revenue metric for this type of SaaS product.

Quite simply, MRR is the revenue you’re earning every month from your customers. It can be calculated by multiplying the total number of paying customers by the average amount they pay you every month, called Average Revenue Per User (or Customer) or ARPU.

  • Total Number of Customers increases with new customers acquired every month and decreases with customers lost during the same month.
  • ARPU increases with customers who upgrade to a higher paying plan and decreases with customers who downgrade to a lower paying plan and customers who churn. It can get a bit complicated when you have customers paying different price points, different customer segments, and your product mix.

The key point to remember when calculating MRR is to focus on net MRR because every month you’re both gaining and losing customers. And hopefully, you’re gaining a lot more customers than you’re losing!

Focus on net MRR! – From SaaS Metrics for Product Managers

Focusing on net MRR will provide a more accurate view of growth. Here’s an example:

If you focus solely on new customers and upgrades, you could be led to believe MRR is growing at 30%. But that would be misleading!

You need to factor in downgrades and churn (i.e., lost customers), resulting in a more accurate 15% growth rate.

Annual Contract Value (ACV) and Bookings

If you manage a B2B enterprise SaaS product, it’s likely your customers are signing long-term contracts for a guaranteed period of time, like 12, 24, 36 or 60 months. (The business, in turn, commits to certain SLAs.)

This means unlike month-to-month SaaS products, the business can usually rely on a certain amount of guaranteed income over two or more years based on the length of the contract.

The annual amount owed by the customer is called the Annual Contract Value or ACV and is the key revenue metric for this type of SaaS product.

A related metric is Total Contract Value or TCV, which is the total value of the customer contract over the life of the contract.

So if a customer signed up for a 3-year contract worth a TCV of $300,000, the ACV would be $100,000.

In particular, you want to track ACV bookings. ACV bookings are the total value of all new signed customer contracts. Simply put, a booking exists when a customer agrees to spend money with you. So bookings are the amount of money customers have committed to spend with the business.

For example, a customer signs a 3-year contract worth a total of $36,000. Whether the customer pays you annually, monthly, quarterly or the entire amount up front, the ACV bookings value is $12,000.

Why are ACV bookings important? Because it allows you to accurately track money customers have committed to spending on your product (regardless of how they are actually billed and pay for it).

More to the point, ACV bookings are a demonstrator of the demand for your product. It tells you how the market is responding and committing to your product — its features, its user experience, it’s capabilities — and as such it’s an important metric for measuring the growth and success of your product.

In other words, how do you know the features you’re building and the user experience you’re delivering are actually resonating with customers from a business perspective? That’s what ACV bookings tell you.

Using MRR or ACV to Drive Growth

So how can you as a product manager impact these critical metrics of MRR and ACV, and thus drive growth?

  1. Identify and deliver features new customers want.
  2. Identify and deliver features that encourage existing customers to upgrade to higher price points.
  3. Up-sell and cross-sell add-ons and product extensions that increase recurring revenue or boost ACV — some customers may be willing to pay extra for value-added features and services.
  4. Look at how you segment customers. It may be worthwhile to look at different ways to segment your customers and package your product’s features into pricing plans that are more specifically targeted to these customer segments, and thus deliver more growth and profitability.
  5. Offer scalable or metered pricing. Does it make sense to offer pricing that scales by a unit metric, like number of users, events, transactions, campaigns, etc.? Some customers may be willing to pay more for your product than others to get more of the same feature or capability.
  6. Reduce churn. This is the #1 growth killer. Are you losing customers because you’re missing critical features? Because they abandon after onboarding? Because valuable features are not easily accessible to the user? Because you’re targeting the wrong set of customers?.

By analyzing the above, you can identify what are the things you can do from a product perspective to drive growth, and then craft your product strategy and roadmap to accomplish those goals.

COGS and Gross Margins

When a customer pays for your product, you generate revenue. Gross margin is the revenue left over after the costs associated directly with the delivery of the product or service are paid for.

The costs directly associated with the delivery of the product or service are called COGS or cost of goods sold.

Unlike a manufactured product, where COGS include materials and direct labor, COGS for a SaaS product can be a bit tricky to figure out. Generally, they include items that contribute directly to the delivery of the service. (Remember: SaaS = “software as a service”).

COGS for a SaaS product typically including things like:

  • Infrastructure, hosting, monitoring costs
  • Licenses and fees for 3rd party embedded apps, integrations or other back-end services
  • Payment processing fees
  • Commissions and royalties to affiliates and partners

There could be others. (Check with your Finance department.)

Gross margin is the cost of goods sold subtracted from revenue. It’s typically represented as a percentage of revenue.

Gross margin is critical because it’s used by your executive team and the company’s Board and investors to determine how much the company has left to cover operating expenses and reinvest in the business after delivering the service to the customer.

Gross margin is also an indicator of customer lifetime value, which in turn is a prediction of all the value a business will derive from its entire future relationship with a customer. (More on LTV in a bit…)

Gross margin is why a $10M SaaS company can be more valuable than a $100M brick and mortar company.

As a product manager, you can look at ways to reduce COGS by finding more cost-effective vendors, reducing fees or finding more efficient ways to deliver your product.

Unit Economics

Unit economics look at the most basic elements of a product’s business model and provides insight into whether the business will be profitable.

And profitability is a pretty important measure of success.

Unit economics express revenues and costs on a per unit basis. For a SaaS business, that unit is typically the user or a customer account.

One of the most fundamental unit economics is LTV or customer lifetime value (or CLV or CLTV).

LTV is a great measure of how “sticky” your customers are — whether they’ll keep paying you and for how long. LTV is also a key data point in determining company profitability.

For a product manager, LTV allows you to calculate the profitability of a single customer or segment of customers. You can then use this analysis to identify your most profitable customers and double-down your product related efforts for those customers or perhaps identify upsell/cross-sell opportunities.

Key Takeaways

Remember: Your job as a product manager is to drive business growth through the delivery of monetizable customer value.

To do this, you need to:

  • Learn the business of your product and the key levers of growth.
  • Understand the underlying economics of your product’s growth.
  • Focus on the right set of actionable metrics.
  • Marry these with your VOC insights to build robust business cases for your product ideas.
  • Craft product strategy and your product roadmap such that they show how you will drive growth via these business metrics.

This is how you can actually QUANTIFY the value you as a product manager bring to your company!

To help you, I’ve created this helpful 2-page SaaS Metrics Quick Reference Guide for Product Managers that you can download totally for free. Print it out, post it on the wall of your cube or office so that way you have it conveniently available as a reference at all times.

Get the SaaS Metrics Quick Reference Guide for Product Managers >>

P.S. If you’re not managing a SaaS product, so these metrics may not apply, of course. You just need to identify they key business metrics for your product that will help you shape your product strategy and drive its business performance.

The secret ingredient to getting product innovation done

So you’ve probably heard of “earlyvangelists”.

(No? Read this post by Steve Blank, who coined the term.)

In Lean Startup circles, we hear a lot about finding this special breed of customers. Why?

Because they’re the ones willing to make the initial bet on the startup. They’ve bought into the startup’s vision and potential. They’re not just buying a version of the product, but the entire vision of the startup. This is what keeps them committed even if the startup screws up a few times.

They are the true visionary customers talked about in the technology adoption lifecycle.

So a lot of focus is put in identifying, finding and nurturing these earlyvangelists in the form of testing customer and problem hypotheses, testing solution hypotheses, finding problem/solution fit, creating an MVP, and getting true customer validation by finding a handful of customers who are actually willing to pay you for your solution — the “earlyvangelists”.

Now, juxtapose this with traditional product management.

When I started out in product management, I was introduced to the technology adoption lifecycle. I read about it in books. People talked about it in conferences. “You must find those visionary customers and early adopters,” experts said in their presentations.Cool.


Problem was: no one taught me how to get these magical customers.

Business school didn’t teach me how to get earlyvangelists.

Product management didn’t teach me how to get earlyvangelists.

Instead, what I was told was to develop a business case. Write an MRD. Create a business plan.

Business school told me I was supposed to do this. Smart consultants and well-meaning senior executives and mentors reinforced this. Elaborate PMO processes required this.

Want resources for your product idea? Show us your business case.

So what’s wrong with that? On the surface, it made sense. Unlike a startup, which is searching for a sustainable business model, a company is executing an existing business model.

On the surface, it made sense. Unlike a startup, which is searching for a sustainable business model, a company is executing an existing business model.

Shareholder returns, customer value, and employee paychecks depend on the successful execution of this business model.

So the company needs to evaluate its investments in terms of risk to this business model. A company needs to know whether to dedicate its resources to project A or B. To do that, it needs to know which has the better payoff.

Good intentions.

But here’s what actually happened.

Product managers began spending loads of time writing multi-page MRDs, crafting business case slideware, and crunching through multi-year financial “projections”. These documents were filled with unvalidated assumptions or HiPPO driven convictions.

“How the heck can I figure out whether customers will buy the product before it even exists?” they’d ask. “How can I figure out how much money it will make when no customer has bought it yet?”

The product manager would torture the spreadsheet, try and convince finance of adoption rates and growth trajectories based on mere guesses, and go to Engineering/IT for estimates.

“You need to give me requirements,” Engineering would say. “If they’re not documented, there’s no way I can give you estimates.”

So the product manager would then start writing an MRD / PRD / BRD / <stick your 3-letter acronym here>. Ah, the joy…

And under pressure to get “accurate” estimates, they’d pack in as much detail as possible, essentially guessing at the features and functionality that would be needed.

And every minute the product manager spent preparing the business case, writing the MRD/PRD or torturing the spreadsheet was valuable time not spent with customers.

So it’s no surprise that in a recent survey filled out by over 40 product managers who enrolled in my online course, Idea To Revenue Masterclass, they listed the following as their biggest product innovation challenges:

#1 Biggest Innovation Challenge: Testing product ideas without having a product.

Meaning testing with both customers and internally within their organizations. They need ways to test their understanding of the market, as well as evaluate the revenue potential for a product opportunity, but without having a product already.

“My number one product management challenge is creating business requirement documents on new products and demonstrating a return on investment for 1/3/5 years without releasing the product.” — survey response

#2 Biggest Innovation Challenge: Alignment, buy-in and communication.

How many people does it take to change a lightbulb?

(Or maybe the question is: how many people does it take to get approval to change the lightbulb? Ha!)

This challenge is a close second to the first. Product innovators are challenged with communicating product strategy to get buy-in, getting executive support for their product plans, aligning teams within the company to support new products, and managing communication across multiple stakeholders.

“In a growing organization, with lots of ‘people of interest’, communicating what you are building and why is a huge challenge.” — survey response

In a blog post titled, Why Internal Ventures are Different from External Startups, Henry Chesbrough argued:

The internal venture must fight on a second front at the same time within the corporation. That second fight must obtain the permissions, protection, resources, etc. needed to launch the venture initiative, and then must work to retain that support over time as conflicts arise (which they will).

#3 Biggest Innovation Challenge: Resources.

We can never have too many resources, can we? 🙂

Working with resource constraints is a fact of life. But product innovators feel this acutely so.

They’re pushed to accelerate time to market, yet are challenged with selling the business case for the right mix of resources to do just that.

And, of course, this leads to the chicken-or-egg dilemma from challenge #1:

We need a product to test whether customers value it…

But we need customer validation in order to get the resources to build the product!

“My #1 product planning challenge is getting and retaining key resources to minimize time to market consistent and aligned with company priorities.” — survey response

So what’s the solution?

This brings us back to “earlyvangelists”…

Lean practices can and should be adopted and adapted to pursue product innovation inside companies. But product innovators actually need to find two types of earlyvangelists:

  • Earlyvangelist customers.
  • Internal stakeholder advocates, a.k.a. “internalvangelists”.

One of the biggest factors that can derail any new product endeavor is lack of internal support. In product innovation, lack of stakeholder traction can often be a bigger roadblock than customer traction.

These stakeholders not only may have access to essential information and resources but also be able to influence key decision makers whose support is critical to the success of your product initiative.

The larger the organization you work in, the more stakeholders you’re likely to have. It’s important to identify who these folks are and make sure you’re not only bringing them along but in fact converting them into advocates — evangelists — for your product initiative.

Product management didn’t teach me how to get internalvangelists.

The good news is that a lean approach that fuses customer development methods with sound product management practices can be used to get early customers AND build the business case, create alignment, and cultivate internalvangelists iteratively.

Lean product management can get you “earlyvangelists” and “internalvangelists”.

Here’s an example:

Customer learning driven investment strategy

The approach calls for spending plenty of time with customers in a methodical way, systematically testing assumptions at each phase, while also having regular check-ins with folks internally.

Each stage is informed by learnings from the previous stage — “mini business cases”, if you will, at each milestone, instead of wasting time writing a big tome of a business case up front.

Requirements for delivery need only be done when there’s a clear signal to do so. For example, if you find there’s no problem/solution fit, no need to write detailed requirements to build out an MVP or do financial projections. Only on achieving problem/solution fit does it make sense to spend the time doing those activities.

This customer learning driven approach makes for a more market-informed investment approach to the product strategy. This makes it easier to garner, maintain and accelerate stakeholder buy-in, because:

(1) Each investment stage is grounded in real customer data, resulting in less assumptive and more empirically based investment asks.

(2) Smaller continual investments that deliver continuous tangible ROI throughout the process are easier for folks to digest and support than a large bloated one upfront.

(3) Stakeholders continually feel involved in the process, increasing confidence to persevere.

There are surely other variants to this approach. The point here is that lean principles can be fused with sound product management practices to:

  • Test product ideas without a product.
  • Build the business case iteratively.
  • Get alignment and buy-in, and create internalvangelists.
  • And get those magical earlyvangelists!

An MVP is not the smallest collection of features you can deliver

Source: Spotify

Source: Spotify

There’s a lot of discussion and confusion about what is and isn’t a minimum viable product (MVP).

Worse, many execs have latched on to the term without really understanding what truly constitutes an MVP — many use it as a buzzword, and as a synonym to mean a completed version 1.0 ready to be sold to all customers.

Buzzwords are meaningless. They represent lazy thinking. And using “MVP” to mean “first market launch” or “first customer ship” means you’re back to the old waterfall, traditional project-driven software development, sales-focused approach. If that’s your approach, fine. Just don’t call what you’re delivering an MVP.

On the flip side, lots of folks in the enterprise world, including in product management, over-think the term. It gets lost in the clever nuances of market maturity, and a long entrenchment in the world of release dates and feature-based requirements thinking.

Many folks think of MVP as simply the smallest collection of features to deliver to customers. Wrong. It’s not.

The problem with that approach is it assumes we know ahead of time exactly what will satisfy customers. Even if we’ve served them for years, odds are when it comes to a new product or feature, we don’t.

Now, the challenge with the concept of a minimum viable product is it constitutes an entirely different way of thinking about our approach to product development.

It’s not about product delivery actually — in other words, it’s not about delivering product for the sake of delivering it or to hit a deadline.

An MVP is about validated learning.

As such, it puts customers’ problems squarely at the center, not our solution.

Reality check: Customers don’t care about your solution. They care about their problems. Your solution, while interesting, is irrelevant.

So if we’re going to use the term “MVP”, it’s important to understand what it really means.

Fortunately, all it takes to do that is to go back to the definition.

Download The Handy Primer “What Is An MVP?” >>

Minimum Viable Product (MVP) is a term coined by Eric Ries as part of his Lean Startup methodology, which lays out a framework for pursuing a startup in particular, and product innovation more generally. This means we need to understand the methodology of Lean Startup to have the right context for using terms like “MVP”. (Just like we shouldn’t use “product backlog” from Agile as a synonym for “dumping ground for all possible feature ideas”.)

Eric lays out a definition for what is an MVP:

“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

Eric goes on to explain exactly what he means (emphasis mine):

MVP, despite the name, is not about creating minimal products… In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

Second, the definition’s use of the words maximum and minimum means an MVP is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

Let’s break this down.

1. An MVP is a product. This means it must be something delivered to customers that they can use.

There’s a lot that’s been written about creating landing pages, mockups, prototypes, doing smoke tests, etc., and considering them as forms of MVPs. While these are undoubtedly worthwhile, and certainly “lean”, efforts to gain valuable learnings, they are not products. Read Ramli John‘s excellent post on “A Landing Page Is NOT A Minimum Viable Product“.

A product must attempt to deliver real value to customers. So a minimum viable product is an attempt — an experiment — to deliver real value to customer.

Which leads us to…

2. An MVP is viable. This means it must try to tangibly solve real world and urgent problems faced by your target customers. An MVP must attempt to deliver value.

So it’s not about figuring out the smallest collection of features. It’s about making sure we’ve understood our customers’ top problems, and figuring out how to deliver a solution to those problems in a way that early customers are willing to “pay” for. (“Pay” in quotes as it depends on your business model.)

If we can’t viably solve early customers’ primary problems, everything else is moot. That is why an MVP is about validated learning.

3. An MVP is the minimum version of your product vision. A few years ago, I had to build an online form builder app that would allow customers to create online payment forms without the need to write any HTML or worry about connecting to a payment gateway. Before having our developers write a single line of code to build the product, we first offered customers the capability as a service: we would get their specs, and then manually build and deliver each online payment form one-by-one, customer-by-customer. Customers would pay us for this service.

This “concierge” type service was our MVP version of our product vision. Of course, it wasn’t scalable. But we learned a heck of a lot: most common types of payment forms they wanted, what was most important to them in a form, frequency of wanting to make changes, reporting needs, and how they perceived the value of the service.

We parlayed these learnings into developing the software app itself — which, by the way, we delivered as an MVP to early customers to whom we had pre-sold the software product. (Yes, we delivered two different types of MVPs!)

Whether you take a “concierge” approach or your MVP is actual code, it most definitely does NOT mean it’s a half-baked or buggy product. (Remember viable from above?)

It DOES mean critically thinking through the absolute necessary features your product will need day 1 to solve your early customers’ top problems, focusing on delivering those first, and putting everything else on the backlog for the time being. It also means being very deliberate about finding those “earlyvangelists” that Steve Blank always talks about.

Ultimately, the key here is “maximum amount of validated learning”. This means being systematic about identifying your riskiest assumptions, formulating testable falsifiable hypotheses around these, and using an MVP — a minimum viable product version of your product vision — to prove or disprove your hypotheses.

Now, validated learning can certainly be accomplished via a landing page, mockup, wireframes, etc. And it may make sense to do these things. Super. But don’t call them MVPs, because while they may deliver value to you and your product idea, they’re not delivering actual value to the customer.

At the same time, the traditional product management exercise of identifying all the features of a product, force ranking them, and then drawing a line through the list to identify the smallest collection to be delivered by a given timeframe is not an MVP. Why? Because this approach is not predicated on maximizing validated learning. If you’re going to pursue this approach, go ahead and call it Release 1.0, Version 1.0, “Beta”, whatever. But don’t call it an MVP.

An MVP is about not just the solution we’re delivering, but also the approach. The key is maximizing validated learning.

I’ve created a handy primer on what is a minimum viable product. Download it below. I hope it helps you to become a pro at defining an MVP for your next great product idea!

Download The Handy Primer “What Is An MVP?” >>

Roadmaps Are Not A Popularity Contest

By Bruce McCarthy

I write a blog called User>Driven and my Twitter handle is @d8a_driven, so you would think I like the idea of setting roadmap priorities based primarily on customer requests. You would be wrong.

Dell Idea Storm

Back in 2007, Dell created an online customer forum where people could post “innovative” ideas for how Dell could improve their offering and others could vote on those ideas. I wrote at the time that I thought it was a very bad idea.

In my opinion, Dell had fundamentally misunderstood the uses of customer data and the best ways to collect it. The proof of that was that the voting had been hijacked by a small number of very vocal open source advocates. Checking back in this week, I see it mostly consists of >complaints and suggestions for minor tweaks to design and packaging. Interestingly, they have made it impossible to see which ideas have the most votes.

Tracking Customer Requests

Over 20 years as a product person, I’ve developed an objective scoring methodology for prioritizing ideas. (See my presentation on Slideshare.) It focuses on ranking proposed improvements or changes as to how much they contribute to strategic goals compared to their implementation cost.

So am I arguing for ignoring customer input? Not at all. If improving your customer retention rate is one of your strategic goals, it might make sense to include number of customer requests in your scoring. I know more than one product person who has tracked popularity as input to their planning and tools like UserVoice make this easier than ever.

Your Customers Can Hold You Back

Tracking customer requests can easily create a false sense of security for a product person, though. You’re collecting real, live market data, right? It’s all neatly tallied and summarized in your PowerPoint, right? Ok, fine, but bear these very real limitations in mind.

  • As Dell Idea Storm showed, you have to recognize that not all votes are equal. Vocal customers are not necessarily paying customers. And even if you could get evenly-distributed input, most customers are small. Should you be focused on their needs or on the needs of your largest customers? Tailor your data collection to your strategic goals and weight the input accordingly.
  • Expect incremental input only. Henry Ford famously said that if he’d asked customers what they wanted, they would have answered: “a faster horse.” Customers will give you ‘better, faster, cheaper’ advice, but are unlikely to propose a break-through idea that uses technology to solve problems in new ways.
  • Beware “featuritis.” We all complain about the lengthy list of features in Microsoft products that we never use but make things complex, crash-prone and slow. Where does all of this bloat come from? Customer requests. Beware of adding features that only a few will use but many will have to put up with.
  • Existing customers tell you nothing about non-buyers. People who are in your target market but don’t respond to your messaging or solution are your best source for information on how to expand your appeal. Reach out to people who evaluated your solution but decided to go with the competition or do nothing (this is called “win/loss analysis”) and ask them about their business, their problems, and why they went a different direction.
  • Existing customers won’t help you penetrate new markets. If you want to grow beyond your current market niche into other verticals or up to larger customers, engage with those people directly and, rather than talk about your solution, ask them about their needs and wants. Develop an understanding of the personas in that space and what they need and you will be on your way to designing a solution that will capture that market.

One Way To Use Popularity To Prioritize

Ok, yes, I did create a forum where people could vote on what a roadmapping tool for product people should do when setting out to design Reqqs, my forthcoming tool for product people. But that was different. Really. Let me tell you why.

Before putting up the forum, I spent a lot of time interviewing other product people, asking them about their jobs, what were they trying to achieve, and what were their main obstacles and frustrations. I did this until it was pretty easy to guess what the next person would say. That kind of qualitative data helped me define the essence of the product as a roadmapping tool for product people.

The next step was to figure out which of the 10 or so problems I had uncovered were the most common and most painful. UserVoice’s voting feature is perfect for that. I set up the forum, pre-populated it with my 10 things, set up each user with 10 votes to allocate however they liked, and began promoting it on product discussion boards like those on LinkedIn. This limited my audience to qualified prospects, all of whom were equal in my eyes since none were yet a customer.

With the hard work of using interview data to develop innovative ideas done, a survey within my target market provided the quantitative data needed to determine the top few of those ideas that would form the MVP. As it happens, potential customers highlighted prioritization as the number one thing they wanted help with, and that will be the core feature of the initial release of Reqqs.

Customer Requests Are But One Input

So, yes, customer input can be a powerful tool to aid in decision-making. But like all superpowers, this one must be used responsibly. Set your strategic goals first, then decide which items from your utility belt will help you toward those goals.


Bruce McCarthy is a serial entrepreneur, 20-year product person, and sought-after speaker on roadmapping and prioritization. By day, he is VP of Product for NetProspex, but only you know his secret identity as Chief Product Person for Reqqs, the smart roadmap tool for product people (forthcoming). He is available for advice on product management topics of all kinds.

How to Identify (and Mitigate) the Riskiest Parts of Your Product Strategy

Any product strategy is fraught with risks.

Three of the biggest risks to a startup are tech risk, market risk, and ego risk. Corporate innovation faces additional risks: resource risk (resources need to be assigned), implementation risk (need the right implementation skill sets and tools), operational risk (the product needs to be operationally cost-effective) and internal risk (need buy-in and alignment from internal stakeholders).

Identifying these risks and de-risking them are crucial to the success of any product strategy. One of the most compelling things to me about Lean Startup is the focus on systematically de-risking elements of a product innovation through experiments and Validated Learning — one of the five core principles of Lean Startup.

Of course, this is predicated on identifying each of the most essential elements of your product vision. The Product Canvas has been great in helping me do just that. Its 1-page format facilitates having important conversations with my partners and stakeholders to gather their feedback.

“[The Product Canvas] is a smart way for each product manager to have a succinct snapshot of what it means to ‘be’ a product. It is a great way to focus and present to others the critical elements of a product.”

Having conversations with my internal partners are critical to helping me uncover risks and assumptions that I may not have thought of.

As I started doing this, the question became how to capture these risks, track progress in de-risking them, and communicate back that progress?

Here, again, is where I found the principle of Innovation Accounting from Lean Startup appealing, which Eric Ries describes it in his book:

To improve entrepreneurial outcomes, and to hold entrepreneurs accountable, we need to focus on the boring stuff: how to measure progress, how to setup milestones, how to prioritize work. This requires a new kind of accounting, specific to startups.

In other words, Innovation Accounting provides a framework to measure and communicate progress. The unit of progress is a learning milestone, “an alternative to traditional business and product milestones.” (From the book.)

This last part really appeals to me. Developing a grounded, workable product strategy cannot be moved forward by a date-driven approach, and I’ve seen too many new product development efforts descend into chaos, and even outright failure, by the traditional project management process.

Again, from Eric’s book:

“Learning milestones are useful for entrepreneurs as a way of assessing their progress accurately and objectively; they are also invaluable to managers and investors who must hold entrepreneurs accountable.”

I’d argue we could replace “entrepreneur” with “product manager” or “product innovator”, and “investors” with “executives”.

But again, the question is how to actually do this in practice. Let’s go back to the issue of capturing and tracking assumptions and risks.

At first, I used stickies:


That worked great as a start. Especially for brainstorming or a live update if a colleague or stakeholder was in the room with me.

But not so much for tracking ongoing progress. Plus, translating all that into an update report to share with someone not in the room is just too much work, quite frankly.

I needed something that doubled up as a tool to use and a way to communicate progress, similar to the Product Canvas.

Then I came across Ash Maurya’s blog posts on his Lean Stack approach to doing Innovation Accounting. I liked how he’s mapped the Build-Measure-Lean cycle into a Kanban style approach to track his progress.

After experimenting with his approach, I developed a version that worked for me as a product manager. I’ll explain via a made up, yet tangible, example.

Below is an initial Product Canvas for an online bill payment app that allows customers of a bank to view all their bills in one place and pay directly through their bank account.


Now, as product manager, I should be intimate with my customer base. So let’s say their input was the genesis for this product — e.g., lots of customer requests asking to enhance the existing bill pay service with the ability to view and pay utility bills.

As such, initially I may not see my Customer Segment or Problems as the highest risks. But I do need to identify my early adopters.

In other words, I feel confident in the initial demand, but I’m not certain which of my customers will be most likely to switch their behavior to paying all their bills through our bank. (After all, people don’t always do what they say.) So I highlight this as a risk.

After speaking with my stakeholders, I identified numerous additional risks, which I highlight via PowerPoint’s comments feature:


All I need to do is click on any comment to view the details:


Now, to track and communicate progress on how risks are being addressed, I use a Kanban style board similar to what Ash uses, called the Validated Learning Board.


Risks and assumptions are placed in the Backlog column. When I begin working on a particular risk card, I move the card to the IN PROGRESS section. I place a blue card under the Build column to note the experiment I’m conducting. On the card, I note the experiment that I’m running and the falsifiable hypothesis of my experiment.

If an experiment serves to tackle more than one risk, no problem. You’ll see an example in the image above representing that.

Once I start the experiment (e.g., interview the first customer, or day 1 of user testing, etc.), I move the card to the Measure column.

Once the experiment is over, I move the risk card to the Learn/DONE column, and color code it green if the assumption has been validated or risk de-risked, and red if not.

If I’m running multiple experiments simultaneously, I separate them with a line.


I don’t capture all the details of my experiment on the cards. This is meant for a high-level progress view. Details of the experiment can be presented on its own slide or report.

Finally, I need to make sure I’m systematically identifying the right set of internal stakeholders and capturing their feedback. I covered that in my blog post on Stakeholder Development, in which I talked about the Stakeholder Development Tracker.

As I continue to get feedback from both the experiments and further internal conversations, I use these learnings to update the product strategy represented in the Product Canvas.

A team can use these artifacts to track progress on, say, the wall of an agile room, while also quickly converting them into 3 quick slides to provide a high-level update to anyone on the progress of the product strategy.

How I Document My Product Vision

Over the last many years, I’ve been experimenting with applying Lean Startup andThe Lean Startup Customer Development concepts to product management. I first wrote about this here. Some time ago, I wrote about the challenges I and other product professionals have faced with the traditional approach of writing a business case.

One area where I had always struggled with was finding a simple and quick way to sketch out my product ideas. I used PowerPoint, Word, Google Docs, but they never really worked effectively. Often times my original notes would grow into a bloated morass of detailed thoughts about features, customers, marketing, partnerships, technologies, etc. There was no structure. Worst of all, if I wanted to share them with someone, I’d have to spend time figuring out how to translate them into something readable, since no one would be able to decipher my chicken scratch.

Before writing a requirements doc or business case, what I really wanted was a way to not only quickly capture a product idea in a structured manner, but also use the same format to share it with others to elicit feedback.

So you can imagine my delight when I came across Alex Osterwalder’s Business Model Canvas several years ago.

Business Model Canvas

What’s great about it is since it’s a single page, one can quickly jot down the basics of any business model, and it’s easy to share and more likely to get read than a PowerPoint deck or a Word doc. The single page also forces brevity: there isn’t a lot of space for a laundry list of features – you need to distil down your idea to its most essential building blocks.

Love at first sight, I started trying to use it for my products. But I ran into a few challenges. I found that while it does a good job capturing the key elements of a business, it’s not as customer focused as I would have liked because there was no place to capture the customer problems I was trying to solve or identify potential early adopters. There was also no place to capture my envisioned solution, and I often got confused between Channels and Customer Relationships.

That’s when I came across Ash Maurya’s Lean Canvas, an adaptation of the Business Model Canvas he created for his web startups.

Lean Canvas

Ash has correctly put the focus on customers and their problems. I also like that he calls out Unfair Advantage, which to me means competitive differentiation. This is especially true for a startup that may be fighting bigger, more established players.

So I started using his Lean Canvas, but ran into a new set of problems as a product manager:

Resources: Ash has left this out from Alex’s original version. I can understand this with respect to startups, but as a product manager working in an organization, it was important to me to identify which resources – platforms, systems, departments, vendors, etc. – I would need to make my product idea a reality.

Readability: When walking someone through a product or business idea, my inclination is always to start with the market opportunity, which means customers, their problems, and how we can solve them. I found neither of the above two canvases easily lend themselves to that flow. I’d have to start at the right-most column and then jump back left. This is non-intuitive to most English-speaking readers, and I found I’d quickly lose my audience as I criss-crossed columns.

Two other challenges I ran into as a product manager:

Stakeholders: Product Managers have to deal with internal stakeholders. The larger the org, the more. Often times a new product idea needs an executive sponsor. In my experience, I’ve found that the more I’m mindful of who are my key stakeholders, the greater the chance of internal support for my product.

Non-Revenue “Products”: Some products managers are responsible for initiatives that aren’t directly revenue generating, but do provide tangible business value, like improving CSAT, driving referrals, etc. I’ve lead several like that.

So I decided to create my own iteration that I felt was more suitable to me as a product manager, that I call the Product Canvas:

This version puts the customer and market on the left-hand side, which not only addresses the readability issue but also supports more intuitively how I think through a product opportunity. I can start with the customer and their problems on the left, and work my way toward the right to ultimately figure out how I’m going to deliver on the solution.

Here’s a brief description of each block and the order in which I typically approach them:

1. Customer Segment: Who is the target customer of our proposed product? This could be the company’s entire customer base, a segment, or a new market or vertical. Ash recommends using a separate Lean Canvas for each segment where one has multiple segments in mind, and I think that’s good advice as a starting point.

1a. Early Adopters: For any new product opportunity, it’s important to identify early adopters. There is already a ton written about this. While identifying early adopters is implied in the Lean Canvas, I wanted it called out explicitly, as I’ve found even in existing organizations there is a tendency to think any new product idea is applicable to all customers.

2. Problem: A brief description of the top problems we’re addressing. I try to limit this to at most 3.

2a. Existing Alternatives: How is the customer solving this problem today? This may not be just direct competitors. For example, in the early days, Quicken’s competition was not only other accounting software, but also checkbooks, and pen and paper.

3. Unique Value Proposition: How are we uniquely going to solve our customers’ problem(s)? This is the elevator pitch: the one sentence that clearly states the value we’re providing to our target customers.

4. Solution: What are the most essential features of our solution that will deliver on our UVP? This is not an exhaustive feature list. I try to limit it to the top 3 elements of my proposed solution.

5. Channels: How will we get (acquire), keep (retain), and grow (sell more to existing) customers? What is the marketing and sales strategy?

6. Revenue Streams/Business Value: How will we make money? What’s our pricing strategy? If this is not a revenue generating product, what other business value is it providing? Improving customer satisfaction? Customer lifetime value? Market positioning? Competitive differentiation? Operational efficiencies?

7. Key Metrics or Success Factors: What are the most important metrics that will tell us that we’re successful? Signups? Conversions? Referrals? CSAT? NPS? These are the metrics that are driving #6 above.

8. Key Resources: What are the most critical internal resources we need? These could be platforms, systems, business processes, departments. Are there external partners we need to rely on?

9. Cost Structure: What are the key cost drivers? Software/IT development? Customer acquisition? Account management? Hiring and talent development? This is also a good place to capture a back-of-the-envelope break-even calculation.

10. Unfair Advantage: This is the distinctive competence or advantage that your product has over other solutions in the marketplace. It’s something your product does better than any other, something that can’t be easily copied. It could be intimate knowledge of an industry, personal authority or brand, a business process or competence, a patent, or some other intellectual property.

After experimenting with using this Product Canvas as a product manager, I started sharing it with folks, asking them to use it, and the feedback has been very encouraging.

Feel free to download it here.

Before Product/Market Fit comes Opportunity/Company Fit

In his book, Running Lean, Ash Maurya presents a workflow for taking a product from idea to launch to Product/Market fit.

Ash Maurya workflow
In the Problem/Solution Fit stage, you are trying to answer the question, “Do you have a problem worth solving?” Ash breaks this down further into three questions:

  • Is the problem something customers want solved? (must-have)
  • Can it be solved? (feasibility)
  • Will they pay for it? If not, who will? (viability)

Problem/Solution Fit is pursued by capturing your business model hypothesis and then doing Customer Discovery via problem interviews and solutions interviews with customers. Once you’ve validated from customers that you have a viable problem worth solving, you move into Product/Launch Fit.

In the Product/Launch Fit stage, you are trying to answer the question, “Are you ready to learn from customers?” Key activities pursued here are reducing down your MVP, getting to Release 1.0, defining your key metrics, and continuous deployment. The purpose here is to lay the critical groundwork to maximize speed and learning for future iterations, and to establish “just enough” traction among customers to support learning.

Finally, in pursuing Product/Market Fit you are trying to answer the ultimate question: “Have you built something customers want?” This is where the rubber hits the road, and you’re validating your complete product. Identifying the “right” metric or set of metrics, prioritizing your feature backlog, and ensuring retention and getting paid are critical to the success of achieving product/market fit.

This Lean Startup workflow is one that could be used by a product manager pursuing a new product idea or looking to introduce an existing product into a new market. After all, the product manager in such a situation must be able to answer the same set of questions about who is the customer, what customer problem is the product trying to solve, and will enough customers care enough to pay for the solution. The product manager typically starts with some sort of informed hypotheses to answer these questions, which form the basis of the product vision. And the product manager must stay in close touch with customers to validate whether the product is truly something they want.

I feel there is one critical step missing in this workflow, though. It has to do with the unique situation product managers find themselves in versus entrepreneurs. Whereas an entrepreneur is trying to discover a business model that works, a product manager is typically an employee in an existing company already executing a repeatable and scalable business model. As such, the new product idea being pursued by the product manager could represent a change to the company’s existing business model. As such, because of the potential impact on the company’s existing business model, a critical consideration for the product manager pursuing a new product is whether the new product is aligned with the company’s corporate strategy.

In his book, Product Leadership: Creating and Launching Superior New Products, author Robert G. Cooper talks about the need for new product development efforts to be closely linked to the overall business strategy. In Beyond the Core, Chris Zook makes the case that the further a new product or business idea is from the core business — what he calls an “adjacency move” — the riskier it is and more prone to failure. What this means is that the more closely aligned the new product idea is to the company’s existing business strategy, the more favorably it will be looked upon by the company’s executives. This does not mean something completely outside of a company’s existing core will never be approved. But it does mean the bar to get that buy-in is much higher.

So in order for the new product idea to garner the necessary stakeholder support, its business case must be able to articulate the business opportunity it presents to the company, how it fits (or departs) from the company’s current business model and strategy, and the risks associated with pursuing it.

As such, Ash’s workflow can be modified as follows:


I call this stage Opportunity/Company Fit.

Critical questions for the product manager to figure out are:

  • Does the idea align with the company’s strategic goals?
  • Who do I have to convince to get buy-in?
  • Can I get a sponsor? Who?

Just like with using customer validation to achieve Problem/Solution Fit, I’m sure it’s possible to use lean principles to achieve Opportunity/Company Fit.