It’s Not the Roadmap, It’s How You Use the Roadmap

One of the best pieces of advice I ever received as a working product manager was to think of roadmaps as a strategic communication document, not as an actual plan for what will be executed and when. Unfortunately, I immediately misinterpreted this advice to mean that everybody already understood that the roadmap was not an actual plan for what will be executed and when. This got me into hot water more than once, as I had to explain to various stakeholders (ranging from engineers to [clears throat] board members) that the roadmap I had provided did not actually reflect what my product team was planning to build. After all, somebody really smart told me that a roadmap isn’t a promise, but rather a strategic communication document. Didn’t they get the memo?

If my misstep illustrates one key lesson, it is this: your organization needs to have an explicit and shared understanding of what a roadmap means and how it is to be used. Is it a hard-and-fast promise? A set of high-level “maybe” ideas? Are the next four years of your product roadmap as set in stone as the next six months? Unless you have taken the time and effort to discuss and clearly answer these questions, you likely do not have this understanding. If you are not sure whether you have this understanding, you do not have this understanding. And in the absence of this understanding, roadmaps are not only useless, but actively harmful.

Here are a few guiding questions to help you get started with creating a clear sense of how your organization intends to use its roadmap:

• How far into the future should our roadmap go?

• Does our roadmap make a distinction between “short-term” and “long-term” plans?

• Who has access to the roadmap? Is it user-facing? Public-facing?

• How often is the roadmap reviewed and by whom?

• How are changes to the roadmap communicated and how often?

• What criteria does something need to meet to be added to the roadmap?

• What could somebody within the organization reasonably expect if they see a feature on the roadmap three months from now?

• What could somebody within the organization reasonably expect if they see a feature on the roadmap two years from now?

The answers to these questions will vary based on your product, your organization, and your stakeholders. What is most important is not how you answer these questions, but rather that you ask and answer these questions at all.

“The Product Manager Owns the Roadmap!”

I recently had coffee with a friend of mine who had just started working as a product manager at a large education company. A few weeks prior, he had attended a training for new product managers that was intended to provide him with some more clarity on what would be expected of him in his day-to-day work. In walking through the high-level responsibilities that participants could expect to fall on their shoulders, the trainer stated, “The product manager owns the roadmap.” My friend—whose willingness to ask an uncomfortable question speaks to his skill as a product manager—interjected, “What about product manager roles where you don’t own the roadmap?” The trainer, genuinely confused by this question, responded, “No. The product manager owns the roadmap.” My friend did not press further.

This story speaks to the enormous disconnect between a product manager’s theoretical ownership of a product roadmap and their day-to-day ability to direct and influence that roadmap. Even when a product manager “owns” the roadmap on paper, this ownership is never absolute, easy, or uncontested. Long story short, everybody has ideas about what the company should build, and everybody feels that their success or failure at the organization is at least partially a function of their ability to get these things built. Although owning the roadmap might feel like a glittering prize for a product manager, it is more often a focal point for disagreement, perceived slights, and the writing of proverbial checks that cannot be proverbially cashed.

Here’s an example of how this might play out. You recently started as a product manager, and you’re eager to show your value by participating in high-level, strategic work. So, you start putting together a new version of the roadmap, culling together bits and pieces from other documents around the organization. You are going to create the one roadmap to rule them all, and in doing so, you are going to position yourself as the true keeper of the organization’s product vision.

Unsurprisingly, everybody has a lot of ideas for the roadmap and is eager to meet with you. Sales and account management have major priorities that they need to get in there. Marketing has some ideas, too. You do your best to put something together that meets everybody’s needs—or at least the needs that align with your vision for the product. You begin to feel kind of like roadmap Santa Claus, handing out spots in the roadmap to all the good kids and lumps of product coal to anybody whose vision doesn’t align with yours (and maybe a few people who have personally annoyed you in the past). You are very strategic about who gets to see the roadmap and who does not. After all, the last thing you need is somebody trying to add their own ideas to the roadmap without going through you first.

As you begin to execute against your roadmap, you run up against some product interdependencies that you hadn’t fully thought through. For your product vision to succeed, you’re going to need a few other product managers in the organization to make nontrivial changes to the way their products are designed. It dawns on you that these product managers are the very people you excluded from your initial roadmapping conversation out of concern that they would derail your vision or compromise your status as the true owner of that vision. You begin to get a little bit nervous.

