My product management toolkit (28): testing price sensitivity

April 17, 2018June 8, 2018 marcabrahamLeave a comment

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: http://www.5circles.com/van-westendorp-pricing-the-price-sensitivity-meter/

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: https://www.qualtrics.com/uk/market-research/pricing-research/*

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: https://www.questionpro.com/survey-templates/conjoint-analysis-retirement-housing/*

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:

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

December 28, 2017 marcabrahamLeave a comment

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: https://blog.leanstack.com/

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

October 18, 2016 marcabrahamLeave a comment

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:

What is a product portfolio? – A set of products, services or features that a company offers and which often need to be managed simultaneously.
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.
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.
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.
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).
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: https://www.sopheon.com/top-down-vs-bottom-up-resource-planning-which-is-better/

screen-shot-2016-10-17-at-08-54-30

Fig. 2 – The standard Stage-Gate approach to product innovation – Taken from: http://www.stage-gate.com/resources_stage-gate_omicron.php

img_chart_nov

Fig. 3 – A goal-oriented product portfolio roadmap – Taken from: http://www.romanpichler.com/blog/the-go-portfolio-roadmap/

the-go-porfolio-roadmap-template

Related links for further learning:

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

July 19, 2016August 5, 2016 marcabrahamLeave a comment

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:

People

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:

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.
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.
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).
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.
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:

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.
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).
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.
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).
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.

Product

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:

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.
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!
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?
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?
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.
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).
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?
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.
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.
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.
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).

Process

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:

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.
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.
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?
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).
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: https://blog.intercom.io/podcast-peter-merholz-talks-product-design/

Taken from: http://www.slideshare.net/UXSTRAT/ux-strat-2014-peter-merholz-shaping-organizations-to-deliver-great-user-experiences

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: https://en.wikipedia.org/wiki/Kano_model

Kano_model_showing_transition_over_time

Fig. 5 – Product Strategy Canvas – Taken from: http://melissaperri.com/2016/07/14/what-is-good-product-strategy/

Product-Strategy-Canvas

Fig. 6 – Sample high level product roadmap – Taken from: http://www.romanpichler.com/blog/goal-oriented-agile-product-roadmap/

SampleGOProductRoadmap

Related links for further learning:

My product management toolkit (6): assessing product opportunities

March 1, 2016September 19, 2017 marcabraham3 Comments

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: http://svpg.com/assessing-product-opportunities/

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

Xing’s “ACE” Framework – Taken from: http://produktfuehrung.de/framework-no-9-auftragsklarung/

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:

My product management toolkit (3) – Goal setting

January 28, 2016 marcabraham8 Comments

As part of my product management toolkit, I’ve thus far covered the creation of a product vision and the definition of a product strategy. The next thing to look at is goal setting: what are the business goals that a product strategy and or roadmap need to align with? I’ve learned the importance of goals to help define or assess a product strategy. I would even go as far as saying that if your product strategy, roadmap, backlog or – low and behold – your actual product don’t align with your business goals, you’re setting yourself up for failure.

Tool 3 – Goal Setting

What are goals? – This is what Wikipedia has to say about “goals”: “A goal is a desired result that a person or a system envisions, plans and commits to achieve; a personal or organizational desired end-point in some sort of assumed development. Many people endeavour to reach goals within a finite time by setting deadlines.” In other words, what is it the that we are looking to achieve, why and by when?

I typically look at goals from either of the following two angles: metrics or ‘objectives-key-results’ (‘OKR’s). From a metric perspective; what is the single metric that we’re looking to move the needle on, why and and by when? What does this impact look like and how can we measure it? For example, a key business goal can be to increase Customer Lifetime Value with 1% by June 2016. To be clear, a metric in itself isn’t a goal, the change that you want to see in metric is a goal.

From an OKR perspective, the idea is to outline a number of tangible results against a set, high level, objective. For example:

Objective: To enable sellers on our marketplace platform to make business and product decisions based on their sales and performance data generated from their activities on our platform.

Result 1: Our sellers making key business and product decisions before and throughout Christmas 2015

Result 2: Our sellers can look at their historic sales data so that they’ve got more sales context for their decision-making

Typically, there will be a set of overarching business goals that have been established and our responsibility as product managers is to link our product goals to these objectives, so that our product strategy is fully aligned with the business strategy.

okr-deck

Taken from: http://www.businessinsider.com/googles-ranking-system-okr-2014-1?IR=T

What goals aren’t – Goals aren’t a strategy or specific features. This might sound obvious, but often see cases where people do confuse things; setting goals without a strategy to achieve them or having a roadmap that doesn’t align with business goals.

In contrast, the point of a strategy or a roadmap is to highlight the ‘how’, the steps that need to be taken to achieve specific goals.

