My product management toolkit (28): testing price sensitivity

Normally when I talk to other product managers about product pricing, I get slightly frightened looks in return. “Does that mean I need to set the price!?” or “am I now responsible for the commercial side of things too!?” are just some of the questions I’ve had thrown at me in the past.

“No” is the answer. I strongly believe that as product managers we run the risk of being all things to all people — see my previous post about “Product Janitors” — and I therefore believe that product people shouldn’t set prices. However, I do believe it’s critical for product people to think about pricing right from the beginning:

  • Do people want the product?
  • Why do they want it?
  • How much are they willing pay for it?

Answers to these questions will not only affect what product is built and how it’s built, but also how it will be launched and positioned within the market. I’ve made the mistake before of not getting involved in pricing at all or too late. As a result, I felt that I was playing catchup to fully understand the product’s value proposition and customers’ appetite for it.

Fortunately, there are two tools I’ve come across which I’ve found very helpful in terms of my comprehending the value a product is looking to achieve — both from a business and customer perspective: the Van Westendorp Pricing Sensitivity Meter and the Conjoint Analysis respectively.

The Van Westendorp Pricing Sensitivity Meter has helped me to learn about the kinds of pricing-relating customers to ask (target) customers:

  • At what price would you consider the product to be so expensive that you would not consider buying it? (Too expensive)
  • At what price would you consider the product to be priced so low that you would feel the quality couldn’t be very good? (Too cheap)
  • At what price would you consider the product starting to get expensive, so that it is not out of the question, but you would have to give some thought to buying it? (Expensive/High Side)
  • At what price would you consider the product to be a bargain — a great buy for the money? (Cheap/Good Value)

The aforementioned Van Westendorp questions are a good example of a so-called “direct pricing technique”, where the pricing research is underpinned by the assumption that people have a basic understanding of what a product is worth. In essence, this line of questioning comes down to asking “how much would you pay for this (product or service)?” Whilst this isn’t necessarily the best question to ask in a customer interview, it’s a nice and direct way to learn about how customers feel about pricing.

Example customer responses to the Van Westdorp questions — Taken from:

The insights from applying these direct questions will help in better understanding price points. The Van Westendorp method identifies four different price definitions:

Point of marginal cheapness (‘PMC’) — At the point of marginal cheapness, more sales volume would be lost than gained due to customers perceiving the product as a bargain and doubting its quality.

Point of marginal expensiveness (‘PME’) — This is a price point above which the product is deemed too expensive for the perceived value customers get from it.

Optimum price point (‘OPP’) — The price point at which the number of potential customers who view the product as either too expensive or too cheap is at a minimum. At this point, the number of persons who would possibly consider purchasing the product is at a maximum.

Indifference price point (‘IPP’) —Point at which the same percentage of customers feel that the product is getting too expensive as those who feel it is at a bargain price. This is the point at which most customers are indifferent to the price of a product.

Range of acceptable pricing (‘RAI’) — This range sits between the aforementioned points of marginal cheapness and marginal expensiveness. In other words, consumers are considered likely to pay a price within this range.

Van Westendorp price sensitivity meter (example) — Taken from:


In addition to the Van Westendorp Price Sensitivity Meter, I’ve also used Conjoint Analysis to understand more about pricing. Unlike the Van Westendorp approach, the conjoint analysis is an indirect pricing technique which means that price is combined with other attributes such as size or brand. Consumers’ price sensitivity is then derived from the results of the analysis.

Sample conjoint analysis question — Taken from:
Sample conjoint analysis question — Taken from:


When designing a conjoint analysis study, the first step is take a product and break it down into its individual parts. For example, we could take a car and create combinations of its different parts to learn about combinations that customers prefer. For example:

Which of these cars would you prefer?

Option: 1

Brand: Volvo

Seats: 5

Price: £65,000

Option: 2

Brand: SsangYyong

Seats: 5

Price: £20,000

Option: 3

Brand: Toyota

Seats: 7

Price: £45,000

This is an overly simplified and totally fictitious example, but hopefully gives you a better idea of how a conjoint analysis takes into account multiple factors and will give you insight into how much consumers are willing to pay for a certain combination of features.