You schedule a meeting with one of these product managers, prepared to beg and barter your way to victory. But it turns out that your efforts to exclude this product manager were even more successful than you realized. Unbeknownst to you, this product manager already had a roadmap for their own product—and the changes you need are not on it. You are suddenly hit with the realization that your “one roadmap to rule them all” is just one of many roadmaps—and all you’re left “owning” is a great big mess.

As a product manager, your job is not to covet and defend the roadmap; rather, it is to open the roadmap to a shared, company-wide discussion about what you are building, who you are building it for, and why. As a rule, the product roadmap should be something that encourages collaboration and focuses that collaboration around high-level goals.

Answering the questions in the last section of this chapter is one step toward not feeling like a roadmap is something that needs to be protected and “owned.” If everybody in the organization knows how a roadmap is being used, there is much less chance of it being used in a counterproductive way. As a rule, it is helpful to ask, “What steps do I need to take that will make me more comfortable sharing this roadmap with the entire organization?” rather than making excuses for why the roadmap would be disastrous if it ever got into the hands of a particular person or team.

Structure and Facilitate Ideas for the Roadmap, Don’t Own Them

Many people are drawn to product management because they want to be the person who “has great ideas” for how to build or improve a product. The truth is, everybody at every organization has lots of ideas about their product. I have never once walked into an organization where there was an actual deficit of product ideas going around. Come to think of it, I don’t think I’ve ever worked on executing an idea that was truly “mine” in the first place. The challenge for a product manager is not so much to have ideas, but rather to establish criteria that can be used to consistently evaluate ideas against user needs and business goals.

In practice, this means providing your colleagues with a productive way to share their ideas with the organization at large. Early on in my career, I tried to do this with a “product idea dump” document. This failed for two reasons. First, the very idea of a “product idea dump” spoke to the, uh, esteem in which I held my colleagues’ ideas. Second, simply giving people a place to “dump” their ideas did nothing to structure their ideas, or to communicate how these ideas would be evaluated and why.

Rather than giving people a place to dump their ideas—the very idea of which suggests that those ideas are not to be taken very seriously—consider providing templates that structure these ideas. The specifics of this template will vary depending on your product and your organization, but here is a generalized place to start:

Even a simple template like this will help structure and filter the ideas coming in from your colleagues around user needs and business goals. I’ve found that templates like this turn “playing product manager” from an annoying thing your colleagues do into an effective filter against half-baked ideas, or ideas that unintentionally move organizational goalposts.

If you’re worried about giving up your status as the company’s idea person, worry not: the product ideas that you are most likely to execute successfully are not your own. If you are truly willing to throw your full weight behind somebody else’s idea, you already have a crucial evangelist in the person who initially suggested the idea. You have left no room for people to assume that you are only pushing through an idea because it is your idea. And you have demonstrated that the ideas that best align with the organization’s overall vision are the ones that will be built. If you can get past the need to be perceived as an “idea person,” it is truly a win–win.

Your Product Spec Is Not Your Product

As you are working on your product roadmap, you might find yourself spending a lot of time describing at great length how exactly each item on the roadmap will look, feel, and work. Product specifications (usually referred to as “product specs”), like roadmaps, are strategic documents that help guide and facilitate the creation of your product. But they are not your product. Working on an extensive, beautiful, comprehensive product spec can feel like a productive and valuable way to contribute to a product’s development—something you can actually do on your own time with your own hands, rather than just “facilitating” or “supporting.” But your users see no benefit from that spec—they are using the product you have actually released. Putting some time into a product spec can be critical for making sure that you understand what you’re building and why you’re building it. But putting too much time into a product spec can create a false sense of certainty that actually makes it harder for your team to successfully collaborate.

One approach I’ve found very useful is to treat product specs like conversation starters, rather than hard-and-fast plans. If a question comes up about how we will build something, I include that question in the spec itself, rather than providing the answer that I think is best. Doing so communicates clearly to my team that they are co-creators of the product and trusted partners in deciding how to build it, not just “code monkeys.”

Keeping this rule in mind can be useful regardless of how exactly you write your product and feature specifications. Many teams operating under the broad banner of “Agile,” for example, write out feature and product ideas as “user stories,” using the format “as a [role], I want [feature] so that [reason].” These user stories are often accompanied by “acceptance criteria,” which are the specific conditions that must be met for this feature to be deemed acceptable in its implementation. So, if you were planning to build a social sharing feature for a music app, you might write, “As a user, I want to share a playlist with my friend, so that they can hear the songs I think they will like.” This user story might have acceptance criteria such as “User must enter a valid email address for the person with whom they are sharing,” and “Playlist being shared must have at least one song.”