When to create goals? – It’s simple: if you join an organisation and hear “we don’t have business goals”, you know what to do! My point here is that a product strategy or roadmap that isn’t aligned with broader business goals, is just a loose collection of features or random solutions. The one thing to add is that some early stage startups tend to get really hung up on a whole range of specific goals or metrics. I’d always recommend to keep it simple and focus on a single goal or metric, understand what your (target) users’ needs are and how are they actually using your product.

Characteristics of good goals – I can imagine that a lot of you will have a heard of SMART goals:

S = specific, significant, stretching
M = measurable, meaningful, motivational
A = agreed upon, attainable, achievable, acceptable, action-oriented
R = realistic, relevant, reasonable, rewarding, results-oriented
T = time-based, time-bound, timely, tangible, trackable

SMART 2 Example taken from: http://business.lovetoknow.com/wiki/Examples_of_SMART_Goals_and_Objectives

Main learning point: In my view, setting and understanding goals is just important as creating a strategy to achieve them. Before I delve into creating a product strategy or roadmap, I’ll always try to make sure I fully understand the business objectives and translate those into specific, measurable product goals.

Related links for further learning:

No more features on product roadmaps – Have themes or goals instead!

October 1, 2015October 1, 2015 marcabraham7 Comments

You might have read my one of my previous blog posts about the so-called goal oriented roadmap. I prefer goal-oriented roadmaps over their more traditional counterparts. My problem is that ‘classic’ roadmaps contain a mix of features and timings, but don’t provide any context whatsoever (I’ve included an example in Fig. 1 below). I typically don’t include features on a roadmap and focus on user or business problems instead. As such, the roadmap becomes a tool for ‘working backwards’ – enabling product teams to explore solutions for given problems or desired results.

I recently learnt from Jared Spool and Bruce McCarthy about adding “themes” to product roadmaps. McCarthy told Spool about the concept of adding themes, and Spool became an instant fan. Like me, McCarthy isn’t a fan of having features on a roadmap. Instead, he suggests adding “themes” to the roadmap and this is why:

Open to ‘options’ – McCarthy believes that by having specific features on a roadmap, you run the risk of sending a product team down a certain avenue (and closing off any potential side streets). For example, if you were to just put “data dashboard” on a roadmap, chances are you’ll end up with a data dashboard. However, what would happen if you were to put “provide our customers with data to make key decisions” or “no data access” on the roadmap instead? By focusing solely on solution you run the risk of falling victim to what Josh Wexler calls solution sickness. Solution sickness is all about fixating on a solution and ignore any alternative ways of solving a problem.
Customer focus – Jared Spool makes a great point when he says “When companies talk about features, they are saying, “Look at us. Look at what we can do.” He goes on to explain that “When companies talk about the problems of customers, they are saying, “Look at what you’re dealing with. Look at how we want to help.” It’s very easy to get fixated on features and forget about the underlying problems you’re looking to solve.
Helping trade-off decisions – One of the things I love about both the goal-oriented and ‘theme’ approach to roadmapping is that it forces you to consider ‘why’ you want to develop certain products or services. What problem are we looking to solve and why? Why do we feel this problem is worth solving? Why should we prioritise this problem over others? Both the goal oriented and the theme roadmap approaches help make customers and their problems the core of everything you do as a product person. When I use the goal oriented roadmap, I always take out the “feature” layer purely because I don’t want us to be pinned down to one solution.
“Marketing the story of solutions” – Which do you think would be an easier story to sell to customers? Option 1: “You can now use this real-time data dashboard which you can access via your content management system, enabling you to filter the data and extract reports” or Option 2: “You can use our data to decide on whether now is good time to sell your house?” … Easy, isn’t it!? As Jared Spool points out, the ‘theme’ approach makes it much easier for marketing teams to tell a story about a product or service: “Here are the problems we set out to solve and here’s how we solved them.”
A more cohesive design – Design is another area which is positively impacted by a shift in focus from solutions to problems. From experience, I know how much easier it is to prioritise against a problem that you’re looking to solve, instead of trying to cram in a lot of features which you think might have an impact. As Spool puts it: ” Without a commitment to specific solutions, the team has flexibility.” As a result, product teams stand a better chance of creating simpler, well designed products.

Main learning point: I really encourage all product managers – the ones who aren’t doing so already – to think much more in terms of user problems instead of focusing on features. Not only will this help you in focusing your product efforts, I believe it will also make you much more customer centric.

Fig. 1 – Example of a traditional roadmap – Taken from: https://roadmunk.com/

Fig. 2 – Goal oriented roadmap example – Taken from: http://www.romanpichler.com/blog/agile-product-roadmap/

Related links for further learning:

As I learn …

This site is about everything digital, giving an update on new things as I learn

Tag: metrics

My product management toolkit (28): testing price sensitivity

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

My product management toolkit (14): Product Portfolio Planning

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

People

Product

Process

My product management toolkit (6): assessing product opportunities

Tool 6 – Assessing product opportunities

My product management toolkit (3) – Goal setting

No more features on product roadmaps – Have themes or goals instead!