Main learning point: I personally don’t expect product managers to set prices for their products or design price research. However, I do think we as product managers benefits from a better understanding of the pricing model for our products and a better understanding of what constitutes ‘value for money’ for our customers. The Van Westendorp Price Sensitivity Meter and the Conjoint Analysis are just two ways of testing price sensitivity, but are in my view to good places to get started if you wish to get a better handle on pricing.

Related links for further learning:

  1. Van Westendorp pricing (the Price Sensitivity Meter) – 5 Circles Research
  2. Conjoint analysis – Wikipedia
  3. Why You Should (Almost) Never Use the van Westendorp Pricing Model
  4. Van Westendorp’s Price Sensitivity Meter – Wikipedia
  5. Pricing research: A new take on the Van Westendorp model | Articles |
  6. Easy Guide: How To Run a Van Westendorp Pricing Analysis – Dimitry Apollonsky
  7. Van Westendorp Price Sensitivity Meter
  8. Conjoint Analysis – introduction and principles


My product management toolkit (25): understanding the “unit economics” of your product

As a product manager it’s important to understand the unit economics of your product, irrespective of whether you’re managing a physical or a digital product. Unit economics are the direct revenues and costs related to a specific business model expressed on a per unit basis. These revenues and costs are the levers that impact the overall financial success of a product. In my view there are a number of reasons why I feel it’s important for product managers to have a good grasp of the unit economics of your product:

  • Helps quantify the value of what we do – Ultimately, product success can be measured in hard metrics such as revenue and profit. Even in cases where our products don’t directly attribute to revenue, they will at least have an impact on operational cost.
  • Customer Value = Business Value – In an ideal world, there’s a perfect equilibrium between customer value and business value. If the customer is happy with your product, buys and uses it, this should result in tangible business value.
  • P&L accountability for product people (1) – Perhaps it’s to do with the fact that product management still is a relatively young discipline, but I’m nevertheless surprised by the limited number of pr0duct people I know who’ve got full P&L responsibility. I believe that having ownership over the profit & loss account helps product decision making and and accountability, not just for product managers but for the product teams that we’re part of.
  • P&L accountability for product people (2) – Understandably, this can be a scary prospect and might impact the ways in which we manage products. However, owning the P&L will (1) make product managers fully accountable for product performance (2) provide clarity and accountability for product decisions, (3) help investments in the product and product marketing and (4) steep product management in data, moving to a more data informed approach to product management.
  • Assessing opportunities based on economics – Let’s move away from assessing new business or product opportunities purely based on “gut feel”. I appreciate that at some point we have to take a leap, especially with new products or problems that haven’t been solved before. At the same time, I do believe it’s critical to use data to help inform your opportunity assessments. Tools like Ash Maurya’s Lean Canvas help to think through and communicate the economics of certain opportunities (see Fig. 1 below). In the “cost structure” part of the lean canvas, for example, you can outline the expected acquisition or distribution cost of a new product.
  • Speaking the same language – It definitely helps the collaboration with stakeholders, the board and investors if you can speak about the unit economics of your product. I know from experience that being able to talk sensibly about unit economics and gross profit, really helps the conversation.

Now that we’ve established the importance of understanding unit economics, let’s look at some of the key components of unit economics  in more detail:

Profit margin per unit = (sales price) – (cost of goods sold + manufacture cost + packaging cost + postage cost + sales cost)

Naturally the exact cost per unit will be dependent on things such as (1) product type (2) point of sale (3) delivery fees and (4) any other ‘cost inputs’.

In a digital context, the user is often the unit. For example, the Lifetime Value (‘LTV’) and Customer Acquisition Cost (‘CAC’) are core metrics for most direct to consumer (B2C) digital products and services. I learned from David Skok and Dave Kellogg about the importance of the ‘CAC to LTV’ ratio.

Granted, Skok and Kellogg apply this ratio to SaaS, but I believe customer acquisition cost (‘CAC’) and customer lifetime value (‘LTV’) are core metrics when you treat the user as a unit; you’ve got a sustainable business model if LTV (significantly) exceeds CAC. In an ideal world, for every £1 it costs to acquire a customer you want to get £3 back in terms of customer lifetime value. Consequently, the LTV:CAC ratio = 3:1.