At their best, user stories help keep product development solidly grounded in user needs. But they can also perpetuate the assumption that critical prioritization and research work has already taken place. Do we know that our users actually want to share a playlist? And how will launching this feature help us achieve our specific team and company goals? As with any highly prescriptive practice, writing “user stories” can inadvertently shift the goalpost from writing a useful and actionable product or feature spec to writing a formally correct product or feature spec.

Rather than trying to address every possible downstream detail in your product spec—or insisting that your product spec adheres perfectly to a format like user stories—make sure that you spend as much time as possible tying every product, feature, and idea back to a clear goal. This will help structure your thinking as it becomes time to plan and prioritize the actual work of building something, and it will give you a chance to reevaluate the roadmap if your goals change. Again, leveling up the conversation from technical details to higher-level goals will give everybody, including your technical partners, more room to find the best possible solution when the product or feature is actually being built.

Wait, You Mean We Actually Have to Build This Now?

In practice, short-term prioritization is often a much bigger pain point than medium- and long-term roadmaps. Why? Because it’s much easier to say, “We’ll build that in six months” than it is to commit the organizational resources needed to actually build something in the next week, month, or time-boxed “sprint” of work. Roadmaps often become bloated, unwieldy, and unreliable because it is so very easy to say, “Sure, we can add that to the roadmap.” But when it comes time for prioritization, you are working with a fixed amount of capacity, and there are always more super-important things to build than there is time and resources to build it.

For this reason, it is often short-term prioritization, not medium- and long-term roadmapping, where your organization’s goals are really put to the test. The bottom line with prioritization is this: prioritization will be as easy or as difficult as your goals are clear, well understood, and actionable. For that reason, prioritization tends to be a microcosm of organizational dynamics at large. Is your organization slapdash, disorganized, and chaotic? Your prioritization process will likely be the same. Is your organization noncommittal, bureaucratic, and accountability-averse? Welcome to your prioritization process. Prioritization is where organizational goals and vision turn into actual decisions about timing and resource allocation. As such, it provides us with a critical opportunity to see how well our organizational goals and vision are actually serving our day-to-day work.

This means that the most important step you can take toward effectively prioritizing might not be sorting through a million product ideas, specifications, and user stories. Instead, you must do whatever you can to make sure that your organization’s goals are as clear and actionable as possible. The most important work of prioritization often happens before you actually sit down for a formal prioritization meeting, when you define and clarify the goals that will guide your prioritization decisions.

By way of example, suppose that your team has been tasked with prioritizing the next two-week “sprint” of work from a “backlog” of potential product and feature ideas. As you look through the product backlog in preparation for your planning meeting, you realize that it is totally unclear which of the things you could build is most important. What do you do?

You could send an uncomfortable email to your manager asking for some time to help clarify. Or, even better, you could approach your manager in person and explain that you need some help understanding your company’s goals, and that you need to get this sorted before your prioritization meeting. This will likely not be an easy conversation. You might need to ask the same question several times. You might need to walk through different scenarios with somebody who just wants to get on with their day. But by the time your conversation is over, you will (hopefully) have a better sense of what your team needs to do to meet the company’s goals and serve your manager’s strategic vision.

Now, let’s imagine that you’re having the kind of day where you reeeeeeally don’t want to mess with any of this “goals” stuff. “It’s fine,” you say to yourself, “We’ll figure out what makes the most sense during the prioritization meeting and work on that. If it doesn’t align with our goals, it’s my manager’s fault for not being clear in the first place!”

Imagine the planning meeting that follows in both of these scenarios. If you were working as an engineer or a designer, which meeting would you rather attend? And, if you were a senior leader in the organization, which meeting would you rather let determine how your well-compensated employees are spending their valuable time?

SMART Goals, CLEAR Goals, OKRs, and so on

