Chapter 3. Gathering Inputs
What you’ll learn in this chapter
What the different stages are in a product’s life cycle
How to gather inputs from the market and business environment
How to gather input from your customers
How to gather input from your stakeholders
Before you run off and make a roadmap, you’ll need to spend some time gathering inputs.
The goal of gathering inputs is to make sure you have all of the relevant information and context you need to make good product decisions.
Without a constant refresh of that context, you’ll risk making too many assumptions and mistakes. As part of this process you’ll likely have lots of discussions and negotiations with your stakeholders.
Understand Where Your Product Is in Its Life Cycle
In the same way that a roadmap is relevant for all types of products, it’s also useful at different stages in the life of a product. As we see it, there are five primary phases of a product’s life cycle:
New
Growth
Expansion
Harvesting
End of life
New Product Phase
In many cases we associate the new product state with startups, but there are a number of established companies putting time and resources into innovation and expansion in the new product realm. Your roadmap in this phase of the life cycle should be used to outline and drive the creation of the first version of your product.
With a new product, you are venturing into uncharted territory. This means you will have to make a lot of assumptions, and then rapidly prototype and test to get validation and answers. That validation, or lack thereof, will ultimately impact what themes or features make it onto your roadmap.
Growth Phase
The second phase in the life cycle is scaling an existing product. This means getting it to as many customers as possible. For example, when R. Colin Kennedy was Product Manager at Sonos, the objective for the year was to get as many product (speaker) installations as possible. The team was to focus on revenue, customer lifetime value, and so on, later—after scaling the product to get it into as many hands as possible.
Roadmapping here helps you prioritize the team’s activities so all are operating to address scale. Sometimes this means a simple reorganization of features or themes to improve the user experience. In other cases you may actually remove features that are no longer necessary.
This phase is the most common for established businesses, as every company should be focused on—and its product roadmap geared to support—continual improvement.
As for risk and uncertainty, this stage tends to be low in both areas. Since the target customer base is known and you have a good understanding of their problems, product discovery is usually a bit smoother.
Product Expansion Phase
In the third phase we’re focusing on here, a company uncovers an opportunity to expand the core product or product line into a new area. The new product opportunity is still linked to the core product, but it introduces fresh functionality and addresses an entirely new need. A good example is the popular flight aggregator site Kayak.com. When Kayak started, it did one simple thing: it allowed users to search for flights across multiple airlines at the same time, filter options, and compare costs. Once Kayak established itself in the market, it realized this format would also work for hotels and cars.
Harvesting Phase
The fourth life-cycle phase we want to mention is the “cash cow product” that simply needs to be maintained. In these cases, the product team has successfully found product-market fit, has usually been in the market for an extended period of time, and has a solid and growing base of customers. The product team has done a great job of delivering value, and for the most part users are happy. A good example here is Google AdWords. According to a 2016 article from Investopedia, “the bulk of Google’s $75 billion revenue in 2015 came from its proprietary advertising service, Google AdWords,” so it’s clear AdWords is the definition of a cash cow product. We can suppose that the prime directive for the AdWords product team has been to keep the product useful and relevant, so customers keep coming back for more.
Product teams in this phase cannot sit back on their heels and simply rake in the profits. The more customers commit to a product, the more demanding they will become. Therefore, teams at this stage should have a constant and revolving roadmapping process that uses customer feedback to inform their decisions about what changes and continuous improvements to make.
End-of-Life Phase
The fifth and final life-cycle phase may feel a bit less relevant for the roadmapping process, but we assure you it requires a similar level of strategy and planning. This is the sunsetting product phase. Yes, it’s disappointing to think about, but sometimes products fail (sad emoji). Most people think a roadmap is about progression and growth, and most often, that’s the case. However, it can also be used to wind down and take a product off the market. Sunsetting a product can be a complicated and delicate task and usually requires a good deal of planning and alignment. Using a roadmap at the end-of-life phase is an incredibly useful way to wind down with ease, dignity, and strong communication across stakeholders.
Gathering Input from Your Market
Once you have a clear understanding of your product life cycle, it’s time to look externally to learn about your market.
Understand Your Ecosystem
It seems obvious that to build a successful product, you need to comprehend the business ecosystem in which you operate, but in practice this understanding is frequently missing from product teams. Often we see that the product leader has sufficient knowledge of the business space, but the rest of the team does not. The designers, engineers, and other team members assume it’s the product manager’s responsibility to understand the business and to communicate strategy to the rest of the team. While this is true in theory, in practice we advise against it. In our opinion, every member of the team should have a basic understanding of the business environment.
If you don’t do the work up front to truly study the business landscape, you start off with a faulty map. Like a 15th-century explorer trying to reach new lands with a map that shows only half the world, you can very easily end up in the wrong place.
There are a number of tools and techniques for gathering the business knowledge you need in order to think strategically about your product. We certainly can’t review them all here, so we’ll leave that to the more qualified consultants and world-class business schools. What we can do is recommend that, at a bare minimum, you assemble a basic business model analysis for your product. Business model templates like Alex Osterwalder’s Business Model Canvas and Ash Maurya’s Lean Canvas can guide you through this step. These tools help you identify and think strategically about the pillars of your business, such as:
Problem and solution
Value proposition
Unfair advantage
Key metrics
Customer segments
Distribution channels
Costs
Revenue model
Key partners
Key resources
We have found that the Lean Canvas is very effective for startups or new products, whereas the Business Model Canvas works well for existing products or growing businesses. That’s just our opinion, though, and you should test a variety of tools to decide what works best for you and your team. If you can’t complete one of these canvases at a basic level, you’re certainly not ready to build your roadmap. Without this base level of understanding, you are starting your journey with partial information or too many assumptions, either of which is a recipe for disaster in product development.
Define the Problem and the Expected Outcome of the Solution
One very rough way to determine a product person’s level of experience is that the novice focuses on features, while the seasoned pro focuses on problems. The best product pros take this to the next level and ask, “If we solve that problem, what’s the outcome we want to see?” There’s no better way to find that outcome than to understand your customer. Vanessa Ferranto, Director of Product at The Grommet, explains that this isn’t as simple as you might expect: “You just want to get something out there in order to gather validated learning. Sometimes you’re successful, you see a positive outcome and you can continue to build on that. Sometimes the outcome is not what you expect and you have to revisit your approach.”
In Steve Blank’s Customer Development Model he stresses the importance of sequencing your exploration of the problem and solution, and the expected outcome.
He starts with Customer Discovery, which supports the criticality of understanding customer problems and needs. He expounds on the value of getting out of the building to validate the core problem you’re addressing before you even think about moving to the next step. Often what a potential customer thinks is the problem is just a symptom of a much larger problem. Once the problem has been confirmed through direct interaction with your target audience, Steve’s model moves onto Customer Validation, Customer Creation, and Company Building. The Customer Validation step requires you to prove that at least some of your target audience is willing to pay for your solution. The third step, Customer Creation, is about demonstrating your early success will lead to growing demand and a more sustained sales pipeline. Finally, according to Blank, Company Building happens when product and sales are strong enough to justify the expansion of the initial team into a more established company structure with formal departments.
Gathering Input from Your Customers
One of the most critical parts of effective product development is to properly identify who your customers are, and then to truly understand and empathize with them—their jobs, wants, needs, obstacles, frustrations, emotions, and more. If your product exists to solve a problem for someone, then you have to intimately know that “person” in order to address their needs. Doing so not only helps you validate what the problem is, but is also critical in understanding how best to solve it for them.
What this means is that every item on your product roadmap should address an actual customer need. And to address their needs, you need to understand their needs. Trying to roadmap without a deep level of empathy for your customer will invariably send you down the wrong path and waste your time. When this goes unchecked for too long, it eventually leads to product failure. Incorporating customer knowledge into your roadmapping process will ensure you’re building the right things, for the right people, for the right reasons.
Customer Roles
Before we get into some suggestions about how to identify and empathize with your customer base, let’s set some guidelines and clarify terminology.
From our perspective, user roles focus on jobs and functions. In other words, a user role describes the primary action taken by a particular user. For example, let’s consider the popular online education platform Lynda.com. Lynda offers classes in business, software, technology, and creative skills to “help users achieve their personal and professional goals.” Before building a platform, Lynda recognized a gap in the education market around professional skill development. Presumably, they realized many people wanted a way to enhance a skill set without having to attend in-person adult education classes. These traditional classes can be time-consuming and expensive, so the team at Lynda decided to provide a lightweight, remote option for functional education. If we take a very broad view of this problem area, we can immediately identify two roles: the student and the instructor. It’s easy to see that in order for Lynda to successfully solve the problem, they needed to create a platform that would add value to both the student and the instructor roles.
Users Versus Buyers
It’s also important to differentiate between users and buyers. It may be obvious, but users use the product and buyers buy the product. In some cases, this is the same individual, but in other cases, it’s not. In the enterprise or B2B world, it’s often the case that the buyer is an entirely different person than the user. For example, the VP of Sales might decide to purchase an annual subscription to Salesforce.com, but it’s most likely the sales managers and sales reps who will use the product on a daily basis. In the consumer or B2C world, on the other hand, it’s much more common for the buyer and user to be the same person. For example, a music lover may decide to purchase a monthly subscription to Spotify and will ultimately be the one that benefits from the service. In that case, one individual effectively represents both the buyer and the user.
To return to our Lynda.com example, we can assume that the student role’s user type is “end user” because she will be using Lynda to take classes and learn new skills. We also recognize that she is a user and a buyer, because she’ll not only be benefitting from the classes directly but also be paying for them out of her own pocket (see Table 3-1).
| User role (who/do) | User type(s) | |
|---|---|---|
Student | To learn | End user, buyer |
Roles Versus Personas
Finally, let’s differentiate between user roles and user personas. Too often these two are conflated or misunderstood. It’s important for the product pro to understand the difference and how they relate to each other.
A persona is often defined as a representation of a user that embodies the characteristics, feelings, and preferences of a user set. Personas deal with softer characteristics. They are typically depicted with a photo or image surrounded by descriptive characteristics and supporting attributes.
Personas are valuable because they help us to empathize with buyers and users. They allow us to put ourselves in an individual’s shoes and see the problem from his or her point of view. The goal is not just to know who your customers are, but to truly understand them.
Roles help us categorize the different customers our product will help, and personas allow us to take our understanding to a deeper level. For example, if we consider again the role of the student, we can assume that every student who uses the Lynda platform will need to watch videos, download documents, ask questions in a forum, and so on. However, to create a really valuable experience for every kind of customer, we can use personas to uncover additional layers related to their needs. Professional Paul might need to download a history of payments so he can submit an expense report to his employer, who has agreed to cover the costs of his class. Or Social Sam might want to see detailed profiles of the other students in class so he can make friends through the network.
Let’s connect all of this user talk back to the roadmap. Understanding your customer base in great detail helps you envision their needs and uncover the jobs that your product will need to help solve. In order to know what your users need, you first have to know who they are, what motivates them, and what actions they take. To do this, you must get out of the building and interact with them directly to understand what they’re thinking, feeling, seeing, hearing, saying, and doing.
Gathering Input from Your Stakeholders
Up to this point, everything we’ve talked about in this chapter has been related to external factors—your users, their needs and behavior patterns, and the business environment in which your product will live. However, we also want to address an incredibly important internal factor as well. As a product person, you cannot build or grow your product in a vacuum, no matter how good your instincts are. You may be able to get a version 1 off the ground on your own, but going any further will require additional support. Therefore, your roadmapping process needs to incorporate collaboration from all key stakeholders.
First you need to identify all your stakeholders. At a bare minimum, most product teams are made up of a product manager, designers, and engineers. This small group is what we call the product core (see Figure 3-1). The product core is generally responsible for designing, building, shipping, and/or maintaining a particular product or version.
Figure 3-1. A product core team consists of those who work directly on the product: Product Manager or Owner, designers, and engineers
| Stakeholder | Benefit | Contribute |
|---|---|---|
Customers | Get excited about how they will benefit in the future | Provide feedback on value and priorities |
Executives | Understand how resources are being used and potential ROI | Provide strategic context for product direction and priorities |
Sales | Be ready to respond to questions about future product direction from customers and prospects | Provide feedback on what will make prospects buy and customers renew |
Marketing & PR | Prepare for launch and promotion of future products or features | Provide feedback on what will get the attention of the target market |
Customer Support | Be ready to respond to customer inquiries about bugs, usability issues, or future features | Provide feedback on the top reasons for support calls |
Research | Plan research projects to support future roadmap themes | Provide information about the market and users to inform themes and priorities |
Other Product Teams | Sync their technical approach and release schedule with your team | Sync your technical approach and release schedule with their team |
Operations, Production, Purchasing, HR | Understand future infrastructure, tooling, plant, personnel, and other scaling needs | Provide insight into infrastructure, tooling, plant, personnel, and other costs of proposed roadmap items |
Finance | Understand planned spending and expected ROI | Provide feedback on available budget and ROI targets |
Vendors & Technology Partners | Plan for timing and volume of required components & supplies, performance specs | Provide feedback on capacity and performance specs, provide insight into new materials and technologies |
Channel Partners | Plan assortment, pricing, promotion, training & distribution | Provide feedback on what will likely sell, timing & pricing; plan co-marketing |
However, throughout the life cycle and development of a product, the core needs to work in conjunction with many other stakeholders, who contribute to the roadmap (see Table 3-2, previous page).
For small or early-stage organizations, the group of stakeholders should be small. However, as the product and its influence grow, additional layers of collaboration and support will be needed. You might envision these as rings surrounding your product. How these layers or rings are defined, and which stakeholders populate them, will depend entirely on the structure of your team and business.
For example, the rings might represent knowledge of the product space or customer base, influence over decisions, or even frequency of interaction with the product team—which is the example we’re using here to demonstrate a typical hierarchy of the groups and individuals associated with the creation, adoption, and management of the product roadmap (see Figure 3-2). Ultimately, you will need to define how your collection of stakeholders should be organized, and how you will interact with them.
Figure 3-2. The product core typically designs, builds, ships, and/or maintains a particular product or version
“Each customer-facing team creates their own top-10 list and then all those teams merge their lists together to come up with an overall prioritized list representing the Voice of the Customer,” says Jackie Bavaro, Head of Product Management at Asana. “Those lists are helpful when understanding what our internal stakeholders would like to see. This process ensures that each team gets to share their unique perspective, and the merging process empowers the teams to be directly involved in the ranking. Once I have that list, I then uplevel from specific feature suggestions into broader themes and consider additional tactical and strategic factors to determine the roadmap.”
We’ll talk more about stakeholders in Chapter 8, but in the beginning it’s very important to identify who your stakeholders are. As you do, make sure to identify the role they will play in the development of the product.
At different points throughout the roadmapping process, you’ll bring these individuals into the conversation. Your commitment to involving stakeholders will greatly improve the quality of your product, and also make the road to building it much smoother.
Figure 3-3. Product roadmap prioritization and costing example
Summary
Trying to create a product roadmap without a basic understanding of the product’s domain and its users will leave you groping around in the dark designing for fictional scenarios with biased assumptions. As you can imagine, this is a risky path to tread. Falling prey to the hubris convincing you that you already have all the context you need will result in wasted time, effort, resources, and of course money. So, to put it plainly: do the up-front work to gather or update the key inputs we’ve mentioned so you can be informed and prepared to build winning products.
The aforementioned inputs are not intended to encompass every bit of context you need prior to embarking on your roadmap effort, but they are the most important ones. There are other things, like full comprehension of the current or intended technology stack, that you’ll want to have a grasp of as well. A good way to think about this is, the more information you have about the space in which you are operating, the more effective you will be as a product leader. Your role will require you to make sense of all of these inputs, interpret how they will affect the product, and then build that knowledge into your roadmapping process.