I’ve seen companies start with high CAC in order to build scale and then lower the CAC as the business matures and relies more on word of mouth as well as higher LTV. Also, companies like Salesforce are well known for carefully designing additions (“editions”) to increase customer lifetime value (see Fig. 2 below). 

Netflix are another good example in this respect, with their long term LTV view of their customers. Netflix take into account the Netflix subscription model and a viable replacement for another subscription model in cable. The average LTV of Netflix customers is 25 months. As a result, Netflix are happy to initially ‘lose’ money on acquiring customers, through a 1-month free trial, as these costs costs will be recouped very soon after acquiring the customer.

Main learning point: You don’t need to be a financial expert to understand the unit economics of your products. Just knowing what the ‘levers’ are that impact your product, will put you in good stead when it comes to making product decisions and collaborating with stakeholders.


 Fig. 1 – Lean Canvas template by Ash Maurya – Taken from:


Fig. 2 – Pricing and functionality overview for Salesforce’s New Sales Cloud Lightning Editions:


Related links for further learning:


My product management toolkit (14): Product Portfolio Planning

One of the key things that I’ve had to learn over the last couple of years is how to best manage a portfolio of products. When I started out as a product manager, I could focus on a single product and was fully accountable for the performance of that product. However, as time has gone by, I’ve found myself becoming responsible for a range of products, and having to make tough trade-off decisions between them. Being able to manage a portfolio of products is therefore an important skill to have in your toolkit as a product manager:

  1. What is a product portfolio? – A set of products, services or features that a company offers and which often need to be managed simultaneously.
  2. What is product portfolio management? – Managing a portfolio of products is all about a balanced allocation of resources – people, time, money, hardware, etc. – to achieve business goals. It’s all about “value maximisation” as new product development expert Carrie Nauyalis called out in a recent podcast.
  3. Types of product portfolio: top down – “Top down” portfolios are typically more strategic, with a ‘programme of work’ at the top (see Fig. 1 below). For example, the business might be looking to deliver products or services into a new market. These are often conscious decisions, taken at the executive level of an organisation.
  4. Types of product portfolio: bottom-up – With “Bottom up” portfolios, the strategy is often coming from customer requests – both with regard to B2C and B2B products or services – and tends to be more tactical. For example, customers asking for specific features to meet their needs or to solve their specific products.
  5. It’s all about analysing trade-offs and decision making! – Some product people use a Stage-Gate approach to create and manage a balanced portfolio, and to help make tough prioritisation and trade-off decisions (see Fig. 2). I personally don’t use the Stage-Gate approach, since I work in more a iterative and continuous fashion, but to me it’s all about linking to key goals and results that the business is looking to achieve, and making hard trade-off decisions on the back of these data points (see Fig. 3 below).
  6. Use data to make your trade-off decisions and evaluate product portfolio performance – As the aforementioned Carrie Nauyalis explained in the podcast, the ultimate role of having a product portfolio is to analyse. Looking at performance of the different products within a portfolio and understanding how they each attribute to key business goals. Reason why I believe it’s critical to include metrics in your product portfolio roadmap – you can see a good example of this in Roman Pichler‘s template for a goal-oriented product portfolio roadmap (see Fig. 3 below).

Main learning point: I don’t feel like you need a whole new toolkit just to manage a suite of product or services. What I’ve learned about managing product portfolios is that it brings difficult trade-off questions to the fore more. Having a clear, goal-oriented product portfolio roadmap will help you in analysing  trade-offs better and making well-informed decisions.


Fig. 1 – Top down vs Bottom up approach to portfolio management – Taken from:


Fig. 2 – The standard Stage-Gate approach to product innovation – Taken from:


Fig. 3 – A goal-oriented product portfolio roadmap – Taken from:


Related links for further learning:



My product management toolkit (12): My 90 day plan as a product person

Soon I’ll be starting a new role as a Head of Product at a great FinTech business in London. I’m very excited about the role. There’s a lot of opportunity to make an impact and influence change. But where do I start? How do I prioritise change? These questions prompted me to start thinking about my 90 day plan for this role, identifying key steps and outcomes to concentrate on. I feel that the ‘3Ps’- people, product and process – are the most logical place for me to start from:


Objective 1: To assess current performance and ambitions of the people in the team and across the business; identify how I can help create the perfect conditions for them to do their day jobs and grow.

Key results:

  1. Individual audit and objectives-key results (‘OKRs’) – To understand strengths, weaknesses and development areas for each team member and have translated these into clearly defined goals and a personal development plan.
  2. Create a simple OKR measurement framework for team members (1) – I’m sure my new company will have a formal review framework, but I want to make sure that their specific quarterly objectives are measurable and are reviewed on ongoing basis beyond formal reviews once or twice a year. The goal is to make sure that personal OKRs are fully aligned with critical business goals.
  3. Create a simple OKR measurement framework for team members (2) – Even though OKRs aren’t necessarily meant to be a performance review tool, these will be very helpful in measuring and discussing personal progress. We can then make sure that individual OKRs align with overarching business and team objectives. I’ll have to make sure their objectives are highly measurable and feel somewhat uncomfortable, similar to the OKRs that I will set to measure my own performance (see example in Fig. 1 below).
  4. Hold at least 6 individual 1:1s with each of my team members within my first 90 days – Set a frequency and a clear agenda for regular 1:1s with my team members. I can imagine that different team members will have different preferences in terms of the frequency and content of our regular 1:1 sessions. I’ll agree this with my team members on an individual basis. I can imagine that our regular 1:1 sessions will cover a mix of OKR progress review as well any questions or issues related to day-to-day stuff.
  5. Establish and communicate team OKRs for the following quarter within my first 90 days – Agree with the team on max. 5 OKRs for the entire team for the following quarter. Share these OKRs – along with a related roadmap for the quarter – with the entire business by the end of my 90 day period at the latest.

Objective 2: To establish a product discipline within the wider technology function and communicate our role to the entire business within my first 90 days.

Key results:

  1. How does Product work with Technology, Design and Business Owners and why? – Agree with other ‘Heads Of’ and their respective teams on how to best integrate Product as a function, making sure the overall team structure reflects this. This agreement should be reached within 1 month from my starting, so that people have clarity about their roles and responsibilities.
  2. Communicate the role of product management, OKRs and team structure within my first 90 days – The goal is to make sure that everyone within the organisation know what the product team does and why. On a practical level, I want to make sure that people who sit outside of the product and tech team know who to turn to, when and why. I’ll be looking at the best way to (1) embed product managers within multi-disciplinary teams and (2) make these teams customer experience centric instead of just feature centric (see Peter Merholz’ great approach in Fig. 2 below).
  3. Talk to 100 people across the business in my first 90 days – The idea here is not to just have nice introductory chats across the business, but use these introductions to really learn about the direction of the company, views on products and customers. I might even ask the same questions in each conversation, almost like a mini research project to identify common themes (see Fig. 3 below). I will thus create a much better picture of key problems and opportunities to consider, which I can then feedback to senior management along with my related recommendations.
  4. Learn from at least 3 other product teams in my first 90 days – It will be good to learn from other product teams in different industries to compare notes on best practices, understand what worked well and what didn’t (and why).
  5. Shadow at least 10 different teams for at least 1 day in my first 90 days – In my experience, there’s hardly a better way to learn about a business, its products, stakeholders and challenges, than sitting with the different business teams. You can actively shadow your colleagues as they talk to customers for example (sitting with customer support is always a good one!). Equally, I’ve found that just sitting with a team on a regular and overhearing their conversations can give you valuable insights into to their worlds and their day-to-day challenges. This is something I strive to do on a continuous basis, well beyond my first 90 days, to make sure that I don’t develop tunnel vision.


Objective 3: To understand the current product portfolio and its fit with the needs of (target) users and against the market(s) the company is operating in.