There is no shortage of information out there about different ways to bring rigor and structure to your organizational goals. You’ve got your SMART goals (Specific, Measurable, Achievable, Relevant, Time-bound); you’ve got your CLEAR goals (Collaborative, Limited, Emotional, Appreciable, Refinable); and you’ve got your Objectives and Key Results or OKR framework. Which of these works best for you will depend enormously on your specific product, team, and organization—as well as your own preference for more numbers-based approaches versus story-based approaches. Even a cursory scan of SMART versus CLEAR can help you think through whether your particular team would be more receptive to “measurable” goals or “emotional” goals, for example.

In my own work, I have come to favor the Objectives and Key Results framework, primarily because it allows for both a qualitative rallying cry (objective) and quantitative measures that indicate that you are moving in the right direction (key results). There are a number of great resources out there for learning more about the OKR framework, but I am particularly fond of Christina Wodtke’s book, Radical Focus (Boxes & Arrows, 2016). Wodtke writes in vivid narrative detail about the common pitfalls that teams encounter when implementing OKRs, and makes an incredibly strong case for the subtractive and focusing power of having clear and well-understood goals.

One quick caveat for product managers looking to implement the OKR framework: every single time I’ve seen a product manager try to bring OKRs to their entire organization—with the exception of very, very small and early-stage startups—I’ve seen it struggle to take hold, and usually outright fail. The “by-the-book” way to do OKRs is to implement cascading goals at the individual, team, and organizational level. But building a solid practice around OKRs for your organization—changing the rules, not breaking the rules—takes time and experimentation. My suggestion is to begin small and simple, by reframing your team’s goals, seeing what works and what doesn’t work, and using those learnings to scale the practice beyond your immediate team to the organization at large.

Later in this chapter, we’ll take a look at an example of how rewriting goals in a lightweight OKR-like format—or, really, any format that encourages discipline and rigor—can help make prioritization much easier.

Taking Your Goals for a Test Drive

Regardless of what framework you and your team use to articulate your goals, there is one sure-fire way to determine whether they are easy to prioritize against: take them for a test drive.

When I was consulting for a growth-stage startup, I made a point of sitting down with the CEO every quarter to review the organization’s goals before they were shared with the product team. (The mere fact that the CEO was writing out a document with definitive and transparent quarterly goals put this company ahead of many other similarly sized companies I have encountered.) The way we reviewed these goals was quite simple: We went through a backlog of potential product and feature ideas to see whether the goals that the CEO had written out would clearly tell us what we should work on next. If we had one project that would increase revenue and one that would potentially bring us new users, which one was more important? If there was a long-standing user complaint about an existing feature, how could we quantify its value compared to a shiny new feature?

Working directly with a senior leader to test-prioritize feature and product ideas against goals has a number of important, positive effects beyond simply improving the quality and clarity of the goals. First, it helps senior leaders feel connected to the product decisions being made by your team, making it less likely that they will question or override your decisions down the road. Second, it gives your team more leeway to change executional details if needed, because you have asked someone in a leadership position to commit to goals, not to solutions. And finally, it opens up a channel of helpful and mutually constructive communication between you and senior leadership, which can prove very useful for many different reasons.

Making Room for Old Stuff and (Truly) New Stuff

One of the biggest challenges around short-term prioritization is ensuring that you aren’t making decisions based on what people on your team feel like working on or think is cool. In theory, prioritizing against a clear set of goals helps solve for this. But having good goals in place will take you only so far if the only ideas you are actively looking to prioritize are ideas that you’ve already decided are cool, new, and interesting. So what do you do if the options you’re discussing all feel more shiny and new than they do useful and goal oriented?

For starters, don’t outright dismiss shiny and new things. Work with your team to understand why these things are so exciting. What about this new technology is so appealing? What about this new feature idea has your team advocating so enthusiastically for it? Rather than fighting the momentum behind shiny and new ideas, see if you can direct that momentum toward the ideas that will deliver the most value for your users and your business. If a shiny new idea could solve a specific problem for some of your users, but some quick revisions to an existing product could solve that same problem for more of your users, you are in a great position to bring new excitement to old products.

For example, imagine that a developer on your team is really excited about allowing your users to log in with their credentials from a cutting-edge social network. This developer arrives at your prioritization meeting with a few emails from users who have requested this very feature. You pause for a moment and try to suppress your frustration. How in the world could this person think that something so marginal and untested is worth prioritizing? In an effort to swat away this suggestion by way of a goal-based question, you say, “Interesting… how many of our actual users do you think are currently unable to log in because this feature is not available?” The developer nods with resignation. You kept the team on track.

