Funnel analysis is a tool used in product management to understand and optimise the process users go through to complete a desired action or conversion within a product. This action or conversion could be anything from signing up for a trial or demo of a product; to making a purchase or subscription; to completing a task or achieving a goal within a product.
Product managers use funnel analysis to identify bottlenecks or points of friction in the conversion process that may be causing users to drop out of the conversion journey. By analysing data on the conversion process, product managers can understand how users interact with their products and identify opportunities to improve the product’s user experience and increase the conversion rate. This can ultimately lead to increased revenue and growth for the product.
Product managers may also combine funnel analysis with segment analysis to compare how conversion rates vary by user attributes or behaviours. These insights can then identify opportunities for improvement within the user journey and help us better understand our user’s behaviours.
While all funnels are different, the steps that a product manager would go through to conduct a funnel analysis are generally the same:
By analysing the data collected through tracking and measurement tools, product managers can identify bottlenecks or points of friction in the conversion process that may be causing users to drop out.
For example, suppose the product manager sees that many users drop off at a particular stage in the funnel. In that case, they may prioritise addressing this issue to improve the conversion rate. They may also look for patterns or trends in the data that can help them understand why users are dropping off and what changes could be made to address the issue.
It’s important to remember that addressing the stage of the funnel where the largest percentage of users drop off may not necessarily lead to an overall improvement in the conversion rate. This could be because other issues or bottlenecks in the conversion process also contribute to the low conversion rate.
In this case, it may be necessary for the product manager to take a more holistic approach to improve the conversion rate by addressing multiple issues in the funnel. This is why it’s vital to model the impact of step improvements on the overall funnel conversion. You can use table three in my template to do this.
Overall, funnel analysis is an essential tool for product managers to understand and optimise the user experience and increase the conversion rate of their product. By analysing data on the conversion process and taking a holistic approach to addressing issues causing users to drop out, you can drive revenue and growth for your products.
]]>In this post, I’ll share the list I put together. If you’re new to product management, start at the top and work your way through, If not, jump around and pick what’s interesting to you. They are all fascinating reads that will help you become a better product manager!
If you are starting in product management, it is easy to be overwhelmed by the unprecedented array of processes, tools, and methods for digital product development. It can be hard to understand how these all fit together, but Jonny Schneider’s book Understanding Design Thinking, Lean, and Agile provides a straightforward explanation.
The book will help you to evaluate your situation and then apply the right techniques to improve your product development. Even better, it’s less than 70 pages, making it a quick read to get you started.
If there were one book I’d recommend to learn or remind yourself of the fundamentals of product management, it would be The Lean Product Playbook. It had to have a place in the list of best product management books.
The book brings together ideas from Lean Startup and Lean UX to give you an actionable model for finding product-market fit. It consists of a 6-step process that explains how to:
It also comes with several real-world examples that illustrate the full product development lifecycle from a product management standpoint.
A good product roadmap is one of the most critical documents you develop as a product manager. It is how you communicate your product strategy and make product trade-off decisions. I think it’s so important it’s worth reading a book specifically on the subject.
Product Roadmaps Relaunched provides an excellent practical guide to building effective roadmaps in agile environments. The book acknowledges the lack of future certainty and provides an adaptable approach to building roadmaps. It includes lots of actionable advice to help you align stakeholders, prioritise new ideas and evolve your roadmap. Not to mention, it’s very well designed and easy to use as a reference book.
A vital part of a product managers job is to develop a product that creates value for a customer segment. To find an opportunity to create value, you need to identify potential customers and the problems they have. But to turn an opportunity into a business, you need to have a sustainable business model to deliver value to your customers and capture some back for yourself.
Business Model Generation provides a practical handbook for anyone looking to create or improve a business model. It introduces the business model canvas and explains how to use it with examples of well-known companies. Developing business models can appear challenging, but this book will give you a quick and easy way to start. You can then test the model and iterate.
If you’ve been working in product management for a while, there’s an excellent chance you’ve already read Nir Eyal’s bestselling Hooked. If you haven’t read it, it should be at the top of your reading list.
Hooked is an excellent introduction to user psychology and how to design product experiences that create user habits. The book shows how businesses that invest in creating habits gain a significant competitive advantage and gives real-world examples from companies, including Instagram, Pinterest, and Twitter.
Crossing the Chasm by Geoffrey Moore is one of the best product management books focused on product marketing. It’s an essential read for anyone looking to grow their products user base. It explains how you can develop products that make the jump from cool novelties for a small group of early-adopter to full-blown mass-market successes.
The book introduces the Technology Adoption Lifecycle and explains why there is a gap (the chasm) between the needs/wants of the early adopters and those of the mainstream market. It then explores how to narrow the chasm and reach the mainstream by targeting a specific niche market, offering a whole product solution and becoming the market leader.
Read my summary of Crossing the Chasm!
Getting stuck in research and data-analysis mode can be a genuine pitfall for product managers. But doing research and analysing data is an essential part of making good product decisions. Understanding when to look for data and what data to look for is the key to finding the balance.
For this reason, I recommend Lean Analytics. This book offers excellent insights into how to collect the right data, what tools to use for analysing it properly, and how to learn from the most successful and data-driven companies before setting your analytics objectives. If you are looking for a book purely on web analytics, this isn’t for you. If, however, you want to know how to apply analytics to building a successful product, this is a great read.
Most of the books in this list show you how to use tried and tested approaches to manage your products. Unfortunately, as a product manager, you won’t always find yourself with a playbook. Sometimes you need to make tough decisions when you’re not sure what to do.
In The Hard Thing About Hard Things, Ben Horowitz shows you how difficult it is to launch a successful product. He shares his stories building venture-backed startups and his advice for navigating the problems you may face. Although the book doesn’t focus exclusively on product management, it gives an honest insight into the challenges you may face as a product manager.
When launching a new product, it can be hard to separate the meaningful metrics from the distractions. Understanding if your product is gaining traction is essential if you are to be successful. In Scaling Lean Ash Maurya gives you a way to measure and scale a tech startup with maximum efficiency. This book will teach you:
What makes Scaling Lean one of the best product management books is how it brings together concepts from Systems Thinking, Lean Startup and the Theory of Constraints into an actionable package for product managers.
Read my summary of Scaling Lean!
If you are a product leader in a large enterprise, you’ll know there are many challenges to applying lean product practices. Many large organisations struggle to respond to changing market conditions, the latest customer needs or emerging technologies when building products, but it doesn’t need to be like that.
Lean Enterprise provides a practical guide to applying lean and agile principles at scale across your organisation. Through case studies, you’ll learn how successful enterprises have rethought everything from governance and financial management to systems architecture and organisational culture in the pursuit of radically improved performance.
At a time when we see an accelerating rate of innovation, it’s critical to have an adaptable organisation. This makes Lean Enterprise an essential read for product leaders in corporate organisations and government.
]]>I’ve found the best way is to establish regular product metric reviews. If you don’t have consistent product metric reviews in your company, I highly recommend you set them up. Through this article, I’ll show you how.
There are three primary reasons for having product metric reviews:
Let’s explore each of these in more detail.
Few product companies would admit they don’t use data to make decisions. Unfortunately, I have found this is rarely true when I see how teams are operating.
Most of these teams have no shortage of data, but it isn’t central to their decision making. Sometimes they don’t look at the data regularly enough. Some of them feel they can’t trust the information they have. And many can’t connect the metrics they care about to the companies business objectives.
Product metric reviews solve these problems. They force stakeholders to review the product metrics regularly and create a forum to discuss any challenges. Over time the quality of the product metrics will improve as will the connection between them and the business goals.
I believe that transparency is one of the most import characteristics of a great product organisation. It’s essential if you want to avoid surprises and if you value organisational learning.
Product metric reviews provide both transparency and accountability. They allow regular monitoring of progress, the sharing of learning, and help to establish team standards.
Used correctly, they also create a culture of introspection that improve performance across the whole team, providing a forum to evaluate what didn’t work openly and honestly. Over time this will build trust and increase team engagement.
Well executed product metric reviews provide product managers with the chance to see what’s going on within your company and outside in the market. In these review sessions, you hear about the experiments people have run, the analysis of the results and an explanation of the trends they have found.
Over time you start to get a collective feel for what works and what doesn’t. I refer to this as product intuition. As your intuition grows, you will begin to make better bets, prioritisation decisions will become easier, and ultimately you will be able to leverage your time more effectively.
Product metric reviews are about measuring real value creation, not activity. You shouldn’t be discussing work completed. Instead, focus on the value generated for your company through the completion of this work.
To understand what is creating value for your business, you need to break it down. Start with the business goal you are trying to achieve and consider the metrics that need to change to achieve the goal. You can then break these down further until you get to an actionable leading metric. I’ve found the best format for this is a tree structure.
Lean Value Tree
The tree is useful because it helps you think about the levers that affect your business. By breaking down the goal using clear metrics, you can understand which of these levers have the highest potential for impact.
Before your first metrics review meeting, you need to decide who should attend and the cadence of these meetings.
Ideally, all the main stakeholders in the business and those that influence the metrics within the tree should attend. Generally, this would include leaders from product, design, engineering, sales and marketing. You’ll also want someone from finance in attendance if you need updates on the trailing financial metrics within the tree.
Depending on your company, it may not be possible to start operating product metric reviews at the exec-level immediately. If this is the case, don’t worry. You can still benefit from these review meetings. In your case, the top of your tree will be the metrics owned by the most senior person in attendance.
It’s best to have your metric review meeting weekly or bi-weekly. Any less regularly and it is tough to create a data-driven culture. Of course, the cadence depends on your product initiatives. You need the ability to make product changes and measure their impact before the next meeting. Then you can discuss the shift in metric and repeat the cycle.
The meeting should ideally happen in-front of the tree so everyone can see the metrics and what any changes influence.
I usually start the meeting by walking through the tree and asking for updates. Each metric within the tree should have a clear owner, and they will give the update. They should speak about any change in the number and a headline reason for this. There is then an opportunity for discussion before we move to the next metric in the tree.
I’ve found the real value is in the discussions that happen after the update as this is where the real learning occurs. If the owner can’t answer a question, they can take it away and give an update in the next meeting.
Once you have established a regular cadence of review sessions, you may want to add in a product strategy review session as well. These should happen less regularly, I do them once a month, and can be used to discuss significant product strategy changes.
Starting and sustaining product metric reviews is not easy. It takes time, data resources and leadership engagement to be successful. But the benefits can be significant. I try to establish regular product metric reviews at the companies I work with to gain these benefits and instil a data-driven product culture. After reading this, I hope you have the knowledge and the motivation to do the same.
]]>To include dates in your roadmap you will need to know three things for every item. When you will start, how long it will take and when you will finish. I’ve never worked with a product team who knew all of these with any certainty, but I’ve worked with plenty who’ve guessed. To guess you have to make a whole lot of assumptions:
Firstly, you assume you know how long everything in your roadmap will take. This is probably a bad assumption since people are fundamentally bad at estimation. You might have some idea about the near-term work, but it gets harder and harder the further out you plan.
Next, you assume the future will be the same as the present. I promise you it won’t be, but I have no idea how it will be different either. People are pretty bad at anticipating the future. The only thing we can be sure of is there will be change all around you.
You’re also assuming that everything you build is going to work as soon as you finish it. The reality is it probably won’t. There will be bugs, there will be teething problems, and there will be rework. I’ve never worked with a team that got everything right the first time, and I doubt I ever will.
Lastly, probably the biggest of the assumptions is that you should build everything in your roadmap. Most likely you shouldn’t, but when you assign a product initiative a delivery date, you’re subconsciously committing to deliver it. This commitment removes your ability to adapt based on the learning from delivering previous initiatives.
As you can see a product roadmap with dates is a collection of assumptions that suggest nothing is going to change. The problem is, things do change, and I think it’s dangerous to pretend they won’t. So what should you do instead?
Your product roadmap should provide a high-level map to show your team and stakeholders where you are going and how you hope to get there, but it should not give them the false certainty that comes with features and dates. Here’s an alternative approach:
Define outcomes instead of features: Instead of using your roadmap to define what you are going to build, explain what you want to achieve. Rather than features, make product bets with a measurable outcome that will directly contribute to your companies objectives. Provide a sequence instead of a date: Remove the timeline and instead focus on prioritising your product bets. You can use categories, like now, next and later to help with this. These categories help you separate the near-term product bets that you understand most from the less certain bets in the future. Make time to review and adapt – In many ways, your roadmap is the output of an ongoing discovery process, with each iteration building on what you learned from the previous. Having time to review what you learned and adapt the roadmap accordingly is essential if you are to navigate the uncertainty of product development. Ultimately it is the process of developing a roadmap that is more important than the roadmap itself. The process will enable you to deal with the uncertainty of product development and the risks that come with it.
I think it’s important to highlight that it won’t necessarily be easy to remove the dates from your roadmap. Dates bring a feeling of certainty and a lot of company leaders like that. They often perceive risk in moving from a safe and predictable feature roadmap, but ironically not doing so opens them up to the higher risk of not learning and adapting. If you face objections, don’t let it put you off. Listen to them and try to show, rather than tell them the benefits of another approach.
Removing the dates from your roadmap isn’t a step into a less certain future. It’s a sign of good product leadership and organisational maturity. Coming clean and admitting that we were all making the dates up means we can have more honest conversations with stakeholders, deal with the real product challenges and adapt to the changes in the future.
Awesome, I hope to see less timeline roadmap’s in the future!
]]>Most companies are not yet at the stage where they can operate product teams like Amazon, Google or Netflix. People often say these companies lack a product mindset or don’t have the right ‘culture’. However, I think it is about having the organisational readiness to operate product teams that empower people to work as they need to.
All organisations could benefit from having product teams, but to operate effectively, they need to be ready for them. There are some significant changes in organisational design necessary to make product teams effective. Often people find these changes surprising and particularly challenging, but the benefits can be far-reaching.
The first step on the path to product teams is to recognise where you currently are. You can then identify the characteristics and activities you need and plot a route towards that for your organisation. To help you find your way, I have built on Amplitude’s team structures diagram and explained the characteristics of teams at the four stages of development.
On the first step of the path are agile delivery teams. These teams exist to deliver what the business asks for, not to decide what to build.
They own the build and test stages of product development. In some cases, they can also release the code they developed. More often though they are releasing to a staging environment and there is a separate operations team that manages the product in production.
Agile delivery teams are not cross-functional. They usually are made up of just developers with a backlog ‘owner’ in the form of a project manager or business analyst. Theses teams are all about output and are managed accordingly. They often exist in companies with significant project management functions and tend to be measured based on team velocity or their ability to hit time-based deadlines.
The next stage of team development is the Design-Build-Run Team. These teams extend the responsibilities of the agile delivery team to include product design and managing the product in production.
At this stage, teams begin to own the usability of the product. They will typically focus on just visual, and interaction design but are ultimately responsible for ensuring that the product is easy to learn, efficient, effective and engaging.
They are now also responsible for the feasibility of the product in production. The team will have to ensure the product is reliable, maintainable and scalable.
Design-Build-Run Teams are cross-functional but don’t include product managers because they don’t need to decide what to work to do. Instead, these teams will receive requests to deliver functionality from business stakeholders.
The next stage is feature teams. Up to this point, teams have been all about delivery, but feature teams begin to have some decision making power. They often will be able to decide on the user requirements and sometimes how to implement these features within the product.
Feature teams often look like product teams. They are usually cross-functional and have development, design and some form of product management capability. Unfortunately, they are not truly empowered to make product decisions.
In feature teams, product decisions are owned by a business stakeholder that sits outside the team and makes feature requests, generally through a roadmap. It’s therefore not possible to fully operate as a product manager from within a feature team. In fact, it can be downright dangerous. Although the stakeholder outside the team is the one responsible for the product decisions, they may still find a way to blame you and your team if their hoped-for results are not realised.
Finally, we arrive at product teams. In comparison to feature teams, they are fully empowered to identify opportunities to serve the customer and develop solutions that work.
Product teams are responsible for outcomes. It is up to them to ensure their product is delivering value to its customers and is capturing value to make continuing product development viable. The results a product team is trying to achieve may vary, but what cannot is their autonomy to decide how to achieve them.
The transition to product teams means the team now exists to serve the customer directly, rather than to serve an internal business stakeholder.
This is a profound change, that affects almost all the team’s ways of working, resulting in greater inspiration, motivation and morale. More importantly, it unlocks the knowledge and abilities of the people within the product team, leading to consistent innovation that generates value for your customers and your business.
It is the trust and empowerment of people within the product teams that enables companies like Amazon, Google, or Netflix to achieve disproportionate results. These companies trust the people nearest the customer problem to make the best product decisions, and you should do the same.
]]>A roadmap is used by product managers to communicate their strategy. It should explain what you are going to do and why you are going to do it. A great roadmap should achieve the following:
Roadmaps are all about strategy so you should avoid talking about how you plan to build things—the how should be in your product backlog.
There’s a lot of advice out there about what to include in your roadmap, but since the purpose of a roadmap is clear communication I recommend you keep it simple and focus primarily on the following three key components:
What are you trying to achieve? It sounds like a simple question, but without clear objectives, you are most likely doing work for the sake of work. The aim of your work should be to achieve something for your company, and the objectives make this clear. Depending on the roadmap level, these may be business, product or release objectives.
How will you know when you have achieved your objective? It’s critical that you have measures of success which describes the value
you will get by delivering the objective. Without this, it becomes impossible to prioritise one activity against another or understand if the cost to achieve the objective is worth the investment.
Examples:
What will you do first, and what will you do next? You don’t need to list specific dates on your roadmap, (I try and avoid this). But you do need a way to clearly show priority because, most likely, you can’t do everything you want to do at once.
Some ways to show priority are:
Your product roadmap shouldn’t exist in isolation. It is the crucial link between your company’s business strategy and the features your team’s release.
Tthere are three levels, and at each level, there should be a roadmap with objectives, measures and priorities. Here’s how to build these roadmaps.
The first step is to understand your company’s goals and strategic bets. Without this, you cannot build an effective product roadmap. Some companies will have a clear business roadmap (or strategy) already. If not, you will need to work with the senior stakeholders in your company to create one. To do this, you should:
Once you have created your Business Roadmap, it’s time to create your Product Roadmap.
Now you know the company’s objectives and strategic bets, you may realise there are multiple products or features which could contribute to achieving them.
Here is what you should do next:
At this point in the roadmap process, it can be easy to be overwhelmed. There usually are so many things you can do, and it can feel like you need to validate them all. Don’t try and plan to far in advance, focus on what will help you now and next, knowing that you may have to validate more product initiatives in the future.
Now you have a prioritised list of product initiatives you need to turn the highest priority initiative into something deliverable. To do this, you need a release roadmap.
The user stories that make up your MVP in the release roadmap will form your product backlog. Depending on the way your delivery team works, you may need to estimate the backlog and calculate the team’s velocity to understand when the features will be released.
Business Roadmap = High-level objectives your company wants to achieve and the strategic bets you will try to reach them.
Product Roadmap = The product initiatives that will help the company deliver its strategic bets.
Release Roadmap = The features that will deliver the customer goals necessary to affect your product initiative.
Product roadmaps are critical to your success. Trying to create a great product without a roadmap is like going on a road trip without a map: if you’re lucky, you might eventually get to your destination, but it’s more likely you’ll get lost along the way.
To conclude, heres a few tips to help you get to where you want to go:
Businesses that create customer habits gain a significant competitive advantage. The hooked model describes how to design a product experience that creates a customer habit in four steps. Through consecutive hook cycles, successful products reach their ultimate goal of unprompted user engagement, bringing users back repeatedly, without depending on costly advertising or aggressive messaging.
The Hooked Model:
Businesses that create customer habits gain a significant competitive advantage. The hooked model describes an experience designed to connect the user’s problem to a companies product frequently enough to create a habit.
Users habits increase how long and how frequently customers use a product, resulting in higher Customer Lifetime Value (CLTV).
As customers form routines around a product they become dependant upon it and become less sensitive to price.
A company can begin to determine it’s products habit forming potential by plotting two factors: frequency of behaviour and how useful/valuable that behaviour is to the user.
Habit forming products often start as nice-to-have’s (vitamins) but once a habit is formed they become must-have’s (painkillers).
Triggers come in two forms – external and internal. To build habit-forming product makers must attach the use of their solution to a frequently felt internal trigger and know how to leverage external triggers to drive user action.
Users who find a product that alleviates their pain will form strong, positive associations with the product over time.
Dr B.J Fogg’s Behaviour Model indivates there are three ingredients required to initiate any and all behaviours:
Motivation: Fogg states that all humans are motivated to seek pleasure and avoid pain; to seek hope and avoid fear; and finally to seek social acceptance and avoid rejection.
Ability: Any product that significantly reduces the steps to complete a task will enjoy high adoption rates by the people it assists. There are six elements of simplicity that influence the difficulty of a task:
When deciding whether to focus on increasing motivation or ability, always start with ability. For companies building technology solutions the greatest ROI generally comes from increasing the products ease of use.
Heuristics are cognative shortcuts that we take to make quick decisions. Product designers can utilise these heuristics to increase the likelihood of a user taking the desired action. Examples of these hueristics include:
What draws us to act is not the sensation from the reward itself, but the need to alliviate the craving for that reward.
Without variability we are like children in that once we have figured out what will happen next we become less excited. To hold our attention products must have an ongoing degree of novelty.
There are three types of variable reward:
Only by understanding what truly matters to users can a company correctly match the right variable reward to their intended behaviour.
The more users invest time and effort into a product or service, the more they value it. In fact, there is ample evidence to suggest that our labour leads to love.
Investments increase the likelyhood of users returning by improving the service the more it is used. they allow the acrual of value in the following ways:
It’s recommended that you progressively stage the investment you want from users into small chunks of work, starting with small, easy tasks and building up to harder tasks during successive cycles through the hooked model.
]]>As with all changes, the move to remote working poses some challenges but also creates the opportunity for great benefits. Over the last two years at ThoughtWorks, I’ve seen some of these benefits and challenges as much of our internal work was remote-first. However, COVID-19 has meant that now our client-facing work must also be conducted remotely leading to a new set of challenges and opportunities.
Last week I led my first fully remote product discovery. This was a step into the unknown as I took our co-located workshop techniques and tried to translate them into a remote-first world. Through this article, I’ll share this experience and what I learned in the process. I’m sure many of you are going through the same adjustment at the moment, so I hope by sharing my experiences it will help you avoid some of my mistakes and make your discovery sessions even better!
Select the right tools: Before you start, it’s essential to ensure you have the right tools to facilitate your communication and collaboration. There are many available, but here’s what we used:
Book time in advance: It’s even more important to have a clear plan for your discovery when you are remote. Everyone needs to understand the expectations of their time and when they need to be available since we can’t just find them in the office!
Create and protect team social time: Working remotely made me realise how often breakthrough ideas happen in the casual conversations that happen over lunch, coffee or between sessions. During a remote discovery, you need to be more intentional about creating space for these conversations. I recommend scheduling virtual team lunches and coffee breaks. Attendance should be optional, and there shouldn’t be a plan, simply use the time to hang out together.
Organise a pre-discovery tech check: There’s a lot that needs to work to ensure your remote discovery runs smoothly. Everyone needs to be able to join the video calls, access the collaboration tools and work out where the best internet connection is in their house! The last thing you want is someone to be unable to contribute or to spend half your session troubleshooting technical issues. Avoid all this by having a quick team call before the discovery to ensure everyone’s tech works in advance.
Start every session with introductions: When working remotely, it’s a lot harder for people to build a connection to those in the room. It’s likely that throughout your discovery you will have different participants in every session so take the time at the start to introduce everyone. I like to get each person to introduce themselves and then pick the next person to avoid any awkward silences!
Teach people to use collaboration tools: For a lot of people who participated in our discovery sessions, it was the first time they had used some of the collaboration tools. It’s worth spending a few minutes at the start of sessions reminding people of the basics they will need to be able to contribute effectively. Trust me it will save you time later on!
Facilitate in pairs: I’m a big proponent of pairing, but it’s even more useful when facilitating remotely. We found it best to separate responsibilities, with one person running the session verbally and the other organising the collaboration space, taking notes and consolidating on the fly. I’d also recommend having a third person available who understands the plan for the session as a backup facilitator who can step in if someone’s internet goes down!
Capture everything: As with co-located discoveries, it’s vital to capture as much as possible, you never know what you will need later! I would recommend you record all your calls and also take screenshots of people on the call to bring sessions to life in playbacks. The great thing about collaborating remotely is a lot of the work is captured automatically using tools like MURAL, just remember to consolidate, add notes and share after the session!
Summarise, summarise, summarise: The amount of information that people need to consume through a discovery is vast, and it can be hard for people to remember everything. We usually get around this problem by displaying session outputs on the walls, but you can’t do that remotely. Instead, you can send round-up emails that link people to key assets in a structured way. I recommend sending a daily round-up that highlights daily learnings and an end of discovery email with all the captured assets.
Remember the retrospective: Being remote means retrospectives are even more important because it can be harder for people to raise issues than in person. I recommend using Fun Retro to collaborate and conducting mini retros regularly through the discovery as well as at the end.
There are undoubtedly challenges in running remote discoveries but not as many as you might think. I was also presently surprised by a few great benefits, including:
I’ve been surprised at how easy it has been to transition to fully-remote working. If you would like help with your own remote product discovery send me a message!
I’m also still learning and improving my methods so if you have some great techniques you’ve used, I’d love to incorporate them. I’m currently planning my first remote inception so tips and tricks are gratefully received!
]]>The Technology Adoption Lifecycle creates a vast gap between the needs/wants of the early adopters and those of the mainstream market. To reach the mainstream market innovators and marketers need to narrow the chasm and find ways to accelerate mainstream product adoption. This book explains how to target a specific niche market, offer a whole product solution and become the market leader.
A market is:
If two people buy the same product for the same reason but have no way they could reference each other, they are not part of the same market.
Markets must be segmented because no meaningful marketing program can be implemented across a set of customers who do not reference each other. Without references, you have no leverage and no company can afford to pay for every marketing contact made.
Technology Enthusiasts: Are easy to do business with provided you: 1) have the latest and greatest technology and 2) don’t need to make much money. — Direct marketing works best for this group – think demos, webinars, tutorials but avoid the flashy image-based marketing.
Visionaries: Want to find technology that provides a significant shift forward in the value that can be provided to the market. They want to use this to help them achieve their goals. — A small direct sales force is the only way to sell to visionaries because you need someone who can understand their goals and give them confidence your company can step up to them. Ensure they have the political status and funding to achieve their visions.
Pragmatists: When pragmatists buy they care about the company they are buying from, the quality of the product they are buying, the infrastructure of supporting products, the reliability of the service. They are planning to live with their buying decision for a long time. – Pragmatists won’t buy from you until you are established in the market, but you can’t get established until they buy from you.
Value-added resellers are one way to reach pragmatists if they have a reputation of delivering high-quality work, on time and on budget. Pragmatists are price sensitive and without a differentiator, they expect the best deal. The best way to win over pragmatists is to make yourself into the obvious supplier of choice.
Target a very specific niche market where you can dominate from the outset, drive competitors out this niche, and then use it as a base to expand into adjacent niches.
To capture a pragmatic customer base we must deliver a whole product, the complete set of products and services a customer needs to achieve their desired result (which should be our sales promise)
Pragmatic customers tend to delay their buying decision (creating the chasm) because they are trying to understand who the market leader will be, so we need to give reassurance that we are or will become the market leader by having other pragmatist customers we can reference. To do this we want to be a big fish in a small pond.
The key to moving beyond the initial target niche is to select a strategic target market segment, to begin with that has one or more relevant adjacent segments.
The market development strategy checklist below shows all the factors to consider when planing a go-to-market strategy. You can rate a target segment against each one.
To become a persistent entity in the market you need a market segment which will commit to you as the standard for enabling a critical business process. To become the standard you must win at least half of the new orders in the segment over the next year.
If the target segment is too small to generate half of next years sales for the new product, then you have to augment it with another segment. If there is no appropriate super-segment, you should pick another target.
There is a gap between the marketing promise (the UVP) made to the customer and the ability of the shipped product to fulfil that promise. For that gap to be overcome, the product must be augmented with a variety of services and/or products to become the ‘whole product’. There are four levels of whole product completeness:
At the introduction of any disruptive innovation, the marketing battle happens at the generic product level. As the marketplace develops and we enter the mainstream, products become more alike and the battle shifts to the expected, augmented and potential layers.
Early adopters (tech enthusiasts & visionaries) will create the whole product for themselves. But to cross the chasm and reach the pragmatist you must create the whole product for them.
If you leave the customers success (to achieve their goal) to chance, you are giving up control of your own destiny.
Big companies struggle to play in small niches. From the customer perspective, if you are willing to go the extra mile for them it builds a level of long-lived loyalty.
To accelerate your path to a ‘whole product’ you can form strategic alliances with other companies to augment the functionality of your product and support your segments compelling reason to buy.
In the pragmatist’s domain, competition is defined by comparative evaluations of products and vendors within a common category.
For pragmatists, understanding the competition is a fundamental condition for purchase. Therefore, creating competition and positioning your product within a buying category that pragmatists understand is key.
Crossing the chasm requires a shift from technology and product based values to market and company based ones.
You develop an early market by demonstrating strong technology advantage and converting it into product credibility, and you develop a mainstream market by demonstrating market leadership advantage and converting it to company credibility.
Because pragmatists, like to buy from market leaders they need to understand the competition. Creating competition involves using two competitors as beacons so that the market can locate your companies unique value proposition. We can use two reference customers to position our product:
Market Alternative: This is the vendor that the target customer has been buying from for years. Our intent here is to help the customer identify the budget they can use to buy with.
Product Alternative: The company that is harnessing the same disruptive innovation as we are, and is positioning itself as a technology leader. Our intent here is to acknowledge their technology but differentiate through our own segment-specific focus.
If you cannot find a market or product alternative you are probably not ready to cross the chasm.
Most people resist selling but enjoy buying, By focusing on making a product easy to buy, you are focusing on what a customer really wants. This is the goal of product positioning and there are four types for each customer type:
Positioning is all about the audiences state of mind, not yours.
The number one objective when crossing the chasm is to secure a distribution channel into the mainstream market. There are five types of customer to consider:
Enterprise Executives: Make big-ticket purchases, adopted across their companies. They are looking for a consultative sales experience and are best reached through relationship marketing, such as leadership events.
End Users: Make low-cost buying decisions on personal or workgroup technology. They are looking for a self-service buying experience and are best reached via promotional marketing, such as email and click-through ads.
Department Heads: Make medium-cost buying decisions for use-case-specific solutions. They are stuck between enterprise executives and end-users. Generally, the marketing approach is the same as for end-users but on upon registering interest and becoming a prospect they often referred to a human salesperson who manages the sale through, email, chat and calls.
Engineers: Make design decisions for products to be sold to their companies customers. They generally don’t like being salespeople or marketing communications. They are not generally the purchaser, but a major influencer. They are best marketed to with factual information and with samples or free-trials.
Small Business Owner-Operators: Make modest purchase decisions, that are very material to them. They are best sold to through Value-Added Resellers and reached through promotional marketing channels.
The number one concern of pricing at this stage is to motivate the channel. There are three perspectives on pricing:
Customer-Orientated Pricing: Visionaries are relatively price insensitive, whereas conservatives want low prices. Pragmatists expect to pay a premium price for the market leader (~30%).
Vendor-Orientated Pricing: This is based on the vendor’s cost base and margin requirements. The biggest impact of this kind of pricing is the number of transactions required to create the targeted annual revenue.
The higher the volume, the more transactional the process, and the more you depend on filling the top of the funnel. The higher the price, the more relationship orientated the process, the more you focus on the bottom of the funnel.
Distribution-Orientated Pricing: Is the product priced to sell and is it worthwhile to sell?
The fundamental goal should be to set the pricing at the market leader price point, reaffirming yourself as the market leader and then build a high margin to reward the channel that will be phased out as the product becomes established in the mainstream.
The post-chasm enterprise is bound by the commitments made by the pre-chasm enterprise. One of the first tasks of the post-chasm era may be to manage yourself out of these pre-chasm commitments.
In building an early market the ROI is investor risk reduction, post-chasm it is about making money.
No mainstream market can occur until the whole product is in place.
A Note on Venture CapitalUntil break-even cash flow is achieved nothing is secure, and your destiny is not under your own control. In slow-developing markets with low capitalisation, there is a strong case for adopting profitability from day one. Early customers will pay consulting fees and pre-pay to help low-capital startups.
Enterprises that are venture-funded for long-periods often fall into a ‘welfare-state’ mentality, losing their urgency and focusing on the next paycheck from a financing round, not from the market.
It can be worth taking VC money if the cost of category development and market entry is too high to fund in other ways, or the category is expected to develop so fast that you cannot afford to grow organically.
Generally, early market development efforts do not respond well to massive infusions of capital.
A Note on People
Before the chasm the organisation is dominated by pioneers, power is often held by top salespeople or product managers. By the time you enter the mainstream market, the power should be distributed more broadly among account managers and product marketing managers who are better suited to stewarding the organisation through a more settled period. This gradual dissemination of power will frustrate the pioneers, hamper the ability to make quick decisions and make them want to leave.
A Note on Compensation
Compensation should be split into two categories:
Account Development: Should reward things like the longevity of the relationship, customer satisfaction and predictability of the revenue stream. It should be spread over time and not clumped into dramatic payments.
Account Penetration: Should reward the winning of a new account. It should be provided in bulk and in recognition of a single achievement.
Equity should be reserved for people who help the company cross the chasm and contribute to the development of the whole product, not those that just contribute to the early core product.
Early-stage products can’t be measured using traditional metrics like revenue and profit; a better metric is traction. Modelling traction enables you to recognise the one clear goal for your product. With your goal in mind, identify the constraints within your product (i.e. bottlenecks) and focus on improving the output of that constraint, repeating until you reach your goals.
Life’s too short to build something nobody wants.
Traditional measures of progress like revenue, profit, and return on investment (ROI), aren’t helpful during the early stages of product development for the following reasons:
A better metric is traction: the rate at which a business model captures monetizable value from its users.
You create value for your customers through your Unique Value Proposition, which is the intersection of your customers’ problems and your solution. The cost of delivering this value is described by your Cost Structure. Some of this value is then captured back through your Revenue Streams.
It is important that you run tests early in the business model validation process to ensure that you can also capture back some of this value as monetizable value that can be converted into revenue.
Customer Throughput is Traction
Throughput is the rate at which a system generates revenue through sales. In the case of a product, customer throughput is the rate at which nonpaying users are processed into paying customers.
Let’s first more formally define each metric as it maps to the customer factory:
The universal goal of every business is to increase throughput while minimizing inventory and operating expenses provided doing that doesn’t degrade throughput.
There are three stages of product growth:
The first stage (Problem/Solution Fit) is where you test for sufficient customer pull to get the factory started. The other two stages (Product/Market Fit and Scale) are simply stepped-up versions of the first stage.
Average time to go from idea to Problem/Solution Fit is eight weeks and around 3 years to get to scale.
The distance between each stage can be modelled using a 10x rule, which works both top down and bottom up. Essentially take your customer numbers at scale, divide by 10 to get numbers for product/market fit and again by 10 to get numbers from product/solution fit.
Before you can prioritize waste, you need to be able to see the factory floor. You can visualize the customer factory using five steps:
The goal of a business is increasing throughput, which is not always the same as increasing customer throughput. Simply adding more customers will also drive up more inventory and operating expenses. You might be able to potentially drive up throughput by increasing prices instead.
Before applying an engine of growth to drive up your customer throughput, you usually have to first optimize the throughput levers in your customer factory. These levers are:
The model is sustainable when the monetizable value captured from your customers (LTV) exceeds the cost of creating a customer (COCA). For a healthy business, you should aim for a 3x ratio between LTV and COCA.
For a metric to be actionable, you additionally need to be able to derive causality. The gold standard for doing this is measuring your customer life cycle in batches (or cohorts).
Cohorts help you measure relative progress by pitting one batch of users against another.
You start by grouping your users into daily, weekly, and monthly batches based on their join date (or sign-up date). Then measure their significant user actions as they progress through your customer factory.
You can create cohorts by gender, acquisition traffic source, release dates, a feature they use, et cetera.
At any given point in time, customer throughput is limited by a single
constraint.
Bottlenecks are generally where you find excess inventory (like users) piling up, examples of inventory pileups would be users waiting on you for something—support requests, promised follow-ups, et cetera.
Constraints can be broadly characterized as external or internal constraints. External constraints are market constraints. Internal constraints can be any of the following:
A key concept from the scientific method is that guesses or theories can never be proven right— they can only be proven wrong. This is the concept of falsifiability.
Our job is to wield these guesses into strategies or growth hacks that make our business model work for some slice of time. The goal isn’t learning but achieving business results—aka traction. We do this by:
The real question isn’t whether you run experiments, but rather whether you run good experiments. This chapter will outline the ground rules for designing and running good experiments.
“If you simply plan on seeing what happens you will always succeed at seeing what happens because something is guaranteed to happen.” —ERIC RIES, THE LEAN STARTUP
You need to develop a culture that allows people to have strong opinions, strange hunches, and weird instincts that they can then rigorously test.
There is no such thing as a failed experiment, only experiments with unexpected outcomes. —BUCKMINSTER FULLER
]]>