Key results:

  1. Overarching business and product vision – What is the long-term vision for the business and why? How does this vision translate into a product vision? Is this vision well understood and shared across the business? I will work with the rest of the product team to work out how we can best drive this vision on a day-to-day basis and flesh it out so that it becomes a key driver for our products.
  2. Business strategy and business goals – Understanding the long and short business strategy is critical. Having an overarching vision is great, but it’s important to have context on how we’re looking to deliver on this vision. Which markets are we looking to target and why? Which customer segments are driving our vision and why? As a product person you might be closely involved in shaping the answers to these questions, but make sure you find out if you haven’t!
  3. Understand user, business, financial and market data – When looking at data, I’m planning on splitting my time spent on data in three different areas. Firstly, going through the company’s financials and forecasts to form a better picture of growth, profit margins and customer segments. I will then use this understanding to link back to the overall business goals – see above – and business strategy. Secondly, understanding our user segments, demographics and behavioural patterns will help me to better frame the problems or unmet needs to address. Thirdly, what does the overall market look like and how does it break down into specific customer segments? Who are our main competitors and what are their differentiators?
  4. Do a quick product (portfolio) audit – It will be interesting to really understand the value of the current value proposition and product portfolio. What problems do these products solve and for whom? Are there any customer needs or problems currently not solved by our products or services? If so, how do our (target) customers solve their problems or jobs without specific products or services in place?
  5. Talk to customers and partners – My goal is to speak to a good number of customers (B2C and B2BC) and partners in my first 90 days and beyond. This means developing good relationships with our sales and accounts people, who can help arrange short, problem interviews with customers. It will be my first foray into getting some real world feedback from our customers on, for example, how they currently use our products and why. I can then work out how to best engage with and learn from our (target) customers on an ongoing basis.
  6. Create a simple KANO model – I want to map our current products in a KANO model, identifying ‘hygiene factors’ and ‘delighters’ in order to get a better understanding of the competitive landscape (see Fig. 4 below).
  7. Explore competitive products and services, ‘mystery shopping’ – In my experience, mystery shopping is a good way to understand the competitive landscape and the differentiators of your own product or service. Using competitor products or observing customers using competitive products is a great way to learn more about user needs and your own product. How does your product or service compare to the competition? How does it benchmark?
  8. Study customer demographic and usage data, identify trends and patterns – I’ll definitely try to get my hands on whatever customer data I can get in order to learn more about customer segments and their behaviours. This will help me to understand trends and opportunities, identifying where we need to focus our product efforts and why.
  9. Identify which markets to target and why – Combining data on our products, our (target) customers and market needs to identify the best market(s) to target. This should also tie in nicely with the relevant strategic themes for the company, for example ‘internationalisation’, ‘partnerships’ and ‘retail’ and related business objectives.
  10. Use quantitative and qualitative data to create an experience map – Who are our users? Which jobs do they need to do and why? How do they feel about our products and services in relation to their jobs-to-be-done? Creating an experience map will help in understanding user behaviour in relation to our products and services. I’ve found the experience map exercise to be particularly helpful in relation to companies that don’t have a unified, shared view of their products or customers.
  11. Translate into a product strategy – Your initial product strategy can be fairly high level and you don’t have to lock yourself up in a dark room for 6 months to draft a plan. I believe it’s important to take your learnings and convert them into a plan which outlines how we can achieve critical business and customer goals, without getting too immersed in the detail. Instead, I tend to look at the high level milestones or building blocks that need to be in place to achieve specific business goals or solve customer problems. Melissa Perri recently wrote a really helpful article about how to create a product strategy, which I’ll definitely include in my toolkit (see Fig. 5 below).


Objective 4: To introduce the ‘minimum viable process’ necessary to address specific organisational or product related problems which impact product development or our bottom line.