Unfortunately, you also might have missed an important opportunity. Something about this idea had your developer excited enough to dig through user feedback before your prioritization meeting. Perhaps this developer is really passionate about improving the overall login experience for your users, which might open up an important discussion about less shiny and new but potentially more impactful ideas, such as improving your password recovery workflow. Perhaps this developer read about how the cutting-edge social network in question took a truly novel and interesting approach to its authentication workflow, which might open up an important discussion about what makes an authentication workflow successful in the first place. Something about this idea got your developer truly motivated, but you won’t be able to harness that motivation if you look for ways to dismiss their suggestion outright.

Taking this approach, you might find yourself talking through a brand new idea that you haven’t had time to formally define and spec out. And if you approach prioritization as a way to answer the question “what well-defined product and feature ideas will we use our capacity for the next iteration to build?” then this idea may simply fizzle out. But your team’s time is not always best spent building. It is critical that you also make time for learning, researching, and experimenting—and that you protect that time by explicitly making it part of the work that you are prioritizing.

In Agile parlance, a finite amount of time devoted to learning, researching, and/or experimenting (as opposed to building or coding) is often called a “spike.” In keeping with “the best thing about best practices” from Chapter 4, using this specific language can be helpful in communicating that you are not haphazardly taking time away from executional work, but rather committing a specific and finite amount of time to exploring how best to approach that executional work.

Some of the most important product decisions I’ve seen made by members of my team have happened when the first item on their to-do list for the next week wasn’t “write a bunch of code to complete this feature,” but rather “research five possible implementation approaches that would help us better understand this feature.” Just because we are going into execution mode does not mean that we should stop learning, or that the only work we should value and prioritize is work that results in an immediate product output.

But This Is an Emergency!

In theory, one of the primary functions of both a roadmap and a prioritization process is to determine both what will and what will not be built in a given timeframe. But in practice, every single organization must deal with “emergency” feature requests. (We walked through one such request at the end of Chapter 6.) In keeping with the spirit of changing, not breaking, the rules, I often suggest that product managers set up an official process and/or template for handling last-minute requests. The following basic template can provide a good place to start:

This particular template assumes that the requests coming in are likely to take the form of “this thing is broken,” but depending on the specifics of your organization, you can customize it to accommodate for feature-happy marketing teams, account management teams that request last-minute custom work, and even developers who seem to habitually prioritize a new bug that they discovered over the work they had set out to do in your prioritization meeting. You can also fine-tune the specific questions around the number of users affected and the potential revenue ramifications based on how broadly accessible that information is within your organization. (Or, even better, use this template as a starting point for making that information more accessible!)

In many cases, I’ve found that the mere presence of a template like this makes the volume of emergency requests drop significantly. After all, it’s much easier to storm into a room and say, “THIS NEEDS TO BE FIXED RIGHT NOW,” than it is to sit down and work through figuring out the actual impact of the thing you’re about to ask somebody else to work on for you.

Prioritization in Practice: Same Features, Different Goals

Imagine that you are working as a product manager at an ad-supported video startup. Your company pulls in video from around the web to create “personalized video playlists” that people can enjoy at parties, on their commute, or just for killing time. You know that video is huge right now, and you know that there’s a lot of potential in personalized aggregation as the video market becomes more fragmented.

As you sit down to approach your next prioritization meeting, you see five items on the roadmap slated for the next quarter:

• Connect to new display advertising network

• Add social sharing feature

• Build functionality for sponsored video playlists

• Improve personalization algorithm

• Launch iPad app (currently iPhone and Android-only)

Some of these ideas have been kicked around within the company since it started. Some of them were supposed to be built last quarter, but were pushed back. And some of them wound up on the roadmap because senior stakeholders kept asking for them, and you found it much easier to say, “You’ve got it, it’s going on the roadmap!” than to debate the finer points of something you wouldn’t really need to think about for a while.

As is often the case, these things are all very different from one another. It’s not entirely clear why you would build one over the other, or even what kind of resourcing they would require. So, you turn to your organization’s goals. Wait, goals? This is a startup. You rummage through some old emails from your founder, and find the closest thing to a mission statement that you can. It reads:

Our goal is to completely transform the way that people consume video. By aggregating video from all over the web and using machine learning to create a “personalized playlist,” we can disrupt the media industry and create a better experience for our users.

You read that over a few times, and blink. How would you prioritize these five potential ideas against those goals? It’s not easy, is it?

Now, suppose that, rather than just winging it, you decide to sit down with the founder and take these potential ideas for a test drive. You begin with the simple question, “How can we make this quarter’s goals clear enough that we wind up building the things that you would want us to build, even if you aren’t present at our prioritization meetings?”

After going back and forth a few times, you wind up with the following Objectives and Key Results–style goal for the next quarter:

Our high-level goal for the next quarter is to get our product in front of anybody who is currently engaged in the behavior of watching videos across multiple platforms. We will know we are on the right track toward achieving this goal when:

• Weekly app downloads have increased by 50%

• Weekly new user signups have increased by 50%

• The average number of connected video platforms per user has increased from 1.3 to 2

You know that this goal and its corresponding success metrics are not perfect or 100% comprehensive, but when you went through them with the founder, you were able to strike a few items off your list (especially those that might increase revenue without contributing to user growth). There are a few ideas you need to research a bit more (how many users are you currently losing to not having an iPad app?) but at the very least you have a clear sense of how to proceed. Some of the sales folks might be annoyed that you won’t be working on their priorities first, but you’re not too worried about it because your choices are clearly being driven by company-level goals.

Or, imagine that your conversation with the founder goes very differently. After the meeting, you wind up with the following Objectives and Key Results–style goal for the next quarter:

Our high-level goal for the next quarter is to increase the company’s revenue while minimizing the need for customized development work. We will know that we are achieving these goals when:

• Overall revenue has increased by 30%

• The percentage of revenue coming from automated ad systems has increased from 30% to 60%

• We are able to continue at or exceed our current rate of user growth

Again, these are not perfect or 100% comprehensive. But they provide some clear guidance about what you might want to build right now, as well as some guidance about how you might want to implement some items on the roadmap (could you build a “sponsored video playlist” system in a way that would not contribute to increasing customized development work?)

When it comes time to actually prioritize these ideas, there will still be discussion to be had and work to be done. You might find yourself using prioritization techniques such as stack-ranking or an impact-versus-effort matrix. But whatever technique you use, the resulting decisions will be as good as the goals that guided them.

Summary: Let Them In!

Creating and populating a roadmap and managing short-term prioritization can often feel like the most high-status tasks for product managers. Not only does this work give you the chance to make important decisions about what is actually being built, but it also affords you a rare opportunity to point to an actual thing—like a roadmap document or an in-depth product spec—and say, “I made that all by myself!” But as with all aspects of product management, roadmaps and prioritization are best approached not as sources of authority, but rather as opportunities to connect and align.

Your Checklist:

• Give up on being the person who “owns” the roadmap. Instead, look to facilitate the way that your entire organization uses roadmaps.

• Don’t make assumptions about how your organization uses roadmaps. Ask lots of questions, and create a clear and well-documented understanding of how roadmaps are to be used within your organization.

• Open up the roadmap. It should be a conversation starter and a tool for alignment, not something to be closely guarded and manipulated under cover of darkness.

• Give your colleagues the opportunity to suggest ideas for the product roadmap, but don’t let it turn into a free-for-all. Use simple templates to structure your colleagues’ thinking around the goals of their ideas, not (just) the ideas themselves.

• Advocate just as fiercely for ideas that are not your own, if not more so. Don’t get hung up on wanting to be the “idea person.”

• Don’t spend so long on product specifications that you close off avenues for true collaboration.

• If you are using a formal practice for writing product and feature specifications such as “user stories,” remember that a formally correct spec is not necessarily a good spec.

• Make sure that everything on your roadmap is tied back to a “why” so that if that “why” changes, you can adjust the roadmap accordingly.

• Be prepared for short-term prioritization to be much more challenging than creating a long-term roadmap.

• Do everything in your power to make sure that the goals against which you are prioritizing are clear, well understood and actionable.

• If you can, take your goals for a “test drive” with the senior leaders who are setting the company vision and strategy. See if the goals can serve as a stand-in for their vision, and change your goals if they aren’t giving you the guidance you need.

• If your team is excited to build something new and shiny, don’t reflexively shoot it down for “not meeting our goals.” Find out why your team is so excited, and see what you can do to direct that excitement toward whatever solution will deliver the most value to your users and your business.

• Remember that learning, testing, and experimenting is still valuable work, and should be treated as such. Prioritize tasks like creating prototypes and researching implementation approaches alongside the work of actually building your product.