Key results: 

  1. Is there a roadmap? Do we need one? – I know that some companies deliberately don’t have product roadmaps. Instead, they fully empower their product managers and engineers to liaise directly with customers and deliver against high-level strategic themes – companies like Hubspot are good examples in this respect. I, however, find having a product roadmap a very important tool in creating a product and customer centric culture across the entire business. A roadmap can be an incredibly helpful tool in conveying high level goals, milestones or themes to business stakeholders, teams and customers. I always make it clear that a product roadmap isn’t set in stone, but that it will give everyone in the business important context on what we’re looking to achieve and why.
  2. How do things get prioritised? – What criteria does the company use to add and prioritise things onto the roadmap. Are a product vision and roadmap in place that drive the roadmap? How do people assess new product opportunities? One the first things I’d like to do is to understand about any product or project milestones in flight or planned, and their underlying rationale.
  3. Product backlog, the next level down from the roadmap – Does the company have one product backlog or do the different teams have a number of backlogs that they work against? If so, what does the backlog look like, has it been ‘groomed’ and prioritised?
  4. How do things get shared across the business? (1) – Understand how people across the business know what’s going on from a product development and performance perspective. Often I see companies where product development is perceived to be a ‘black box’, with people being unclear about what gets developed (and why). I’ve also come across companies with a project management office that sends out status reports which are very task based and don’t necessarily provide a good update on the value we’re looking to create for customers or on tangible product progress. Like I mentioned in point 1. above, my preference is to have a high level product roadmap which is shared across the entire company (and ideally with customers as well). This acts as a simple but very effective example to convey why we’re building certain solutions or features and how we’re progressing against specific milestones or goals (see example in Fig. 6 below).
  5. How do things get shared across the business? (2) – Product review meetings, ‘all hands’ sessions or product retrospectives can also be a very effective in engaging with people across the business. The main reason why I’m always in favour of live demos over status reports is that people typically find it easier to see working software or a prototype instead of a written document. Even if you’re showing a non-finished article, you’ll at least be able to explain in person that a product or feature is still work in progress and what it is that you’re looking to learn (and why).

Fig. 1 – Sample OKRs to measure and review individual performance:

Instead of:

“To launch a new mobile app”

We will make the result more objective and measurable:

“To launch a mobile app for iOS and Android by the end of September ’16 and to achieve a 2% increase in mobile conversion by the end of November ’16.”

And make sure it’s aligned with key business objectives:

“To increase repeat purchase from 1.7 to 2.5 by 31 December ’16.”


Fig. 2 – Product managers embedded within multi-disciplinary product teams – Taken from:

Taken from:

Peter Merholz 1

Fig. 3 – Sample questions to ask during my first my introductory conversations in my first 90 days:

Generic questions to ask:

  • What is the overall vision of the company?
  • What are the key company goals or success criteria? What does success look like and why? Which one(s) are you working towards (how and why)?
  • How would you describe the company culture – what do you enjoy about working here, what could be improved?
  • Are you involved in developing new products or services? If so, how? If not, why not?
  • Who is your main customer? Is your customer internal or external? What do they care about and why?
  • What do you see as the main differentiator(s) of the business? Where do you see opportunities for the company or where are we lagging behind?
  • What are your observations with regard to the new products we launch to market and existing products that are already out there?
  • How do you currently collaborate with other disciplines within the company to deliver against company goals (e.g. working with traders, customer support or developers)

Questions about continuous improvement:

  • What does continuous improvement mean for our business and why?
  • Why is continuous improvement so important and what does success look like?
  • Have you got an example of where continuous improvement materially impacted the business’ bottom line? If so, how?
  • What kind of processes have you put in place to ensure continuous learning and improvement?
  • How do you go about instilling and maintaining a continuous improvement mindset across the wider business?

Questions about technology teams and leadership:

  • How do the developers currently interact with product managers, QA, UX as part of product development?
  • What is working well in that collaboration and what can be improved? Why?
  • What are the key roadmap goals or milestones for the coming quarter? How is success being measured?
  • What does the definition of “DONE” look like for the development team?
  • How and when do developers get involved in the planning process?
  • How do you currently structure your development team? For example, is it based on internal vs external, customer segments, specific problems, features or metrics?
  • (how) Do developers interact with customers?
  • Do you run a “dual track scrum” approach? If so, who gets involved in product and technical discovery?
  • How do you manage or mitigate technical risk?
  • What approach do you use with respect to testing? For example, do developers use TDD to test their code?
  • How do you balance fixing bugs, addressing technical debt with delivering business value, releasing new features?
  • How iteratively do the cross-discipline teams work? Is there a culture of continuous deployment?

Questions about customer experience and marketing:

  • How does marketing collaborate with product managers? When and how do marketeers get involved in the product lifecycle?
  • Who is responsible for developing a go-to market strategy? Who develops marketing strategies and related collateral?
  • Which customer profiles, segments and demographics are at the heart of our business strategy and why?
  • How do we go about reaching out to our target audience? Are there are specific areas that you are looking to optimise?
  • What does market growth look like and why? Are we looking at new – opposite or adjacent – markets?
  • What happens at the ‘initial insight’, ‘plan’ and ‘execute’ stages and why? It would be good to understand specific activities (e.g. story mapping, ‘jobs’, experience mapping, empathy mapping, etc.)

Fig. 4 – Create a simple KANO model – Taken from:



Fig. 5 – Product Strategy Canvas – Taken from:


Fig. 6 – Sample high level product roadmap – Taken from:



Related links for further learning:





My product management toolkit (6): assessing product opportunities

Prioritisation. A lot of product managers will have a love-hate relationship with prioritisation; constantly having to choose between ideas and making tough tradeoff decisions. Whichever way you look at it, prioritisation is part and parcel of our job as product managers. Before you prioritise a specific solution, I’d always recommend you assess first whether the problem is worth solving in the first place.

A few weeks ago I wrote about identifying and validating problems. I’m now going to focus on assessing the opportunity related to solving a particular problem. Is the problem worthwhile solving? Why (not)? Has the problem already been solved? If so, by whom and how? I’ve learned that a simple opportunity assessment or business case can be very effective in helping to decide on whether to create a product.

Tool 6 – Assessing product opportunities

What’s a product opportunity assessment? – A product opportunity statement is a simple template invented by Marty Cagan and is meant to help people concentrate on the ‘right’ opportunities. How do you know which opportunities to focus on and which ones to discard? How do you prioritise between ‘great sounding product idea A’ and ‘great sounding product idea B’? What are the grounds on which you base such a – typically difficult – decision? Marty Cagan’s product opportunity assessment helps us work through these thorny questions in a very systematic and structured manner:

1. Exactly what problem will this solve? (value proposition)
2. For whom do we solve that problem? (target market)
3. How big is the opportunity? (market size)
4. What alternatives are out there? (competitive landscape)
5. Why are we best suited to pursue this? (our differentiator)
6. Why now? (market window)
7. How will we get this product to market? (go-to-market strategy)
8. How will we measure success/make money from this product? (metrics/revenue strategy)
9. What factors are critical to success? (solution requirements)
10. Given the above, what’s the recommendation? (go or no-go)

By Marty Cagan – Taken from:

The thing I love about this approach is that it enables me to compare product opportunities or ideas in a very objective and like-for-like manner. Instead of going for the first solution to a problem that “sounds right” or “seems cool” you’re taking a step back and assessing a number of (competing) market or product opportunities, using the same questions or metrics to do an objective comparison. I’ve found that going through the process of assessing a product opportunity makes it so much easier to have really focused conversations about product strategy or goals that you are looking to deliver on.

What a product opportunity assessment isn’t – An opportunity assessment doesn’t aim to provide a solution to a business or customer problem. In contrast, it helps answering the question whether it’s worthwhile solving the problem in the first place. Another way to look at this is to look at the value or outcome that you’re looking to provide to your business or customer.

When to do a product opportunity assessment? – Too often, I see business people or product managers jumping straight into what I call “feature mode”: coming up with a feature or a solution instead of first looking at the problem to solve (and whether it’s worth solving) or the specific business or customer outcome to achieve. I’ve learned a lot from Valve, a well known gaming company, and from American based innovation expert and author Tony Ulwick in this respect. Both Valve and Ulwick focus on outcomes instead of outputs. It’s not about creating feature X. It’s about the value that this or any feature generates for the customer and the business. Similar to creating a business case, a product opportunity assessment helps you and your stakeholders understand why a problem is worth solving (or why not) and the value that solving it will generate.

I recently came across another useful framework by my friends at Xing, a business networking platform aimed at German speaking users. This framework is called “ACE” and stands for “Assignment Clarification Exercise” (see below). Similar to Marty Cagan’s product opportunity assessment template, Xing’s framework urges you to think about aspects such as “context” and “outcome.”


Xing’s “ACE” Framework – Taken from:

Main learning point: Especially in situations where you’ve got a lot of opportunities to choose from, assessing the opportunity using Marty Cagan’s questions helps you to compare opportunities or ideas objectively. Whether you create a full fledged business case or use Cagan’s template, the key thing is that you assess the problem you’re thinking of solving, the competition, your target audience, etc. You’re thus assessing the ‘context’ around a problem, understanding whether it’s a problem worth solving or prioritising.

Related links for further learning: