As the Head of Product at LIKE.TG, I spend a lot of time talking to product teams and learning about their experiences throughout the product development process. I am deeply familiar with their common refrains of endless roadmap review meetings, repetitive PowerPoint presentations, and the strain of constant context shifting. Sometimes, it’s helpful to get out of the day-to-day and see things from a different lens. I loved that stepping into ProductWorld’s Developer Week 2024 in San Francisco a few weeks ago reminded me of the other side of the product development experience. Engineers and development teams surrounded us—the people who collaborate with product teams daily—the often unsung heroes of building truly impactful products that solve real problems for real people. It was a terrific experience hearing from my peers, mingling with fresh faces, and participating in great conversations about nurturing the coexistence of product and engineering with empathy, respect, and mutual accountability. I came out of Developer Week with three key takeaways about how we can work together in their quests to design, build, test, and ultimately ship great products. Keep reading to learn more about my experience at the event! #1 – The best product and engineering teams create shared accountability Collaboration is the cornerstone of successful product and engineering teams, starting with effective communication. By working together and being transparent, product and engineering will see each other as partners seeking to achieve the same goals. Product teams are responsible for creating a strategy and explaining the “why” behind the product. Their importance shouldn’t be overlooked or dismissed as not technical enough. Product’s role is crucial to the development of effective product strategy and stakeholder buy-in. On the other hand, engineering must stay informed throughout the product development lifecycle and closely involved in problem-solving processes. They should not be dismissed as “ticket-takers” and can provide insightful guidance to the product. Speakers and attendees alike emphasized the importance of utilizing robust communication tools, like our product management platform, to facilitate seamless collaboration and encourage shared accountability. A collaborative mindset enhances teamwork and amplifies the overall impact of the product organization. In short, product teams should own outcomes while developers own the outputs. Together, they own the impact. #2 – Successful execution requires a thoughtful strategy Product management and project management are often confused with one another, but they are two distinct roles that serve different purposes. Project managers should work closely with product teams to create thoughtful and realistic plans, similar to how engineering teams rely on product expertise for strategy. Successful product execution requires a thoughtful balance between ambition and probabilistic planning from product and project managers. Justin Meyer, CEO of Bitovi, shared valuable insights and practical strategies during his presentation “Building and Maintaining Actionable Multi-team Plans.” At Bitovi, they help product teams strengthen confidence in their estimates by taking a data-driven approach to planning. They build formulas with standard deviations around confidence in effort estimates to ensure realistic forecasts. This approach helps stakeholders identify critical paths and dependencies and promotes communication and shared accountability for the teams that are working together. Product should also be prepared with thoughtful problem statements and have clear recommendations for an effective sequence of tasks. Each step is interdependent, underscoring the importance of creating mutual buy-in early in the product development lifecycle. To manage effective sequencing, Meyer suggested reducing scope, adjusting resources, and addressing confidence issues promptly. The overarching goal of probabilistic planning is to expedite tasks with heightened confidence. All things considered, Product has a crucial role in the planning process. When alignment on the “what” and “why” is established, uncertainty about the “how” becomes secondary, fostering a conducive environment for successful execution. #3 – Expect the unexpected and learn to adapt In an era of rapid technological advancements, it’s not just about having great ideas but mastering the art of embracing change and adapting swiftly to unforeseen challenges. Learning to pivot is not just a skill but a survival necessity. The conference drove home the importance of acknowledging this reality early on, urging product leaders to embrace agility to succeed. Although some things are out of your control, even the most minor expected setbacks can become opportunities for success. Lindsay Harman, Senior Product Manager at Sirius XM, elaborated on ways to pivot and innovate in her presentation “Making the Most of Failed Products: Pivoting Your Roadmap and Goals When Things Don’t Go as Planned.” In one exercise, she had the audience imagine that they worked at a medical device company that recently released a wearable product to improve memory. But after going to market and finding early success, the FDA shuts them down for a side effect that increases the length of customers’ limbs… how should they pivot when confronted with this unforeseen obstacle? This creative thinking exercise encouraged everyone to consider a new market. Is the “limb-lengthening” side effect desirable for some people? Is there an opportunity to sell to them and consider a new market? Although it was just an example, it was a fun and playful way to show the importance of adopting a mindset that welcomes unexpected change and adapts to survive. How I’m bringing these insights into my work as a product leader After attending the conference, I felt inspired by the valuable insights I could bring back to ProductPlan. The most important takeaway was that shared accountability is essential for collaborative success. Firstly, shared accountability emerges as the foundation for collective success, reminding us that effective communication is the bridge that connects teams. The importance of a thoughtful strategy resonates clearly, urging leaders to find the right balance between ambition and probabilistic planning. And, of course, embracing change ensures survival and becomes the catalyst for innovation, setting our product teams up to be resilient. Together, these key learnings form a compass guiding us toward sustained success and excellence in the ever-evolving world of product leadership. Where is LIKE.TG heading next? LIKE.TG will also attend the Product-Led Summit hosted by the Product-Led Alliance in New York on March 20-21. Our team is looking forward to continuing our development as product leaders and would love the opportunity to connect while we’re in town. Contact our team at [email protected] to connect with us.

I’ve been talking with product managers lately about how the concepts of “essentialism” can help them focus their efforts on what matters. I distilled the advice a few months ago in my book The Essentialist Product Manager and have recently been giving talks and workshops on the topic. This article tackles one of the areas that gets the most interest from product managers: how can they use an essentialist approach to create and communicate better product roadmaps? First, let’s recap what essentialism means. The concepts were popularized in the book Essentialism: The Disciplined Pursuit of Less by Greg McKeown. According to his book, an “essentialist” lives by design, not by default. An essentialist isn’t reactive but rather makes choices deliberately by separating the few most important things from the hundreds of other less-important things. To achieve this, an essentialist must say “No” a lot. As a product professional for over 20 years, this philosophy resonates with me. And it’s resonated with other product managers too. We already know that it’s not about getting more things done; it’s about getting the right things done. To ensure you’re adding the right features and initiatives to your product roadmap, I’ve outlined several suggestions here.

Have your big-picture roadmap discussions in the roadmap itself Users of LIKE.TG’s roadmap app can always add comments to any bar or container in a roadmap. Users can click on an item in the roadmap and type a note or question into the comments field. The app even lets users add @mentions to their comments, to make sure the right stakeholders see them. But what if you want to add comments or questions about the roadmap? How can you start those higher-level conversations about product strategy or other roadmap-level issues? What if your comment or concern doesn’t fit neatly into any of the roadmap’s bars or containers? We discovered that many LIKE.TG users were creating these comment threads outside of our app—often in email and Slack channels. Feature: Roadmap-Level Conversations LIKE.TG has a feature that allows your team to have roadmap-level discussions within your roadmap itself. hbspt.cta.load(3434168, '527dc6af-8860-436f-9ca6-ae2b71b0cc99', {"useNewLoader":"true","region":"na1"}); How does the new feature work Look for the bell icon in the upper-right corner of the LIKE.TG app? Clicking on it brings up our roadmap-level Comments menu. It lets you filter between Open Comments and Resolved Comments to view All Comments for the roadmap. Now, when someone on your team wants to ask about timelines or budgets or competitive info—not for a particular theme or epic, but for the roadmap itself—they can start that conversation right here. Note: You can even have these high-level conversations for an entire portfolio of products if you’re using LIKE.TG’s Portfolio View to consolidate multiple roadmaps. With our Roadmap-Level Conversation feature, your team can now: Hold and document strategic discussions at the roadmap level (rather than the bar or container level). Review roadmaps asynchronously with your stakeholders. Discuss and resolve issues between individual roadmap bars and containers. Update your team on the status of roadmap initiatives, identify blockers, request additions, and document changes—all within your roadmap interface. You can also resolve comments at the roadmap level. This way, all stakeholders quickly ensure they’re participating in the latest conversation about the current roadmap. Make it easy for stakeholders to see what’s changed since they last viewed the roadmap Our app does a great job of tracking all changes to your roadmaps. But your stakeholders have limited time. They want to see those changes quickly without reading through a long list of details. Here’s how we took that customer feedback to make our app even better. What our customers wanted Sonia works for a multibillion-dollar tech solution company, and her team uses LIKE.TG for their product roadmaps. We’ve heard variations on her request from many customers. Here’s how she summarized the issue: “I want to see a view of what was planned and what actually happened. It’s not a question of what was completed or not, it’s a matter of understanding how our plans changed.” We knew we could do better. So, we created the Visualize Roadmap Changes option.” Feature: Visualize Roadmap Changes How it works With this feature, you can simply click a button and visually display the differences between roadmap versions or the differences between the roadmap at any two points in time. As you can see from the screen above, clicking into the History section still allows you to display roadmap changes as a list. Those updates display on the right-hand side. But now you can also toggle to a visual depiction of this information. As you can see in the main panel above, the app can now also display the changes to the bars and containers. For example: Items moved show both original and new placement, connected with lines and arrows, and are color-coded with red borders. Green borders depict items added to the roadmap. Strikethroughs show items removed after the previous version. With the app’s Visualize Changes feature, your team can: Make roadmap changes easy to grasp for stakeholders. Quickly and easily compare a roadmap between any two points in time. Eliminate the need to manually recreate visual changes for executive and other stakeholder roadmap updates. Visually monitor your performance and progress over time. (For example, to determine if your team is moving an items’ deadline more often than you’d like.) Takeaway These new features address two very different use cases in our app, but they have a common theme: improved roadmap collaboration. At LIKE.TG, we are always looking for ways that our roadmap app can help your team communicate and collaborate more efficiently—so you can build great products. Try our Visualize Roadmap Changes and Roadmap-Level Conversations features, and let us know if they hit the mark with your team. Get Your Free Roadmap Template Guide ➜ hbspt.cta.load(3434168, 'aade5d3d-4c0b-4409-b1c0-31d727a356aa', {"useNewLoader":"true","region":"na1"});

Have your big-picture roadmap discussions in the roadmap itself Users of LIKE.TG’s roadmap app can always add comments to any bar or container in a roadmap. Users can click on an item in the roadmap and type a note or question into the comments field. The app even lets users add @mentions to their comments, to make sure the right stakeholders see them. But what if you want to add comments or questions about the roadmap? How can you start those higher-level conversations about product strategy or other roadmap-level issues? What if your comment or concern doesn’t fit neatly into any of the roadmap’s bars or containers? We discovered that many LIKE.TG users were creating these comment threads outside of our app—often in email and Slack channels. Feature: Roadmap-Level Conversations LIKE.TG has a feature that allows your team to have roadmap-level discussions within your roadmap itself. hbspt.cta.load(3434168, '527dc6af-8860-436f-9ca6-ae2b71b0cc99', {"useNewLoader":"true","region":"na1"}); How does the new feature work Look for the bell icon in the upper-right corner of the LIKE.TG app? Clicking on it brings up our roadmap-level Comments menu. It lets you filter between Open Comments and Resolved Comments to view All Comments for the roadmap. Now, when someone on your team wants to ask about timelines or budgets or competitive info—not for a particular theme or epic, but for the roadmap itself—they can start that conversation right here. Note: You can even have these high-level conversations for an entire portfolio of products if you’re using LIKE.TG’s Portfolio View to consolidate multiple roadmaps. With our Roadmap-Level Conversation feature, your team can now: Hold and document strategic discussions at the roadmap level (rather than the bar or container level). Review roadmaps asynchronously with your stakeholders. Discuss and resolve issues between individual roadmap bars and containers. Update your team on the status of roadmap initiatives, identify blockers, request additions, and document changes—all within your roadmap interface. You can also resolve comments at the roadmap level. This way, all stakeholders quickly ensure they’re participating in the latest conversation about the current roadmap. Make it easy for stakeholders to see what’s changed since they last viewed the roadmap Our app does a great job of tracking all changes to your roadmaps. But your stakeholders have limited time. They want to see those changes quickly without reading through a long list of details. Here’s how we took that customer feedback to make our app even better. What our customers wanted Sonia works for a multibillion-dollar tech solution company, and her team uses LIKE.TG for their product roadmaps. We’ve heard variations on her request from many customers. Here’s how she summarized the issue: “I want to see a view of what was planned and what actually happened. It’s not a question of what was completed or not, it’s a matter of understanding how our plans changed.” We knew we could do better. So, we created the Visualize Roadmap Changes option.” Feature: Visualize Roadmap Changes How it works With this feature, you can simply click a button and visually display the differences between roadmap versions or the differences between the roadmap at any two points in time. As you can see from the screen above, clicking into the History section still allows you to display roadmap changes as a list. Those updates display on the right-hand side. But now you can also toggle to a visual depiction of this information. As you can see in the main panel above, the app can now also display the changes to the bars and containers. For example: Items moved show both original and new placement, connected with lines and arrows, and are color-coded with red borders. Green borders depict items added to the roadmap. Strikethroughs show items removed after the previous version. With the app’s Visualize Changes feature, your team can: Make roadmap changes easy to grasp for stakeholders. Quickly and easily compare a roadmap between any two points in time. Eliminate the need to manually recreate visual changes for executive and other stakeholder roadmap updates. Visually monitor your performance and progress over time. (For example, to determine if your team is moving an items’ deadline more often than you’d like.) Takeaway These new features address two very different use cases in our app, but they have a common theme: improved roadmap collaboration. At LIKE.TG, we are always looking for ways that our roadmap app can help your team communicate and collaborate more efficiently—so you can build great products. Try our Visualize Roadmap Changes and Roadmap-Level Conversations features, and let us know if they hit the mark with your team. Get Your Free Roadmap Template Guide ➜ hbspt.cta.load(3434168, 'aade5d3d-4c0b-4409-b1c0-31d727a356aa', {"useNewLoader":"true","region":"na1"});

At LIKE.TG, I frequently get questions about agile roadmap planning. How should you balance long-term strategic planning with short-term agility? This was an especially hot topic on a recent webinar we hosted. I thought I’d elaborate on some of my answers in this post. Here are 3 questions on that topic I’d like to highlight. 1. How do you balance agile uncertainty with roadmap planning at a growing small or medium-sized company? It’s important for product managers to not make the mistake of thinking that because they have a roadmap, they’re not agile. Those two concepts actually work in tandem. You need an agile roadmap to set the strategic goals for your company, but you still have a lot of freedom to move things around within those goals. Download How Agile Product Managers Can Build Better Products ➜ hbspt.cta.load(3434168, 'b4eb5c0b-bf4b-4a7e-9b0a-75f92005c127', {}); There are a couple of points that I’ll make around this: The first is that you should be doing continuous customer discovery and customer interviews. You should always be engaging with customers in order to find the big problems worth solving. And when you match customer problems up with the strategic goals that you’ve set for your organization, it will point you in the right direction in terms of which features to build. It’s important to remember that you’re not necessarily putting narrow features and tasks on the roadmap. Instead, you’re bubbling those up to make the roadmap very high-level. You need to be looking at big themes that will help you move the needle in problem areas that your customers have. Think about the jobs your customers need to get done. Remember, your agile roadmap helps you communicate the strategy. When you keep your roadmap high-level, you maintain a lot of flexibility as a product manager to move features in and out of the backlog in order to accomplish your goals. The second point I want to make is that you should be reprioritizing all the time. Reprioritize your backlog and your roadmap, especially in the long-term, because things change and different competitive pressures come up. Don’t lock in timelines that are too long, or your stakeholders will feel like you’re making commitments and they’ll expect you to deliver. [Free book] Backlog Refinement: How to Prioritize What Matters ➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {}); I think those two points are really important — doing continuous customer discovery and constantly reprioritizing features. That way you can ensure your agile process is really working for you. You don’t want to find yourself in a position where you’re throwing features into the development queue that was decided on twelve months ago. Those features may or may not be the right things to do today. And there’s one more thing I want to touch on — this idea of using a Kanban-style roadmap. The Kanban methodology has become pretty popular because it lets you organize the roadmap into different buckets — planned, doing, done, etc. — without committing to specific deadlines. With a Kanban roadmap, you can designate things that you might want to be doing in the future, but you’re not quite sure about yet. You can distinguish the things that are a little bit fuzzy from the things that you’ve already committed to for the short term. I think that in a small or mid-size organization, Kanban is a great way to avoid making the mistake of locking in an inflexible,12-month roadmap that may or may not end up being the right course of action. And, of course, it should also be mixed in with continuous customer discovery and reprioritization. 2. How far out should you plan your roadmap? How do you properly set expectations with stakeholders that plans will change? I think it depends. The appropriate timeframe for your roadmap depends on the kind of organization you have, the type of product you have, and where your product is in its lifecycle. If it’s an early-stage product, your roadmap needs to be very short-term. You simply don’t have enough insight into what the right things to build are, so your roadmap needs to be very flexible. On the other hand, if you have a product that is five or six years into its lifecycle, your planning horizon needs to be much longer. So, again, it really depends on product and company maturity, but at LIKE.TG, the most common roadmap time horizon our customers use is about a year. Many organizations are moving to an agile planning approach, and that makes it less likely that the things you’re putting on your roadmap for six or nine months from now are solid — and that presents challenges for product managers. We hear from a lot of product managers who feel that creating a one-year roadmap means setting unreasonable expectations among their stakeholders. And that’s really a caveat here — you have to communicate to your stakeholders that the roadmap will change. One of the ways that you can do that is by bringing your roadmap up a level. Again, the roadmap should not be simply a list of features or a backlog. The roadmap should be tied to strategic themes. So rather than listing out specific features or tasks that need to be accomplished, roll those up into larger themes and communicate the roadmap at the theme level. A theme ties back to strategy. For example, if your product is an e-commerce product and you want to reduce the rate of shopping cart abandonment — i.e. you want to improve the number of customers who are actually making purchases — that could become a theme. Now, the exact features that you create in order to accomplish that goal, or that theme, may change. You also may not really know the effort level behind the features you’re considering. As you get closer to building them and you estimate the stories, it will become more clear what that effort level is. Then you can make trade-off decisions about which items will best accomplish your goals. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); So those are my recommendations — that you manage stakeholder expectations that the plan will change and that you bring the roadmap up a level. As a product manager, you have a lot of flexibility in what you can accomplish as long as you don’t get locked into building a specific feature set. 3. How do you adjust when you have roadmaps for a racehorse but realize you’re actually riding a mule? I love that question! I think a lot of us have been there, and I think it’s just the nature of things. As product managers, we know what the path is — we have the vision for the product. But sometimes things don’t move as quickly as we want them to. I think setting up those longer-term strategic goals is the right way to safeguard against unexpected bumps in the road. And there’s no quick fix here other than to just stay on the path. As long as the path fits in with those strategic goals, you’ll eventually get there. Having that long-term strategic perspective will make it easier to say, “Yes, we are going to do that, just not yet.” I also think that this is where the concept of an MVP comes into play. Not every feature is important, and a lot of the things that you have on your roadmap, especially if you thought them up in the conference room, may not be the right things to build in the first place. I’ve found that I can often satisfy customers and give them a lot of value by building only 50% of what I thought they needed to have — and I’m constantly surprised by that. If you’re solving one key problem for them, they’ll buy and they’ll be happy, even though you may not have given them everything that was on the initial roadmap.

One of the biggest challenges product managers face is working with diverse stakeholders and managing their conflicting priorities. You’re pulled in a hundred different directions, and often it’s the sales team applying pressure on your roadmap priorities. At times it’s tempting to build what the latest big sales prospect asked for. And sometimes, to close the deal, it’s tempting to make promises on release dates or to mention features that are still a few months out on the roadmap. I’ll elaborate on some of the points I made during our recent webinar, and explain how product managers can better work with sales teams to ensure they don’t over-promise and under-deliver. What successful methods have you found to manage the sales team selling roadmap features before readiness? The sales team understandably is looking for ways to close the deal. That’s how they’re compensated, and I think it’s important for product managers to recognize that. You can set expectations with the sales department that plans will change and you can talk all you want about being agile. You can tell them that you’re not sure when the exact delivery dates for certain features will be. But the reality is that when you send the sales team a roadmap, many will consider it to be a commitment. The last thing you want is for sales to be attaching a copy of that roadmap to a customer contract. One option to consider: creating a separate sales-oriented roadmap — one that doesn’t have dates and that is less granular. A sales-oriented roadmap could also limit the timeframe, showing just what you’ll be delivering in the short term — maybe three months out. It’s important to involve sales leadership in the roadmap planning process. Not only does it get their important input, but it helps establish buy-in. You also have the opportunity to guide them on why certain features are important from a strategic perspective. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); How do you keep sales and product teams on the same page? It’s important for product managers to make sure that the sales team is targeting the same market that the product team has identified for the product. Product managers usually work with personas, and I think that’s a really important concept, but sales teams may not necessarily have a similar sales persona. For example, let’s say you’re a B2B company and you’re targeting companies with 1,000 to 2,000 employees. Well, your sales team better be doing the same. You’re building a product that solves a problem for that market, but if your sales team is then approaching startups, there’s going to be a problem. A product/market mismatch. The sales team will inevitably be disappointed, and of course, the customer will inevitably be disappointed. You need to make sure that there’s alignment between your target market and the market that your sales department is actually selling to. Everybody should be pulling for the same team. Tweet This: “Make sure your target market matches the market your sales team is actually selling to.” Also, I think it’s important to nicely remind your stakeholders that sales and revenue aren’t the only success metrics. The success of a product is based on a whole lot of other things. For example, customer satisfaction after a sale is critical. If your sales team is selling actively but you have a lot of customers churning, that’s not good. So it’s important to recognize that there are other metrics out there besides sales that are worth paying attention to. Get Buy-In and Budget Approval on Your Product Stack➜ hbspt.cta.load(3434168, 'c4f7dcc8-378e-4b20-9c16-637fcb9589a5', {"region":"na1"}); How do you avoid getting distracted by high-paying clients? When a high-profile client comes in and asks for a feature, it means something else is not going to get built. If everything is equal, if one feature is added to the roadmap, another one moves out. And it’s easy to get distracted from your core roadmap when a large prospect says, “If you build this feature, we’ll buy.” Check them against your strategic objectives — this is where having those clear objectives and goals mapped out with your team becomes really critical. You need to make sure your team is aligned on strategic goals because if you’re making these decisions by yourself, you’re going to have an even harder time weighing the risks and benefits. Whatever this big deal is that’s being dangled in front of you, the feature they’re requesting needs to be tied back to your product vision. If you’re doing a good job of that, then it should be fairly clear what the right answer is. Sometimes it’s tough but you just have to say no or not yet. Have other suggestions on how to better align sales and product teams? Share them in the comments below.

Much has been written over the last few years on the idea of the featureless roadmap, which challenges product teams to present their plans grounded more in strategic vision – or by themes – rather than a laundry list of specific features. LIKE.TG alone has several articles on the subject that demonstrate the many virtues of this outcome-focused approach. It’s becoming more and more widely adopted by Product Management organizations across the globe. One of the critical considerations in developing your theme framework is to ask what drives the need for this theme? There is a genuine risk that a well-meaning product manager might simply group and categorize the existing feature list as a means for determining the theme. However, the real goal of the themed roadmap is to let the desired outcomes define the features. So how do you zero in on the most meaningful outcomes from which to center your roadmap themes around? How to Decide on Roadmap Themes that Produce Meaningful Outcomes I’ve seen several different approaches, including themes that align with high-level business goals (acquisition, growth, customer satisfaction, etc.) or more granular focus areas like the example in Jim Semick’s article of increasing satisfaction within a user persona group. There are pros and cons to each of these approaches. For example, the business goals approach is static over time, so the themes themselves stay consistent and maintain a pulse on the longer view. But the themes in and of themselves are a bit uninspiring and don’t do much to communicate customer value. In the more granular approach, the focus is more laser-sharp and centered on a specific customer outcome. However, this approach runs the risk of myopia and losing sight of new emergent opportunities that might outweigh the theme’s value. A compelling theme should be centered on the exchange of value between the business and the customer, and the above examples are hyper-focused on one or the other. hbspt.cta.load(3434168, '5894a003-79ce-4ea3-9804-dae280a96106', {}); One way to achieve this balance is to organize your roadmap themes by each phase of the customer journey. This customer journey approach provides a widely universal framework for both business and customer outcomes and promotes a constant, bird-eye perspective on the end-to-end customer experience. The Customer Journey Framework The customer journey chronicles every customer interaction and touchpoint with your business—from becoming aware that you exist to making a purchase decision, using, and then eventually renewing with your product or service. The journey is depicted in different phases, which are relatively universal (but might be customized by a business that has done the work to map their customers’ journey). Those phases include Become Aware, Evaluate and Buy, Set Up, Happily Use, Get Support, Add Services, and Renew. The Benefits of Defining Product Themes by Customer Journey Phases Breaking down the customer’s end-to-end journey is a highly effective framework that enables an outside-in perspective and customer empathy as a means to drive value that is reciprocal to both customer and the business: Journey maps, then, are highly applicable to the goal of defining product roadmap themes since successful customer outcomes are at the heart of each phase. Besides the apparent value exchange, the customer journey is a universal perspective that transcends organizational silos. Each phase of the journey has pretty clear stakeholders, for example, generating awareness is usually assigned to the marketing team, and the customer success department usually owns the support experience. Focusing your themes on phases of the customer journey enables stronger partnerships between the product team and other functional groups because their goals become less disparate from the product strategy. It changes the conversation from other departments vying for a slot on the product roadmap to one that is much more strategic. Both groups can become collaboratively responsible for goal setting within the shared theme. Another benefit of the journey-based roadmap themes is that it inherently promotes customer empathy. Everyone in the company who looks at your product roadmap can evaluate it, not from just a customer perspective, but a timeline-based customer perspective. The customer journey enables individuals and teams to consider the context of their work within the customer’s end-to-end experience. Leading with this genuine care, curiosity, and perspective of the customer can have profound cultural effects on a business. Customer-centered cultures foster a bottom-up drive for innovation based on the desire to solve customer problems creatively. Problems are fluid, and markets are changing rapidly, so the work of a product manager to effectively prioritize work is a constant challenge effectively. Choosing the right theme altitude is critical to keeping eyes and ears open for emerging opportunities outside of the current focus areas. I like using customer journey phases as themes because, while customer needs may fluctuate, their journey stages are static. Maintaining consistency and continuity in themes provides a clearly defined lens from which to scan the customers, trends, and competition. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); Customer Journey Roadmap Themes in Practice Let’s look at some tangible examples of how each theme may be planned and presented from the perspective of a fictitious e-commerce platform company. Phase 1: Become aware Prospects know our product exists, and it has a positive reputation. Generating awareness includes all of the things your marketing department is doing to reach new prospective customers. In this example, the product and marketing teams establish a mission to grow the reputation of the business by addressing issues raised by contributors to software review sites and focusing on a specific feature and usability gaps common among the less-favorable reviews. CUSTOMER KPI: Reach BUSINESS KPI: Reach as a % of Total Addressable Market (TAM) STAKEHOLDER PARTNER: Marketing Phase 2: Evaluate & buy Make it easy for prospects to choose and purchase our product. Reducing friction between a prospect and their willingness to buy is a key concern for sales and product management teams. Having a theme dedicated to this experience drives constant focus in this crucial area, like in this example, where the goal is to reduce sales objections by adding the top payment options prospects are demanding. CUSTOMER KPI: Time to deal close BUSINESS KPI: Maps to sales booking goals STAKEHOLDER PARTNER: Sales Phase 3: Set-up New customers can take immediate advantage of our product. Product onboarding encompasses all the activities a customer or user engages in to configure, learn, and start using a product. In this example, the teams at our e-commerce platform are working on ways to do just that by introducing two new, self-guided onboarding flows within the product. CUSTOMER KPI: Time to the first use of the critical feature BUSINESS KPI: Time to goal monthly recurring revenue (MRR) STAKEHOLDER PARTNER: Customer Success and/or Onboarding Teams Phase 4: Happily use Customers get so much value from using the product, and they love it! Naturally, the phase focused on product use is how much of mainstream product management is currently categorizing their work. Given the above examples, one can begin to ascertain the benefits of instead capturing work in terms of the different outcomes defined by the customer journey. Keeping the outcome of this theme narrowly focused on adding value makes it an excellent space for prioritizing feature requests of current customers, usability improvements, addressing technical debt, and, as in this example, improving product engagement of a specific feature set. CUSTOMER KPI: Transactional Net Promoter Score (tNPS), System Usability Score (SUS) BUSINESS KPI: Critical engagement metrics STAKEHOLDER PARTNER: Product Development (Product, UX, & Engineering) Phase 5: Get support Customers rarely need help, but when problems arise, they are quickly solved. The support phase is focused on making support resources easily accessible, improving resolution speed, building out various support channels, and reducing the need for support in the first place. The product team can have a significant impact on this outcome by doing this, like implementing an in-product support experience or, as in the example below, dedicating focus to address the top product case drivers. CUSTOMER KPI: Transactional Net Promoter Score (tNPS), Time to case resolution BUSINESS KPI: Tracking against operational cost efficiencies STAKEHOLDER PARTNER: Customer Support Phase 6: Add services Customers are compelled to upgrade and subscribe to value-add services. The heart of the add services phase is in upgrades, upselling, and the purchase of additional products and services, all tied to a business’s growth initiatives. This theme can capture things like improving the discoverability of value-add services, adding features to be repackaged as a new subscription tier, or, as in this example, building out new features or services that customers would be willing to pay extra for. CUSTOMER KPI: Reach/Conversion BUSINESS KPI: Average Revenue per Unit (ARPU) STAKEHOLDER PARTNER: Customer Success and/or Sales Phase 7: Renew Customers remain loyal advocates of our product and business. The renew phase looks at every opportunity to keep customers happy coming back to your product or service. Almost all SaaS businesses are looking at churn, and addressing those reasons is perhaps the most apparent epic under this theme. But, similar to some of the other themes, there may be opportunities to reduce effort by integrating account management experiences within the product, such as this example that would introduce a renewal flow and add the ability for SaaS customers to pay their invoice online (instead of sending a check). CUSTOMER KPI: Net Promoter Score, Customer Satisfaction (CSAT) scores BUSINESS KPI: Churn STAKEHOLDER PARTNER: Customer Success Considerations for Journey-Focused Roadmap Themes A highlighted benefit of having high-level themes that align with phases of the customer journey is that the themes are universally applicable across every department of the business. Sharing goals across business functions create a substantial competitive advantage for consistently delivering high-value, end-to-end experiences. There are, however, some aspects of this approach to be mindful of, which include: Avoid creating silos by phase. People and tactics may be focused on a specific phase. However, Product and Design need to maintain their awareness of their work’s context within the end-to-end journey. Phases require prioritization. While I advocate for having the same consistent themes, I don’t believe that work needs always to be happening equally within each. Certain phases will have a greater need than others. It’s up to the product team to appropriately allocate focus where the greatest needs are. Phases often have embedded journeys of their own. This is especially true for the Add Services phase, where there is a complete cycle of awareness to renew to consider. Keeping customer outcomes at the heart of your roadmap, effectively mapping them to business outcomes, and sharing those outcomes across your organization is an excellent recipe for driving innovation and building reciprocal value between your customers and your business. The phases of the customer journey already have this value exchange baked-in. They can be a highly effective lens through which to view and prioritize the opportunities on your product roadmap. Read the Strategic Roadmap Planning Guide hbspt.cta.load(3434168, 'e23dbd3d-c389-4aba-b537-43c357b5672a', {});

Much has been written over the last few years on the idea of the featureless roadmap, which challenges product teams to present their plans grounded more in strategic vision – or by themes – rather than a laundry list of specific features. LIKE.TG alone has several articles on the subject that demonstrate the many virtues of this outcome-focused approach. It’s becoming more and more widely adopted by Product Management organizations across the globe. One of the critical considerations in developing your theme framework is to ask what drives the need for this theme? There is a genuine risk that a well-meaning product manager might simply group and categorize the existing feature list as a means for determining the theme. However, the real goal of the themed roadmap is to let the desired outcomes define the features. So how do you zero in on the most meaningful outcomes from which to center your roadmap themes around? How to Decide on Roadmap Themes that Produce Meaningful Outcomes I’ve seen several different approaches, including themes that align with high-level business goals (acquisition, growth, customer satisfaction, etc.) or more granular focus areas like the example in Jim Semick’s article of increasing satisfaction within a user persona group. There are pros and cons to each of these approaches. For example, the business goals approach is static over time, so the themes themselves stay consistent and maintain a pulse on the longer view. But the themes in and of themselves are a bit uninspiring and don’t do much to communicate customer value. In the more granular approach, the focus is more laser-sharp and centered on a specific customer outcome. However, this approach runs the risk of myopia and losing sight of new emergent opportunities that might outweigh the theme’s value. A compelling theme should be centered on the exchange of value between the business and the customer, and the above examples are hyper-focused on one or the other. hbspt.cta.load(3434168, '5894a003-79ce-4ea3-9804-dae280a96106', {}); One way to achieve this balance is to organize your roadmap themes by each phase of the customer journey. This customer journey approach provides a widely universal framework for both business and customer outcomes and promotes a constant, bird-eye perspective on the end-to-end customer experience. The Customer Journey Framework The customer journey chronicles every customer interaction and touchpoint with your business—from becoming aware that you exist to making a purchase decision, using, and then eventually renewing with your product or service. The journey is depicted in different phases, which are relatively universal (but might be customized by a business that has done the work to map their customers’ journey). Those phases include Become Aware, Evaluate and Buy, Set Up, Happily Use, Get Support, Add Services, and Renew. The Benefits of Defining Product Themes by Customer Journey Phases Breaking down the customer’s end-to-end journey is a highly effective framework that enables an outside-in perspective and customer empathy as a means to drive value that is reciprocal to both customer and the business: Journey maps, then, are highly applicable to the goal of defining product roadmap themes since successful customer outcomes are at the heart of each phase. Besides the apparent value exchange, the customer journey is a universal perspective that transcends organizational silos. Each phase of the journey has pretty clear stakeholders, for example, generating awareness is usually assigned to the marketing team, and the customer success department usually owns the support experience. Focusing your themes on phases of the customer journey enables stronger partnerships between the product team and other functional groups because their goals become less disparate from the product strategy. It changes the conversation from other departments vying for a slot on the product roadmap to one that is much more strategic. Both groups can become collaboratively responsible for goal setting within the shared theme. Another benefit of the journey-based roadmap themes is that it inherently promotes customer empathy. Everyone in the company who looks at your product roadmap can evaluate it, not from just a customer perspective, but a timeline-based customer perspective. The customer journey enables individuals and teams to consider the context of their work within the customer’s end-to-end experience. Leading with this genuine care, curiosity, and perspective of the customer can have profound cultural effects on a business. Customer-centered cultures foster a bottom-up drive for innovation based on the desire to solve customer problems creatively. Problems are fluid, and markets are changing rapidly, so the work of a product manager to effectively prioritize work is a constant challenge effectively. Choosing the right theme altitude is critical to keeping eyes and ears open for emerging opportunities outside of the current focus areas. I like using customer journey phases as themes because, while customer needs may fluctuate, their journey stages are static. Maintaining consistency and continuity in themes provides a clearly defined lens from which to scan the customers, trends, and competition. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); Customer Journey Roadmap Themes in Practice Let’s look at some tangible examples of how each theme may be planned and presented from the perspective of a fictitious e-commerce platform company. Phase 1: Become aware Prospects know our product exists, and it has a positive reputation. Generating awareness includes all of the things your marketing department is doing to reach new prospective customers. In this example, the product and marketing teams establish a mission to grow the reputation of the business by addressing issues raised by contributors to software review sites and focusing on a specific feature and usability gaps common among the less-favorable reviews. CUSTOMER KPI: Reach BUSINESS KPI: Reach as a % of Total Addressable Market (TAM) STAKEHOLDER PARTNER: Marketing Phase 2: Evaluate & buy Make it easy for prospects to choose and purchase our product. Reducing friction between a prospect and their willingness to buy is a key concern for sales and product management teams. Having a theme dedicated to this experience drives constant focus in this crucial area, like in this example, where the goal is to reduce sales objections by adding the top payment options prospects are demanding. CUSTOMER KPI: Time to deal close BUSINESS KPI: Maps to sales booking goals STAKEHOLDER PARTNER: Sales Phase 3: Set-up New customers can take immediate advantage of our product. Product onboarding encompasses all the activities a customer or user engages in to configure, learn, and start using a product. In this example, the teams at our e-commerce platform are working on ways to do just that by introducing two new, self-guided onboarding flows within the product. CUSTOMER KPI: Time to the first use of the critical feature BUSINESS KPI: Time to goal monthly recurring revenue (MRR) STAKEHOLDER PARTNER: Customer Success and/or Onboarding Teams Phase 4: Happily use Customers get so much value from using the product, and they love it! Naturally, the phase focused on product use is how much of mainstream product management is currently categorizing their work. Given the above examples, one can begin to ascertain the benefits of instead capturing work in terms of the different outcomes defined by the customer journey. Keeping the outcome of this theme narrowly focused on adding value makes it an excellent space for prioritizing feature requests of current customers, usability improvements, addressing technical debt, and, as in this example, improving product engagement of a specific feature set. CUSTOMER KPI: Transactional Net Promoter Score (tNPS), System Usability Score (SUS) BUSINESS KPI: Critical engagement metrics STAKEHOLDER PARTNER: Product Development (Product, UX, & Engineering) Phase 5: Get support Customers rarely need help, but when problems arise, they are quickly solved. The support phase is focused on making support resources easily accessible, improving resolution speed, building out various support channels, and reducing the need for support in the first place. The product team can have a significant impact on this outcome by doing this, like implementing an in-product support experience or, as in the example below, dedicating focus to address the top product case drivers. CUSTOMER KPI: Transactional Net Promoter Score (tNPS), Time to case resolution BUSINESS KPI: Tracking against operational cost efficiencies STAKEHOLDER PARTNER: Customer Support Phase 6: Add services Customers are compelled to upgrade and subscribe to value-add services. The heart of the add services phase is in upgrades, upselling, and the purchase of additional products and services, all tied to a business’s growth initiatives. This theme can capture things like improving the discoverability of value-add services, adding features to be repackaged as a new subscription tier, or, as in this example, building out new features or services that customers would be willing to pay extra for. CUSTOMER KPI: Reach/Conversion BUSINESS KPI: Average Revenue per Unit (ARPU) STAKEHOLDER PARTNER: Customer Success and/or Sales Phase 7: Renew Customers remain loyal advocates of our product and business. The renew phase looks at every opportunity to keep customers happy coming back to your product or service. Almost all SaaS businesses are looking at churn, and addressing those reasons is perhaps the most apparent epic under this theme. But, similar to some of the other themes, there may be opportunities to reduce effort by integrating account management experiences within the product, such as this example that would introduce a renewal flow and add the ability for SaaS customers to pay their invoice online (instead of sending a check). CUSTOMER KPI: Net Promoter Score, Customer Satisfaction (CSAT) scores BUSINESS KPI: Churn STAKEHOLDER PARTNER: Customer Success Considerations for Journey-Focused Roadmap Themes A highlighted benefit of having high-level themes that align with phases of the customer journey is that the themes are universally applicable across every department of the business. Sharing goals across business functions create a substantial competitive advantage for consistently delivering high-value, end-to-end experiences. There are, however, some aspects of this approach to be mindful of, which include: Avoid creating silos by phase. People and tactics may be focused on a specific phase. However, Product and Design need to maintain their awareness of their work’s context within the end-to-end journey. Phases require prioritization. While I advocate for having the same consistent themes, I don’t believe that work needs always to be happening equally within each. Certain phases will have a greater need than others. It’s up to the product team to appropriately allocate focus where the greatest needs are. Phases often have embedded journeys of their own. This is especially true for the Add Services phase, where there is a complete cycle of awareness to renew to consider. Keeping customer outcomes at the heart of your roadmap, effectively mapping them to business outcomes, and sharing those outcomes across your organization is an excellent recipe for driving innovation and building reciprocal value between your customers and your business. The phases of the customer journey already have this value exchange baked-in. They can be a highly effective lens through which to view and prioritize the opportunities on your product roadmap. Read the Strategic Roadmap Planning Guide hbspt.cta.load(3434168, 'e23dbd3d-c389-4aba-b537-43c357b5672a', {});

When prioritizing items for our product roadmaps, we sort and select them based on their ability to influence key metrics, achieve strategic goals, delight customers, and generate revenue. In evaluating possibilities, we choose the initiatives that maximize ROI and make the most of the available time and resources. In short, we’re trying to create a positive impact, and one lens to deploy for these exercises is the IMPACT mindset I’ve written about in our new free ebook. But the decisions we make as product leaders extend far beyond which themes and enhancements cut the next release. In this blog, I want to talk about hiring with an IMPACT mindset. Deciding which roles our team needs and who should fill them exercises muscles product leaders don’t use that often. It’s not like we’re hiring new product managers every few weeks like some of our engineering counterparts might fill out their vastly larger ranks. Product management hires at all, but the largest companies are relatively few and far between. And because we don’t get many opportunities, that makes these decisions that much more critical. We can’t just hire another if the first turns out to be a dud without navigating painful human resources processes. Plus, we have to find someone else to do the work while restarting another lengthy recruitment and hiring process. There’s usually a decent appetite for experimentation, ongoing learning, and trial and error in product development. But not so much when it comes to staffing. This makes our hiring decisions in many ways even more impactful than some of the choices we make around our products themselves. Why hiring product managers is so hard I don’t need to tell anyone in product management that finding good talent is tricky; anyone who’s ever had the opportunity knows that resumes and cover letters don’t give you a full sense of the candidate. Plus, you tend to get a flood of highly unqualified applicants you still need to sift through. But why is a product hire so much harder than finding another engineer or salesperson, or customer service rep? It’s because we ask so darn much from product management at every level. No other job requires you to do many different things with a high level of competence and mastery. In addition to being asked, forced, and blessed to wear so many hats, there’s also no preferred path to a career in product management. Our ranks include former developers, marketers, analysts, and customer success reps. They all bring unique experiences and skills to the table. But comparing candidates with such diverse professional backgrounds can be challenging. Especially since they may all have their own ideas about what product management actually is and what the day-to-day job looks like. Product management also requires a broad slate of soft skills to succeed. These aren’t binary, checklist items that a hiring manager can surmise from a glance at their C.V., and your HR department typically can’t offer much assistance in this department either. It requires probing interview questions and reference checks that try and uncover the real person you’ll be working with and relying on if they join the organization. Using IMPACT to Choose the Right Product Hire We know product management hires are important and that it’s hard. Luckily we can apply IMPACT to this process to help ensure we make quality hires that increase productivity and cut down on turnover. IMPACT comes in handy from the very first step—writing a killer job description—to making the final decision. Each pillar gives us something to think about and consider as we seek out additional team members. hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"}); How to Hire with IMPACT Interesting You want to work with interesting people—you’re going to spend a lot of time with them, after all—so you can look for candidates with backgrounds you find intriguing. A clone army is not the goal for product teams, as every new person brings a new perspective and lived experience to the table. More importantly, you want to hire people who are interested in things. You want people that always have another question and are lifetime learners. They should be intrigued by customers and their stories, always inquisitive but not seeking to impose their viewpoints on others until they’ve done their homework. If they’re not curious, they’re not likely to be an excellent product manager. Meaningful Even the most junior product manager has a lot of leeway in how they spend their time. Since you don’t want to spend all your time babysitting your staff, finding candidates that are instinctually focused on important things is key. Their resume and how they talk about their past achievements can be indicatory in this department. Using language about “improving” or “enabling” things and “delighting customers” resonates with me far more than simply “increasing revenue” or “delivering” lots of projects. I’m looking for a strong moral compass and recognition that they have the ability to make a difference in people’s lives through their work… even if it’s on something relatively mundane. People Product management is a team sport, even if you’re the only one with “product manager” on their business card. No one in this role can succeed if they don’t work well with others. So, naturally, I’m seeking evidence of past success in this area and an awareness of its importance. “Collaboration” and “partnering” carry much more weight than simply “leading” or “running” things. Candidates must truly value the importance of working with others and creating alignment and consensus. Actionable Coming up with ideas is easy. Coming up with good ideas that are actually doable is a lot harder. I’m looking for team members that don’t let “perfect” be the enemy of “good.” This means actually getting things done. I also want individuals who identify doable opportunities and not just pie-in-the-sky ideas. By ensuring candidates are grounded in reality, I know they’re going to gravitate toward opportunities that are practical and possible. It necessitates a 360-degree-view of the situation, collaboration with technical stakeholders to assess how actionable things are, and a focus on incremental progress toward goals. I also want product managers who don’t just present information and problems. I want them to have a clear ask or solution to go along with it. This is happening, this is what it means, and this is what we need to do now. Clear Communication skills are one of the top requirements for successful product management, and I’m looking for clear, concise communication from candidates from the get-go. This starts with their own “elevator pitch,” as I expect them to entice me and sell me on them quickly. This isn’t to be mean or overly judgmental. Rather, it’s an indicator of their ability to command the room and convey the essential information—and do so in a convincing way. Product management is always competing for the time and attention of stakeholders. So I want to know they’ve got what it takes to thrive in those environments. Testable The job application and interview process is really one big series of tests and questions. Have they checked enough boxes to warrant a phone screen? Do they still seem interested after learning more about the job? Did they conduct themselves well during interviews with myself and colleagues and distinguish themselves positively versus the other candidates? hbspt.cta.load(3434168, '6dfa8cf7-7fd5-4e22-8d7e-edacfc23154a', {"region":"na1"}); I’m also testing for my comfort with the hire. What do they bring to the table, and how will it positively (or negatively) impact the combined skills, experiences, and talents of the overall team. Is it filling a need or duplicating an existing strength? But for a product management role, I will also literally put applicants to the test. These should be reserved for finalists out of respect for their time (and mine!). But for such a key hire, it’s important to see their work output and the tactics and strategies they utilize to do it. I have several examples of these test exercises in my book. Hire with IMPACT at Every Opportunity More than anything, incorporating an IMPACT approach into your hiring philosophy is all about making the most of the limited chances managers get to augment and improve their staff. Who we hire will have a massive impact on both the products in our portfolio and the teams we manage. We want assets instead of liabilities, high performers, and not needy neophytes. This requires scrutiny, inquiry, judgment, and a healthy dose of gut feel (which we normally try to tamp down in this line of work). At the end of the day, we want employees that share our values and work ethic. They should be worthy of our trust and not clash too much with our style. Using IMPACT is one way to ensure our choices match that intent.

Product Strategy is Important One of the most important roles of a product manager (PM) is setting the product strategy. The strategy, by way of a roadmap, is the document that drives team alignment. When a group of people adopts a strategy, it transforms the product strategy from just a piece of paper to something that drives team success. Informed teams, including product and everyone that affects product development—from engineers to executives, can deliver consistent results, essential to any organization that wants to grow from pure greenfield exploration into gaining product-market fit. When you are looking for consistent strategic results that you can sell to the business and the team around you, you’ll need to escape the trap of pure feature velocity (“building stuff”) and get to building the “right stuff” that makes an impact for customers and the business. Consistent strategic results are essential because as teams scale, wasting time and resources gets easier. Consistency is why the strategy must exist and live in the minds of those who need to operationalize it. That is when the strategy is truly alive when you can see it in action. But, unfortunately, most strategy is dead when it exists, but in name only. What makes a strategy alive or dead? Well, let’s start by making sure you have a strategy that works first. If you aren’t sure what that looks like, you can find our complete guide here. A Refresher of the Six Pillars of an Alive Product Strategy: 1. A product must have a purpose. Building a product just for the sake of creating and maintaining something isn’t a strategy. Products should have a raison d‘être and exist for something beyond themselves. What drives the company? Why does the founder wake up in the morning? What about your product can the customer not live without? Take the time to communicate externally to find the locus of your product’s truth. Once you simplify that into something repeatable that a team can align around, you are most of the way there. The alive product strategy has a clear, repeatable purpose. Dead strategy is muddled. 2. Understand the customer’s needs and their evolution. Our customers are important, so it is critical that any product strategy we make also has to meet the customer where they are. But, more importantly, we can’t fall into the trap of “building a faster horse” instead of a car. Our customers don’t deal in features, and they deal in problems. Those problems evolve, and so must our strategy. Alive strategy evolves with the customer. Dead strategy is static. 3. Understand your value chain and how it’s evolving. Products don’t exist in a vacuum. Neither do its users. The product strategy must incorporate how it fits into the larger ecosystem, determining where it adds value and where friction points remain. As an ecosystem changes, the product’s role within it may also evolve. When determining strategy, you can find insight into how your product makes decisions—whether looking at your competitors or what systems your product builds on to work. Alive strategy engages with the ecosystem. Dead strategy engages with a point in time. 4. Determine what change is likely to happen. Although strategic thinkers don’t possess psychic powers, they should cast an eye toward the future and anticipate likely disruptions to either limit or expand the product’s opportunities for growth and usage. Then, with a good strategy, you’ll see what chances the business is willing to take. An alive strategy makes bets. Dead strategy “knows” the future. 5. Define actions against those changes. With a view on the horizon, what can your strategy do to mitigate disruption or seize opportunities? Alive strategy anticipates risks. Dead strategy hides them. 6. Measure success and course correct. There’s no way to know if a strategy is successful if no one’s keeping score. While the strategy itself shouldn’t be hitting specific metrics, tracking progress and KPIs illuminate progress and offer potential warning signs. Alive strategy iterates. Dead strategy always starts from scratch. Click for sound @keyframes VOLUME_SMALL_WAVE_FLASH { 0% { opacity: 0; } 33% { opacity: 1; } 66% { opacity: 1; } 100% { opacity: 0; } } @keyframes VOLUME_LARGE_WAVE_FLASH { 0% { opacity: 0; } 33% { opacity: 1; } 66% { opacity: 1; } 100% { opacity: 0; } } .volume__small-wave { animation: VOLUME_SMALL_WAVE_FLASH 2s infinite; opacity: 0; } .volume__large-wave { animation: VOLUME_LARGE_WAVE_FLASH 2s infinite .3s; opacity: 0; } 4:10 #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset{font-size:14px;} #wistia_chrome_23 #wistia_grid_43_wrapper div.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper span.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper ul.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper li.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper label.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper fieldset.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper button.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper img.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper a.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper svg.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper p.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper a.w-css-reset{border:0;} #wistia_chrome_23 #wistia_grid_43_wrapper h1.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:2em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper h2.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:1.5em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper h3.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:1.17em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper p.w-css-reset{margin:1.4em 0;} #wistia_chrome_23 #wistia_grid_43_wrapper a.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_43_wrapper span.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_43_wrapper svg.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_43_wrapper ul.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_43_wrapper ol.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_43_wrapper li.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_43_wrapper ul:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper ol:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper li:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper ul:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper ol:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper li:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper label.w-css-reset{background-attachment:scroll;background-color:transparent;background-image:none;background-position:0 0;background-repeat:no-repeat;background-size:100% 100%;float:none;outline:none} #wistia_chrome_23 #wistia_grid_43_wrapper button.w-css-reset{background-attachment:scroll;background-color:transparent;background-image:none;background-position:0 0;background-repeat:no-repeat;background-size:100% 100%;border:0;border-radius:0;outline:none;position:static} #wistia_chrome_23 #wistia_grid_43_wrapper img.w-css-reset{border:0;display:inline-block;vertical-align:top;border-radius:0;outline:none;position:static} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset button::-moz-focus-inner{border: 0;} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree {font-size:14px;} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree div{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree span{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree ul{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree li{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree label{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree fieldset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree button{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree img{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree a{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree svg{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree p{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree a{border:0;} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree h1{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:2em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree h2{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:1.5em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree h3{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:1.17em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree p{margin:1.4em 0;} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree a{display:inline;} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree span{display:inline;} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree svg{display:inline;} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree ul{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree ol{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree li{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree ul:before{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree ol:before{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree li:before{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree ul:after{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree ol:after{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree li:after{display:none} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree label{background-attachment:scroll;background-color:transparent;background-image:none;background-position:0 0;background-repeat:no-repeat;background-size:100% 100%;float:none;outline:none} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree button{background-attachment:scroll;background-color:transparent;background-image:none;background-position:0 0;background-repeat:no-repeat;background-size:100% 100%;border:0;border-radius:0;outline:none;position:static} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree img{border:0;display:inline-block;vertical-align:top;border-radius:0;outline:none;position:static} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-tree button::-moz-focus-inner{border: 0;} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-max-width-none-important{max-width:none!important} #wistia_chrome_23 #wistia_grid_43_wrapper .w-css-reset-button-important{border-radius:0!important;color:#fff!important;} #wistia_grid_43_wrapper{-moz-box-sizing:content-box;-webkit-box-sizing:content-box;box-sizing:content-box;font-family:Arial,sans-serif;font-size:14px;height:100%;position:relative;text-align:left;width:100%;} #wistia_grid_43_wrapper *{-moz-box-sizing:content-box;-webkit-box-sizing:content-box;box-sizing:content-box;} #wistia_grid_43_above{position:relative;} #wistia_grid_43_main{display:block;height:100%;position:relative;} #wistia_grid_43_behind{height:100%;left:0;position:absolute;top:0;width:100%;} #wistia_grid_43_center{height:100%;overflow:hidden;position:relative;width:100%;} #wistia_grid_43_front{display:none;height:100%;left:0;position:absolute;top:0;width:100%;} #wistia_grid_43_top_inside{position:absolute;left:0;top:0;width:100%;} #wistia_grid_43_top{width:100%;position:absolute;bottom:0;left:0;} #wistia_grid_43_bottom_inside{position:absolute;left:0;bottom:0;width:100%;} #wistia_grid_43_bottom{width:100%;position:absolute;top:0;left:0;} #wistia_grid_43_left_inside{height:100%;position:absolute;left:0;top:0;} #wistia_grid_43_left{height:100%;position:absolute;right:0;top:0;} #wistia_grid_43_right_inside{height:100%;right:0;position:absolute;top:0;} #wistia_grid_43_right{height:100%;left:0;position:absolute;top:0;} #wistia_grid_43_below{position:relative;} Strategy Doesn’t Need to Just Exist Simply having a strategy isn’t enough, however. For example, if a tree falls in the woods and no one hears it, did it make a sound? Unfortunately, many teams that find themselves with a product strategy have to ask. “how does this matter to me?” and, as a result, lose interest. Strategy means nothing if it isn’t alive, in people’s hands, hearts, and heads applying to their work. So, as we continue this article, let’s ask ourselves some questions. First, does any of this sound familiar to you? Feeling unsure of what to do, even though the strategy is there. Having a ton of distractions, even though the strategy is there. Operating in the past, even though the strategy is there. Then your strategy might be dead. Don’t fear! There is an opportunity here. If you have a strategy, you’ve already done the first step, create a strategy! So, we need to turn it around, and on that note, it feels like a good time to talk about what we mean by “alive.” An Alive Product Strategy Yes, your strategy is living. In fact, strategy is a muscle and an important one for teams to exercise. Much like the muscles in your body, they need nutrition, and for them to operate at their best, they need exercise. hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {"region":"na1"}); So, what do we mean by that? When we mention nutrition, your strategy needs context. Think about point two, mentioned above “2. Understand customer needs and their evolution Our customers are important, so it is critical that any product strategy we make also has to meet the customer where they are. More importantly, we can’t fall into the trap of ‘building a faster horse’ instead of a car. Our customers don’t deal in features, and they deal in problems. Those problems evolve, and so must our strategy. Alive strategy evolves with the customer. Dead strategy is static.” When you think about your customers, this concept makes sense. Our strategy needs to build towards our customers’ context of the marketplace. What if I told you that it needs also to do so internally – stakeholders who use your strategy also need that context. So how is that strategy you made a few weeks ago? Is it alive? Does it have its nutrients? Has it gotten its exercise? In fact, when is the last time anyone referenced it? Let’s talk about alive in another way – author Robert Greene once told author Ryan Holiday this: “He told me there are two types of time: alive time and dead time. One is when you sit around when you wait until things happen to you. The other is when you are in control when you make every second count when you are learning and improving and growing.” “Strategy is something that grows” is great as a mental model to see product strategy. But, remember, product strategy is a muscle. When a team sits around and doesn’t exercise that muscle, it will atrophy. An atrophied strategy is a recipe for disaster, as it is as good as no strategy at all. In fact, an atrophied strategy is a one-step towards a dead strategy. So, let’s pose the question again, is your strategy alive? Like any new artifact, your strategy, once well crafted, starts that way. That said, from a distance, an alive product strategy can look like a dead one if you don’t know what to look for. Don’t let your strategy turn into a zombie. A Dead Product Strategy Will Become A Zombie Grrr, brains Zombies are scary (and possibly real). But we aren’t talking about those zombies right now. So instead, what we’re looking at is a zombie strategy. The people we work with are smart and ready to work. A dead strategy, however, will sap their energy and leave our teams to fend for themselves. Moreover, as our teams grow, a culture built on dead strategy is a culture whose problems compound. Product strategy is our domain, not theirs. When strategy atrophies, they will spend time working on things that make sense to them. Sometimes, the team will get lucky. Oftentimes, they will end up distracted. That distraction is how you look up in the middle of the third quarter and wonder what happened to that roadmap you set in December. But, unfortunately, you’ve been bit by the strategy zombie, and as a result, the team is now playing catch up. hbspt.cta.load(3434168, '527dc6af-8860-436f-9ca6-ae2b71b0cc99', {"useNewLoader":"true","region":"na1"}); The bad news, as a PM, is you’ve turned into a necromancer. The good news is that you can step away from that. The first step, though, is to identify if there is a dead strategy in your midst. How do you identify a zombie strategy? Well, if it’s well built, here are a few indicators. Of course, we won’t leave you without homework either, so expect some ways to clear the zombies out. Then, each section holds a way to move that strategy from dead to alive. 3 Ways to Identify a Dead Product Strategy 1. Team members can’t remember what’s important. Our brains’ short-term memory holds 5-7 things at a time. Why is that important? One of the issues that can zombify a product strategy is overloading people with too much information. We may have an urge to load the strategy with everything we need to get done. You, as a PM, may feel like you are giving proper context – however, overloading the team with context is exactly what will atrophy your strategy. Instead of giving context and helping folks find alignment, you allow the team to turn off and figure it out independently. This is how your strategy sits on the shelf and eventually zombifies. So, let’s make this real. Let me ask a question: If you were to go around your team and ask, “What are the three priorities from our product strategy?” How confident are you that individual team members can list these top priorities? What about within 80% of your expectation? If you gulped during that question, chances are, you may have a zombie product strategy on your hands. Unfortunately, whatever you thought was happening isn’t. The zombie strategy is eating your team’s mental space. hbspt.cta.load(3434168, '4077b305-9bcc-4a5a-a982-aad75ee06c23', {"region":"na1"}); In fact, brain science provides a reason for that. Our brains are more tuned to negative experiences than positive ones, up to seven times more. So those near-death experiences are negative experiences. Strategy is a positive one. Simplify your strategy The basis of strategy is here. You need to simplify. Evangelize. Become a broken record and talk about the strategy regularly. Remind people at the end of every team meeting of the important pillars of your strategy. When people start getting sick of hearing it, you’ve only begun. Prioritize. Be clear about what is important, and get rid of the rest. Cut until it hurts – a strategy that doesn’t make any choices will atrophy. Positivize. Remind people of the small wins regularly. Remember, teams think negative first, so overwhelm them with positivity. 2. Strategy incorporates incentives for all Every discipline has its own incentives. It’s important to recognize that the strategy isn’t about you. Human beings are storytellers, and without something more compelling, they will take what is around them to create their incentives. That is why a telltale sign of a lack of an alive product strategy looks like this: Engineering cares about engineering stuff, same with design, marketing, and sales. It’s natural with any vocation. Teams are just telling themselves a story and running with it. Since it isn’t compelling, they have to make it up as they go along. A strategy will atrophy if the members of the team don’t see themselves in the strategy. As a PM, are you aware of everyone’s incentive? If you have to wonder, chances are you don’t. When building the strategy, remember strategy is an abstraction. That abstraction helps people fit their mental model into the world itself. If that strategy doesn’t help them, they’ll split their time between your strategy and their incentive at best, and at worst, completely ignore your strategy. Then your strategy is dead. As an owner of the product strategy, make sure you talk to the point of contact from every discipline. Meet with the team regularly and have coffee with random team members to find out what drives those team members to work. This is a slower process, but every time you iterate, the strategy gets better. This is because you are working your strategy muscles with each conversation as you make it more alive. As a bonus, your relationship with the other discipline will get better, too. 3. Strategy relies on consistent process Do not try to turn the entire ship at once. Our teams have enough on their plate. That is why we, as PMs, have to be very careful when we bring in a new process. If we do, we have to do so thoughtfully and repeatedly. Once is not enough. Remember, our brains can only hold 3-7 things in short-term memory, so it’s far better to leverage things that are already comfortable in an organization or build it into muscle memory. As PMs, we live with our strategies for a long time, making sense to us (only). So we want to try a new process to shake things up and partially bring newness to ourselves, selfishly. So, we make the team go through an exercise, something you may find on the internet, and never refer to it again since the pieces fit so well in your head. Well, while you may remember it, the team around you has their own issues, and more than likely, is overloaded. When this happens, you’ve walked right into a dead strategy since the team has learned not to take anything you’ve done as seriously. As a rule of thumb, small edits to the current process are better than a new process. If you aren’t going to plan around a new process to ensure it’s compelling and do it often, don’t do it at all. Alive Product Strategy Starts with You There is a pattern here. A product strategy isn’t alive on its own. So simply writing a great one isn’t good enough. Instead, as a PM or product leader, you’ll need to work hard at keeping it alive continuously. It’s worth bringing up this quote again. “He told me there are two types of time: alive time and dead time. One is when you sit around when you wait until things happen to you. The other is when you are in control when you make every second count when you are learning and improving and growing.” One is when you sit around when you wait until things happen to you. The other is when you are in control when you make every second count when you are learning and improving and growing. A great strategy is something you control, iterate, and grow. If you aren’t careful, you’ll turn from a PM into an unwitting necromancer. So your strategy will be less about control and more about waiting. Strategy is a way to speed up alignment, and alignment isn’t stationary. If you aren’t working those strategy muscles, your strategy will turn from alive to dead. As a result, your team will get further and further away when strategy stands still. Building a product strategy is not enough; make sure the strategy is alive and aligned not just with the market and the customers but also with the team that is working through it. When other functions use product strategy, it lessens the cross-functional burden and gives the organization a chance to course-correct when things aren’t going well. Keep your product strategy alive with focused goals, aligned incentives, and repeatable processes. Download IMPACT ➜ hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"});

When your product can do more than it could do before, that sounds like a good thing. Added functionality, new capabilities, a more robust feature set…these are the talking points product marketers salivate over and executives search for on product roadmaps. But are you solving for actual customer problems? In the never-ending race to ship out product updates to keep up with—or ideally, stay ahead of—the competition, it’s easy to get caught up in the flurry of activity and become a feature factory. The danger, however, lies in mistaking new functionality for actually adding meaningful value to the customer experience. All those new features might look good on a product comparison matrix and give salespeople a new angle when pitching reluctant prospects, but none of it matters if those features aren’t solving real customer problems. Where are product teams getting their feature ideas? According to our 2023 State of Product Management Report, customer feature requests are still the top source of actionable product ideas, but that’s only the case for 35% of respondents. Feedback from sales and support is the source 26% of the time, and the competition inspires new features for 16% of respondents. Most concerningly, 19% of respondents reported that their top source of ideas comes from senior management, who are often disconnected from both customers and the product development process. To reframe things, only about one out of three feature ideas actually come directly from customers… you know, the people who are paying money to use your products. And while a quarter comes from sales and support, these too can come with their own caveats since there’s always some amount of interpretation and bias involved. When product investments don’t meet expectations, the blame gets spread around. But a lack of a clear company strategy (23%), poor prioritization (19%), misallocation of resources (17%), and underdeveloped roadmaps (17%) encompass the vast majority of misfires. These all point to internal deficiencies in planning rather than problematic execution. In short, organizations are making the wrong bets rather than messing up on the go-to-market or implementation fronts. Why do product teams become feature factories? No one intends to waste valuable resources on projects that don’t yield meaningful results. No software developer wakes up in the morning excited to write a bunch of code that will be re-written a few sprints later. Product managers don’t want to ship features no one will use. And no management team prefers an extra bullet point in a sales deck over another satisfied customer. But despite good intentions, feature factories arise more often than anyone cares to admit. There’s no single cause for these misguided projects frittering away precious development and testing resources, but there are some common causes for many of these missteps. A scattershot strategy In the quest to meet the needs of as many different people and customers as possible, product teams can become too ambitious and reactive in their strategic planning. Saying no to a key customer or stakeholder is challenging, so the product team finds itself pursuing multiple paths simultaneously. Implementation teams get divided up to solve lots of different types of problems, often in the same sprints. This can incrementally add new capabilities to the product and potentially quell a few customer complaints, but without a a unified vision, it can also lead to a lot of partial fixes that don’t attack and solve major pain points in a holistic manner. Instead of the product team putting more energy into validating and solving major problems, customers get a steady stream of tweaks and minor improvements across the board. This generates a sense of progress and improvement in the form of minor enhancements that may feel like you’re on the right path, but never quite puts those issues to bed from a customer perspective. It’s a bit like treading water. You might stay afloat, but you’re burning a lot of energy without getting closer to the shore. Noisy customers When it comes to your product roadmap, the customer is most definitely NOT always right, especially when they ask for specific features. This doesn’t mean customer ideas and requests should be ignored… quite the opposite! But it does mean product teams should ultimately be responsible for defining features. When a customer has a feature idea, it’s not really because they want that particular feature. In the majority of cases, they have a problem or pain point they want to address, and their suggested solution is their way of asking for help. But most of your customers probably aren’t product managers. They just want the problem to go away and this is their best guess on how to solve it. If you build exactly what the customer asks for, it doesn’t guarantee they’ll get what they actually want. For products to truly address the root cause, product managers must understand the jobs their customers are trying to get done and identify the roadblocks preventing them from achieving it. While it’s certainly possible that the feature request is spot-on, chances are it doesn’t fully address the underlying issue or will only address a very narrow set of use cases that don’t necessarily fit in with your product vision. By really digging into the problem space with customers and putting in the right validation efforts, the product team can get a clearer picture of the right solution opportunity. Then they can work with the implementation team to shape a more holistic solution that improves things for a broader swath of current and potential clients. Shiny object syndrome When an executive with enough influence gets excited about something, their enthusiasm can sometimes create a runaway train. They could be inspired by new technology, a new business model gaining traction, or a competitor’s differentiating capabilities. Whatever it is, these power brokers get it in their heads that THIS is the game-changing addition the product needs. This comes regardless of any existing customer problems to be solved. They bypass ROI calculations, due diligence, prioritization exercises, and customer validation. They lobby hard for their new obsession to jump the queue and get added to the product. Fearing blowback or simply trying to play nice with this executive, product managers just go with the flow and disrupt their own roadmap and strategic plans to make it happen. When it hits the market and doesn’t move any needles, there’s less scrutiny and criticism because who wants to tell the boss that their bad idea was a flop? And without some brave souls willing to take a stand, it’s likely to keep happening as long as that power dynamic continues. How can product teams focus on value versus volume? To ensure product development resources get expended on actual customer problems, product managers must dig deep into their toolbox. Relying on some of these fundamental principles will introduce more discipline into the process and give the product team solid footing to stand their ground and make some potentially unpopular decisions. Learn to say no Nearly everything on a product roadmap is there because someone thought it was a great idea or asked for it. Unfortunately, there are way more great ideas and requests than there is time to address them. We can’t do everything, so we must be choosy. This puts product managers in the awkward position of having to say “no” to stakeholders and customers. It’s awkward because plenty of us are people pleasers. Plus it seems odd to say we’re trying to satisfy customers while regularly telling them “we’re not going to give you what you are asking for.” Product managers don’t do themselves any favors when they agree to do everything asked of them. It’s not possible to deliver on those promises and it’s an irresponsible use of resources to say “yes” to everything. Product management would be a pretty easy job if all we had to do was take requests and hand them over to developers. Deciphering which requests will drive key results is the secret sauce. Luckily, saying no is a little easier when there’s an objective prioritization process guiding those decisions. Use prioritization frameworks Every decision to build a new feature is a judgment call. But making the decision on any one feature in a vacuum presents problems. There’s no context nor much consideration given to what DOESN’T get built instead. Using prioritization frameworks eliminates these isolated judgment calls. They force everyone involved to both justify the need for a given feature and stare at the trade-offs head-on. Consider selecting a framework that incorporates scoring and ROI. These are particularly helpful for avoiding prioritizing features that don’t move the needle in meaningful ways for customers or the business. The opportunity scoring framework puts customers in the driver’s seat, which should lead to prioritizing features that customers actually care about. The jobs-to-be-done framework is another tool that refocuses prioritization around what customers are trying to do rather than what the product team thinks they need. There are many prioritization frameworks to choose from, so teams should try out a few to find their best fit. You don’t have to pick the perfect framework. The most important thing is to use ANY of them (if not multiple frameworks). These are tools that can help force more objective conversations. Plus, they help you directly acknowledge the tough trade-off decisions that need to be made. Validate with multiple customers It’s natural to want to make customers happy. We are in the “delight” business after all. But the problem facing a particular customer may or may not represent a true systemic need. It might be unique to that customer due to external factors or just not be a top priority for others. The only way to fully comprehend the scope of the issue is to engage more customers. Discover whether this is a real problem for them as well. If it’s a common complaint causing customers a significant level of pain, then it likely warrants prioritization. Otherwise, there are likely better things to work on. Some enterprise clients may still get their personal wish list items fulfilled. But the organization should go into things with their eyes wide open regarding the eventual ROI and impact of dedicating resources to a relatively bespoke situation. Define KPIs and success metrics upfront Don’t build something, release it, and then figure out how to gauge its success. Rather, product teams must begin by defining measurable indicators of the outcome they’re aiming for. If the team can’t come up with any solid way of assessing the ROI or impact of a new feature, then it’s time to revisit the rationale altogether. No net-new features should make it onto the product roadmap without a measurable benefit for the business/customer base. Adopt a theme-based approach to roadmapping The antithesis of scattershot feature releases is leveraging themes to dictate product development. Themes create an overarching thrust for an entire development cycle. This enables the product team to prioritize multiple features to be worked on at once with the ultimate goal of building out significant functionality to comprehensively solve a specific problem area. Instead of making parts of the product slightly better, it takes one problem and tackles it head-on. This singular focus yields benefits for the entire business. Product teams can do their homework and fully understand a problem, providing valuable customer insights to the organization. Implementation teams can dedicate more resources and problem-solving energy toward identifying comprehensive solutions. Sales and marketing have a meaty set of capabilities to sink their teeth into for go-to-market and customer communication purposes. And senior leadership can get out of the weeds and focus on big-picture priorities. Keeping customer problems at the forefront Resisting the pressure to continually push new features instead of focusing on customer problems might give you a case of imposter syndrome. But rest assured you’re doing the right thing. Customers aren’t counting how many new bells and whistles your product adds. They just want it to do what they need it to do. So use the strategies above to keep your product on track and your team focused on what really matters. To bolster yourself, here’s more on why you should put your customers first.

This week, more than 3,500 attendees from 50 different countries arrived in San Jose, California for the 2017 Atlassian Summit. Events like these are an excellent opportunity for product managers to interact with reps for popular product-oriented tools like Jira and Confluence, chat with their own customers and prospects, and interact with product folks from other organizations. LIKE.TG sponsored the event and team members were on hand to chat with visitors about roadmapping best practices, attend workshops, and more. It was a great experience and we thought we’d share some highlights from the Summit along with some advice about events in general. Here are eight tips to help product managers make the most of their next event experience: 1. Meet new prospects. Approach and chat with attendees who aren’t your customers. Figure out their motivations for attending the event, if they’re happy with their existing toolstack, or if they’re looking to solve a specific problem. Are they using one of your competitors? Why? Are they in an adjacent market you might be targeting in the future? This doesn’t mean every interaction needs to be a sales demo. Think of these chats as mini interviews and think of the event as a fact-finding mission where discovery is the primary goal. Bonus: Schedule meetings or social events with local prospects ahead of the event to ensure you make the most of your travel. 2. Be a customer for a while. If you’re headed to a large branded trade show like Atlassian Summit, you’re likely to run into representatives from other sponsoring companies. It’s a great opportunity to play the role of customer and offer feedback, discuss upcoming releases, and updates to strategy. We were happy to meet with executives and product managers from Atlassian to discuss our ongoing partnership, shared values, and enhanced integrations with Jira and Confluence. Your day-to-day life as a product manager means you eat, sleep, and breathe your product, but you also use lots of products as a customer and events can be a great opportunity to switch hats and offer feedback to someone else! 3. Meet your customers. For your existing customers, use the event as a research opportunity to get product feedback, refine your user personas, and give your customers a friendly, human face to associate with your product. Figure out why your customers are attending the event. Why are they here? What are they looking for? Are they evaluating new tools, exploring alternative solutions, or just catching up socially and collecting swag? Their answers will likely vary by segment, industry, role in the company, etc., but events are generally a great way to informally meet your customers and deepen your relationship. During Atlassian Summit, we met some of our customers who provided a lot of friendly (and useful) feedback on ProductPlan. Starting a conversation at an event means you can easily pick up where you left off when you get back to the office. On that note, it’s great to take notes during the event, both for your own reference and to share with your team after the event. We recommend creating a new chat room where you can quickly share ideas with your team back at the office during the event. One of the key points Atlassian co-founder and co-CEO Mike Cannon-Brookes made in his product-focused keynote presentation was that “the best way to understand a company’s culture is through its people.” We recently wrote a blog on things a product manager should do in their first 30 days at a new company and one of our recommendations was to figure out where your customers spend their time. The events they attend certainly fall under this recommendation and chatting in person is a great way to understand your customers and their respective company cultures. 4. Be transparent with fellow vendors. Atlassian emphasized during the Summit that “open work helps teams work better together.” In other words, transparency can lead to efficiency. For vendors, this means networking with other vendors, even, in some cases, your competition. You have something in common with at least some of the other vendors in the room. You probably have some customers in common. They’ve probably tackled similar challenges or opportunities that you’re currently facing, i.e. integrating with the Atlassian suite. Atlassian Summit was a great chance for us to talk to other companies about how and why they integrated with Atlassian products. Candor tends to encourage more candor and if you’re open and transparent with fellow vendors, you’re likely to learn something new. Part of your job is to understand where the market is heading and why. You can help each other understand differentiators and shared challenges, without feeling like you’re giving away your competitive advantage. 5. Ask questions. Practice describing and asking questions about your product (at light speed). If you’re spending anytime working your company’s booth, you’re going to get the chance to speak (briefly) with hundreds of people. Events are a great opportunity to hone your product’s elevator pitch, condense its features, benefits, and value proposition, and quickly identify the problem your product solves. These are all things you likely do on a daily basis with various product stakeholders, but you probably don’t do it over and over again in 2-3 minute intervals with hundreds of people in a row. That volume really requires you to cut to the chase and understand the core value of your product. Beyond describing your product, the booth also provides a great opportunity to conduct quick interviews with customers, prospects, and fellow vendors. You’re competing with hundreds of other colorful booths, flashing demo stations, snack tables, and swag giveaways, and you want to be sure when you get someone’s attention you don’t ask them about the weather. Events are a fantastic opportunity to sharpen and practice your interviewing skills, distilling your long list of product-related questions into 2-3 core questions that ensure you make the most of your time. If you’re talking to a prospect, you might ask them how they’re currently addressing the problem your product aims to solve. In our case, it might be something like “How are you currently communicating your product strategy to stakeholders?” It’s concise. It’s open-ended. It’s a great starting point for a broader conversation. For existing customers, you can ask them how they’re using your product today, and if there’s something about it you could change or update to make them more successful in their job? However brief their answer might be, this type of face-to-face, direct feedback is typically invaluable. 6. Conduct market research. Get a sense of the state of the market. Many of the sessions and keynote presentations at Atlassian Summit focused on large trends in the software industry, including a growing focus on the DevOps community, infrastructure-as-code, and issues around scalability. Since Atlassian has more than 90,000 customers worldwide, their view of the marketplace is extremely insightful. During one of the Atlassian Summit keynotes, Jira team members discussed their belief that technology companies are beginning to move “beyond agile,” shifting more toward continuous development and DevOps practices. While you’re unlikely to make sweeping changes to your product roadmap based on a single keynote address, information like this is important to take note of and investigate. This shift toward DevOps is likely to impact Product Managers that work with development teams, directly impacting how work gets done. Beyond explicit talks devoted to the state of the industry, there’s often a couple of emergent themes at each event—ideas, companies, or products that everyone seems to be talking about in the exhibition halls or during social events. These whispers can be invaluable for product folks wondering where things might be headed next year. 7. Take advantage of getting outside. Enjoy being out of the office. Any time you can get out of the office or deviate from your daily work routine is a great time to examine why you have the processes that you do. Summit had a particularly inspirational keynote on this front, highlighting how breaking your regular routine can be very energizing, ultimately reinvigorating your enthusiasm for your product and career. Bonus points if you can pass on some of this energy to your team when you get back to work. 8. Finally, remember to have fun. People do business with people. You solve problems for people. Take some time to meet other attendees outside of the exhibition hours and head to some of the social events. Grab a drink! Grab some swag! Talking to all those people at the booth is super helpful but can be a bit grueling and event organizers purposefully build in this time to unwind with teammates and new friends for a reason. If you remember to enjoy yourself, you’re much more likely to go home with a fresh perspective on your product. If you weren’t able to attend the event in person, Atlassian is making videos of some of the top sessions and presentations available here. Have more tips for product managers on their way to an event like Atlassian Summit? Leave them in the comments below!

If you’ve been in a product for a while, you’ve almost certainly run into the problem of inconsistent documentation. This problem rears its ugly head in lots of places: Requirements spread across product briefs, PRDs, Jira or other workflow management tool tickets, and wireframes Web-based and in-app user guides Sales collateral, especially in B2B situations in which sales execs like to put their spin on the pitch Product roadmaps Inconsistent documentation is, of course, only one example of a lack of standardization within a product team. This post will focus on the last example, product roadmaps. Furthermore, the post will offer some suggestions on how you can get this issue under control. Why does roadmap inconsistency matter? What are the problems that arise from having inconsistent roadmaps, starting with the most consequential? Your story lacks coherence The worst result of roadmap inconsistency is that the story doesn’t make sense. The details at the drill-down level don’t support the big-picture vision. This inconsistency is the most insidious sign of a poor product strategy. It has the consequence of individual teams failing to align. In either case, the outcome is the same – a failure (or at least an obstacle to overcome) to achieve your goals. Your audiences get the wrong message If you only have one roadmap for the entire company that you show to everyone who needs to see it, inconsistency is not an issue for you. The effectiveness of communication might be, but that’s a different topic. Or you may work at a very small company. Smaller companies may not need to target views of their roadmap for different groups – internal/external, executives/product team/sales team, etc. If you have reached that point, however, a set of roadmaps describe a different picture of the future. When it comes to expectation management, those different understandings make a big difference. One group may celebrate the evolution of the product, while the other experiences confusion. For example, you could find yourself in a situation where the customer support team is thrilled about a fix. The fix addresses a big source of support tickets. However, the sales team is incensed that the valuable feature they have been promising customers is still in development. Or worse, depending on how large, decentralized, and empowered your product team is, you could have teams working on problems that have been deprioritized based on a change in corporate strategy. The roadmap user experience makes the reader “work for it” If your product team is of sufficient size to include multiple product managers, all with responsibility for a different aspect of the product, then you likely have multiple individuals creating and contributing to views of your roadmap at different levels. With each person applying their spin on how to visualize the plan for their area of responsibility, even if each team’s plan is aligned with the overall vision, you can end up with a document that is difficult to decipher. Inconsistency of formatting and what drill-down details to include can create an increased cognitive load on the reader or viewer that requires unwanted work to understand. At worst, these issues can make what is otherwise a well-aligned team and story come across as disconnected and disjointed. Download the Product Planning Workbook➜ hbspt.cta.load(3434168, 'bec1bbd5-4b4f-480c-ab3c-2ee61623a20d', {"useNewLoader":"true","region":"na1"}); Types of inconsistency and how to fix them Roadmap inconsistency falls into three categories: Structure Content Style You need to address all three to avoid the issues we reviewed above. Structural inconsistency Structural consistency requires the product team to choose a standardized roadmap the collective can use. Will you adopt a feature-based roadmap or an outcome-driven roadmap? If you select an outcome-driven, feature-less roadmap approach, will you build your story around themes or a north star? The second aspect of structural consistency to consider is the time horizon. Whereas traditional roadmaps orient around a calendar-based timeline, typically divided into quarters or even years in some cases, more and more teams are adopting a Now, Next, and Later approach. This type of structure, used primarily with outcome-driven roadmaps, acknowledges the uncertainty around strategic outcome achievement. Calendar-oriented timelines have more common with feature-based roadmaps, which usually aim to communicate specifics about when a new feature will be delivered. Another element of structural consistency that can be overlooked is decisions about what to include in different roadmap views. For example, sometimes it’s appropriate to include an item on the view that the sales team shows to customers, and sometimes it’s not. Having a way to manage information disclosure can go a long way toward avoiding uncomfortable conversations when a customer gets excited about an early-stage idea on the roadmap that was ultimately deprioritized. Templates and tags LIKE.TG helps product leaders manage structural roadmap consistency through templates and tags. There are a variety of template types that teams can use as-is or customize as needed. Or if none of the pre-existing templates are quite right, product leaders can create templates from scratch. In either case, product managers can save preferred templates for team members to use as they build the roadmap for their specific area of responsibility. LIKE.TG also allows for custom tags and a way to manage tags to avoid redundancy and error. Once in place, tags can filter roadmap items to create the right view for your audience and situation. Inconsistent content When you have a team of product managers contributing individual areas to a larger roadmap owned by a Portfolio Product Manager, you run the risk that each person will make decisions about what information is important to include and what isn’t. The old saying, “The devil is in the details,” applies here. A consistent set of details for every item on the roadmap goes a long way toward instilling confidence in the decisions. For example, at the most basic level, information like what you are building, why you are building it, and who you are building it for are a good start at establishing a common set of details for each item. In many cases, companies will want to go further to include information like the responsible product owner, the allocated budget, and the values assigned to each item that contributed to its prioritization. LIKE.TG has two features that are particularly helpful in maintaining consistent content in your roadmap. Custom fields give you a way to specify exactly what content you want product managers to include, assuring that when a stakeholder drills down, they get the same set of supporting details for each item. The Prioritization Board provides a customizable set of scoring criteria that allow your team to make objective decisions about the importance and anticipated value of each item on the roadmap. This objective prioritization helps you avoid the dreaded HiPPO approach to product strategy and communicate the “why” behind an item’s placement in the plan. Stylistic inconsistency Sometimes designs are objectively bad or at least worse than others when comparing the outcomes achieved by alternatives. The practice of A/B testing allows product teams to make design decisions out of subjective opinions about whether the orange or blue call-to-action button is better by looking at the conversion data achieved by each. Often, however, decisions about design alternatives are purely subjective. Should we use a serif or sans-serif font for labels? Will the items on the roadmap related to this theme be green or purple? Should we use a light orange or dark orange to denote initiatives that are at risk? Or should we use yellow? Product managers, left to their own devices, will make different decisions when creating their roadmap. Even if the rest of the content and structure of the roadmap is completely consistent, a stylistic hodge-podge is the first thing stakeholders will see, and the rest of the content will immediately be suspect. Shared legends and templates With Shared Legends and templates, LIKE.TG users can easily maintain a consistent look and feel for their roadmaps. Shared Legends allows admins to create and lock down roadmap legends. Individual users will have to use predetermined colors and labels. Just as templates allow product leaders to implement structural consistency, they also support stylistic consistency. Templates provide a way for product leaders to provide an officially-styled display format that product managers can not change. With LIKE.TG’s roadmap software, product teams have a rich set of tools available to battle roadmap inconsistency. By ensuring that roadmaps are consistent structurally, in content, and stylistically, product leaders can better communicate the information, stakeholders need with a product roadmap. hbspt.cta.load(3434168, '842368a9-af78-421f-a3cb-4da00ad39f75', {"useNewLoader":"true","region":"na1"});

Deciding which initiatives to include in your future product releases can be daunting. Product prioritization is even more difficult when there are too many opportunities to choose from and too many stakeholders to satisfy. Often these all-important decisions are disconnected from a company’s strategic goals, with product prioritization discussions dominated by opinion, a knee-jerk reaction to the latest lost sale, or the influence of a, particularly vocal executive. By using a scoring method to guide your product prioritization discussions, product managers can facilitate a more productive conversation about what to include on the product roadmap. While there are many inputs that ultimately go into a product decision, a scoring model can help the team have an objective conversation about product prioritization. One way to work through the process is with LIKE.TG’s Planning Board, a framework to help prioritize product opportunities. Based on product management best practices, the Planning Board helps you and your team objectively score new initiatives. More importantly, the Planning Board gives you a process to guide your strategic discussions. Whether you use a spreadsheet or the Planning Board, this method can make the product planning process more productive and help you get buy-in from key stakeholders. Think Benefit versus Cost Every potential initiative has two major considerations: the business Benefit and the associated Cost of implementing it. Product managers implicitly or explicitly use this calculation when prioritizing. The priority of an initiative is a composite of Benefit versus Cost (clearly, items with high Benefit and low Cost get higher priority). Benefits can be described as customer value, strategic value, revenue potential, cost reduction, or any other strategic objective your company may have. Costs often include implementation or development effort as one of the key categories. You may also want to include the impact on ongoing operational costs, or even an initiative’s risk factor. With the Planning Board you prioritize opportunities based on a customized set of Benefit and Cost categories. For example: Your company’s specific Benefit and Cost categories will be different – some companies based their categories on an ever-evolving set of criteria, while others use the company’s strategic initiatives as a basis. Whatever categories you choose, the Planning Board is customizable. The Planning Board takes into account the relative weighting of each category that you assign (the weight can add up to any number you choose). Discussing the weighting of each category in your planning meetings is a great way to get an agreement on what’s important to the organization. hbspt.cta.load(3434168, 'e1e87713-3763-4c27-8f73-f817614e5f52', {}); The Scoring Discussion: It’s All Relative Once you have an agreement on the Benefit and Cost categories, you can begin scoring the initiatives. The Planning Board uses a scale of 1-5 to rank each opportunity in a category: One (1) is low Benefit or low Cost. Five (5) is high Benefit or high Cost. It’s important that you score items relative to other items. In other words, an initiative’s score only matters when you compare it to another initiative. And because business objectives can change, scores can change as well. Once you have a score for each item, you can have a fact-based, objective discussion with the team about what to include on the product roadmap. Of course, simply because an item has a high score doesn’t mean you add it to the roadmap. You still need to practice good product management, and that includes assessing many more variables than could be included in a product prioritization framework. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); The total score and rank is a composite of Benefit versus Cost and takes into account each column’s weighting. For example, an item with 5’s on the Benefit side and 1’s on the Cost side will calculate the maximum score. Which initiatives should you score? At LIKE.TG we recommend you use this model for only big features, themes, epics, and strategic initiatives rather than smaller features. In other words, use the framework for evaluating the needle movers that make an impact on the strategic goals. We’ve made the Planning Board flexible enough that you can pull in opportunities from the backlog (Table Layout) or items that are already on the roadmap. LIKE.TG is a web-based product roadmap software. If you haven’t already, feel free to sign up for a 30-day free trial.

A tool is only helpful if people are using it. We’ve all got exercise equipment, cooking gadgets, or crafting supplies lying in corners and closets collecting dust and good intentions. There’s nothing wrong with those items, but they’re also not adding any value while they sit idle. Understanding the benefits of roadmap metrics can help align your product team. For this reason, tracking whether or not your roadmaps are being used can help guide your product team towards a shared vision. Roadmaps add value when used regularly by coworkers and other stakeholders. But once you email or Slack a document, you have no idea if anyone even opened it a single time. The lack of visibility may have you wondering if anyone actually referred to it. There’s simply no way to measure, leaving you with doubts and uncertainty. When the Ideal Meets Reality Roadmaps intend to create and reinforce alignment across the organization. They give everyone a clear view of the direction of the product or project. They connect to the key themes, strategic goals, and intended outcomes of those efforts. In a perfect world, individuals reviewing and referencing roadmaps would happen all the time. Roadmaps would be part of everyone’s daily or weekly routines. Yet far too often, roadmaps are glanced at briefly. Sometimes they may get ignored until an issue forces a second look. If people aren’t looking at your roadmaps regularly and using them to guide their own work, they aren’t living up to their full potential. Even worse, some stakeholders might still be viewing old and outdated roadmaps without realizing it, making their plans based on false information. Download Strategic Project Alignment in an Agile World ➜ hbspt.cta.load(3434168, 'bfb5032e-5746-4c05-9f2a-54b36ba0e871', {"useNewLoader":"true","region":"na1"}); Solving a Pervasive Problem Using a purpose-built, cloud-based roadmapping tool such as LIKE.TG alleviates many of these issues. For one thing, as long as people are using the web viewer to see your roadmaps, you’ll know they’re always looking at the latest version. Beyond this critical version control advantage, these tools can also provide product managers, scrum masters, project managers, and other roadmap authors with additional insights. We want to help you treat your roadmaps as a product. That means understanding if and how people are engaging with them. This is why we built roadmap Activity Metrics, so you can now see exactly how often your individuals view your roadmap each week. Putting Roadmap Activity Metrics into Action With this data, you’ll have a much better sense of whether your roadmaps are collecting digital dust or accessed regularly. Product Ops and project managers can track roadmap activity metrics just like other KPIs and metrics. After an update is shared and communicated, roadmap authors can eyeball these metrics to ensure a corresponding spike in views occurred. If not, they’ll know they need to use other vehicles to prompt this action, from leveraging a company all-hands meeting to other tactics specifically tailored to engage critical stakeholders. Additionally, roadmap owners can pursue a different course of action if roadmap activity metrics indicate that views are too low in between announced updates. Initiating open, frank discussions with various stakeholders and colleagues, you can investigate why they’re not viewing your roadmap more often. Analyzing roadmap metrics may reveal a host of unknowns, from a general lack of awareness to missing information and context. These unknowns make the roadmap valuable to your product team and stakeholders. If the latter scenario turns out to be the case, you can create custom views of the roadmap for each of these audiences, ensuring it has the most relevant information. Analyzing roadmap activity metrics can help you manage your product team better. By seeing the number of individuals who view your roadmap, you’ll be able to jump in and coach your team to socialize the roadmap’s contents and value better. It may also be an early indicator that their roadmap is flawed or missing something. Another Measure of Success Every business has many ways to measure its overall success, from revenues and profits to usage, adoption, and churn. But our internal processes don’t always have as many data points to track and put to use. Your roadmap metrics deserve a spot on your organization’s Product Ops dashboard. These artifacts are too essential to ignore. Roadmap authors now have the power to evaluate their utilization and effectiveness. Learn more about how roadmap activity metrics work in LIKE.TG or schedule a full demo today! hbspt.cta.load(3434168, '9252db78-e0f2-4f64-b933-416e291c2422', {"useNewLoader":"true","region":"na1"});

A tool is only helpful if people are using it. We’ve all got exercise equipment, cooking gadgets, or crafting supplies lying in corners and closets collecting dust and good intentions. There’s nothing wrong with those items, but they’re also not adding any value while they sit idle. Understanding the benefits of roadmap metrics can help align your product team. For this reason, tracking whether or not your roadmaps are being used can help guide your product team towards a shared vision. Roadmaps add value when used regularly by coworkers and other stakeholders. But once you email or Slack a document, you have no idea if anyone even opened it a single time. The lack of visibility may have you wondering if anyone actually referred to it. There’s simply no way to measure, leaving you with doubts and uncertainty. When the Ideal Meets Reality Roadmaps intend to create and reinforce alignment across the organization. They give everyone a clear view of the direction of the product or project. They connect to the key themes, strategic goals, and intended outcomes of those efforts. In a perfect world, individuals reviewing and referencing roadmaps would happen all the time. Roadmaps would be part of everyone’s daily or weekly routines. Yet far too often, roadmaps are glanced at briefly. Sometimes they may get ignored until an issue forces a second look. If people aren’t looking at your roadmaps regularly and using them to guide their own work, they aren’t living up to their full potential. Even worse, some stakeholders might still be viewing old and outdated roadmaps without realizing it, making their plans based on false information. Download Strategic Project Alignment in an Agile World ➜ hbspt.cta.load(3434168, 'bfb5032e-5746-4c05-9f2a-54b36ba0e871', {"useNewLoader":"true","region":"na1"}); Solving a Pervasive Problem Using a purpose-built, cloud-based roadmapping tool such as LIKE.TG alleviates many of these issues. For one thing, as long as people are using the web viewer to see your roadmaps, you’ll know they’re always looking at the latest version. Beyond this critical version control advantage, these tools can also provide product managers, scrum masters, project managers, and other roadmap authors with additional insights. We want to help you treat your roadmaps as a product. That means understanding if and how people are engaging with them. This is why we built roadmap Activity Metrics, so you can now see exactly how often your individuals view your roadmap each week. Putting Roadmap Activity Metrics into Action With this data, you’ll have a much better sense of whether your roadmaps are collecting digital dust or accessed regularly. Product Ops and project managers can track roadmap activity metrics just like other KPIs and metrics. After an update is shared and communicated, roadmap authors can eyeball these metrics to ensure a corresponding spike in views occurred. If not, they’ll know they need to use other vehicles to prompt this action, from leveraging a company all-hands meeting to other tactics specifically tailored to engage critical stakeholders. Additionally, roadmap owners can pursue a different course of action if roadmap activity metrics indicate that views are too low in between announced updates. Initiating open, frank discussions with various stakeholders and colleagues, you can investigate why they’re not viewing your roadmap more often. Analyzing roadmap metrics may reveal a host of unknowns, from a general lack of awareness to missing information and context. These unknowns make the roadmap valuable to your product team and stakeholders. If the latter scenario turns out to be the case, you can create custom views of the roadmap for each of these audiences, ensuring it has the most relevant information. Analyzing roadmap activity metrics can help you manage your product team better. By seeing the number of individuals who view your roadmap, you’ll be able to jump in and coach your team to socialize the roadmap’s contents and value better. It may also be an early indicator that their roadmap is flawed or missing something. Another Measure of Success Every business has many ways to measure its overall success, from revenues and profits to usage, adoption, and churn. But our internal processes don’t always have as many data points to track and put to use. Your roadmap metrics deserve a spot on your organization’s Product Ops dashboard. These artifacts are too essential to ignore. Roadmap authors now have the power to evaluate their utilization and effectiveness. Learn more about how roadmap activity metrics work in LIKE.TG or schedule a full demo today! hbspt.cta.load(3434168, '9252db78-e0f2-4f64-b933-416e291c2422', {"useNewLoader":"true","region":"na1"});

The past year was a lot, but dull wasn’t one of them. With so many social media posts, blogs, videos, ebooks, and podcasts, it’s hard to keep up. Look at how many browser tabs you have open right now for things you still want to read! To help you get over your FOMO on any amazing content from your friends at LIKE.TG, we’ve pulled together the most-viewed articles, blogs, and glossary entries this past year. So, without further ado, here are the top ten pieces from LIKE.TG for 2022! 10. 10 Great Questions Product Managers Should Ask Customers Kicking off our top ten is a top-ten list of its own! It’s a tenet of Product Management 101 that PMs need to get out of the building and talk to real-live customers… even if it’s just over Zoom. But while fresh insights from actual users are always invaluable, you’ve only got so much time to pick their brains. To make the most of it, these ten questions maximize your opportunity to collect primary research by asking open-ended questions that coax real nuggets of insight from these interview sessions. Best of all, it means you’ll do more listening and less talking, which is always a good thing. 9. Misfits, Geniuses, and Ringleaders: Why Product Management May Be Perfect for You This guest post from LogMeIn Principal Product Manager Carey Caulfield helps readers understand if their entrepreneurial mindset and career aspirations are a good fit for product management. Weaving in a few anecdotes and experiences from her career, Caulfield forces readers to take a clear look inside themselves to determine if they have what it takes and whether it’s a job they actually want. This primer on why product management may be perfect for you is a great read for those considering leaping to another career or for senior product leaders to share with colleagues outside the product team yearning to join. Download How to Structure Your Product Management Organization for Success➜ hbspt.cta.load(3434168, '6d5d320c-e62c-4b13-bcdb-08990df79fdf', {"useNewLoader":"true","region":"na1"}); 8. 4 Key Responsibilities of Outstanding Product Managers Whether you’re writing a job description for a future hire, preparing for your first day at a new position, or simply investigating whether product management sounds like a good gig, you need a solid understanding of what the job entails. But beyond the obvious bullet points, such as “maintaining a product roadmap” and “understanding customer and market needs,” our VP of Product Annie Dunham says she’s looking for PMs to go above and beyond in certain areas. Annie’s top four integrate some of the key soft skills product managers need to build trust and operate transparently while still holding the line against any departures from the core product strategy. See what it takes to stand out in her organization. 7. The Product Manager Career Path With no direct pipeline from trade schools or a specific college major, all sorts of people end up in product management at different phases of their careers. But whether you’re a freshly-minted MBA, a converted project manager/customer service rep/engineer, a product management “lifer,” or still on the outside looking in, there’s always an on-ramp to the PM life and new tiers to reach within the discipline. Our guide to product management careers runs the gamut from entry-level roles to the C-suite, explaining the responsibilities of each position and some tips on how to level up within the field. 6. Product Manager vs. Product Owner Although the “vs.” in this article’s title might think these roles are adversarial, PMs and POs can and should work together. But like any ensemble, they need to know their part and stay in harmony with the rest of the band. At the highest level, it’s about one concentrating on strategic matters while the other focuses on tactical execution, but this article delves further into which skills each role demands and their inevitable overlap. It also touches on cases where the same individual may fill both roles in smaller organizations. 5. 11 Revealing Product Manager Job Interview Questions All the job switching and newly created product positions this past year meant a lot of product management leaders were busy trying to determine which candidates were a great fit for their teams. But getting a strong sense of an applicant’s skills, mindset, work ethic, and style is tricky when you can only have a short amount of time with them. To help interviewers maximize their opportunity to find diamonds in the rough and kick the pretenders to the curb, we’ve got 11 tried-and-true questions that will reveal a little more about the candidates’ inner selves than their resumes put on display. From putting them on the spot to pitch you a product to having them define product management to ensure both parties are aligned on what this specific job entails, these go-to questions will give interviewers a fuller picture of the person sitting across the table…or on the other end of the video call. 4. 4 Product Management Certifications that are Worth Your Time In this crazy job market, everyone knows you need to stand out in the crowd and show potential employers you know your stuff. So it’s no surprise many current, and aspiring product management professionals were looking to burnish their credentials. This list of 4 Product Management Certifications saves you the trouble of sifting through the many options on the market. We outline what we like about each program to help you narrow things down and accelerate your path to certified product management expertise. 3. Acceptance Criteria After a meandering diversion through career-related content, our top three pieces return to the nitty-gritty details of product management work by defining a few key terms product managers were exceptionally curious about this year. As Mick Jagger once told us, you can’t always get what you want, but… you get what you need. Acceptance criteria help stakeholders separate “want” from “need” by stating the minimum necessary to move forward. Alignment around this “definition of done” is essential in the fast-paced world of Agile development since engineers are given more leeway in the specifics of each implementation. Clearly, articulated acceptance criteria list precisely what must be present before product development even thinks about testing and shipping a new release while informing the test plan for quality assurance. 2. MoSCoW Prioritization Model This rollercoaster of capitalization nabbed second place… hopefully not just because people wanted to know what that wild acronym stands for! More likely, readers remain intrigued by the particular pros and cons of this technique for deciding what to build next. The MoSCoW Prioritization Model is a fitting follow-up to acceptance criteria as it slots potential functionality into four definitive tiers: Must-have Should-have Can-have Won’t-have When the team is aligned around which bucket each feature or capability falls into, there’s no mystery surrounding what to work on first, what might sneak in, and what belongs on the back burner for now. 1. RICE Scoring Model Topping the charts this year was another prioritization method, the RICE scoring model. This acronym stands for Reach, Impact, Confidence, and Effort, and the model scores each potential initiative against each of these elements. Using this method helps teams compare the relative ROI of each project under consideration based on how many people will realize meaningful value from it, along with how certain the team feels about that and how much work it will take. This really shifts the internal debate to consider each idea holistically to make realistic cost-benefit calculations to drive their roadmap, staffing, and more. Still hungry for more? Suppose those 10 pieces haven’t sated your craving for top-notch product management content. In that case, we encourage you to explore our Learning Center, where you’ll find tons of blogs, articles, glossary definitions, and eBooks to help you master your craft and keep releasing amazing products that satisfy and delight your target audience. hbspt.cta.load(3434168, '842368a9-af78-421f-a3cb-4da00ad39f75', {"useNewLoader":"true","region":"na1"});

Ah, a free exchange of ideas. Sounds nice, doesn’t it? Until you’ve got five stakeholders sitting in an enclosed space spitting out “Must Haves” like watermelon seeds in a county fair contest. Ideas are great, but a strategy everyone can agree on is better. How can you get from one extreme to the other? How can you improve your product strategy meetings? Successful product strategy meetings don’t happen by accident — they require planning and expert execution. So here’s a 5-step formula to help make your meetings run more smoothly and effectively, and round up those maverick cats. hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {}); Step 1: Set one objective — just one — no cheating Because a product strategy meeting is generally a high-level discussion, you can expect your attendees to come ready to brainstorm, pontificate, philosophize — even argue. This is all okay, even beneficial, as long as the discussion does not stray from your meeting’s single strategic objective. Without an ultimate strategic focus, these meetings can quickly devolve from productive discussions about planning your product roadmap to heated debates about a specific feature. Or worse, they can devolve into several simultaneous arguments across the room, with attendees debating features, colors, deadlines, budgets, and other non-strategic details. This is why it’s a good idea to set a single strategic objective for your meeting. Here are a few examples: Achieving a specific revenue target for your product in the next fiscal year. Increasing the number of users (including free-trial users) over the next 6 months. Maintaining your current market position for the next two fiscal quarters. Notice that these are “SMART” goals — specific, measurable, attainable, relevant, and time-bound. Now, as soon as you open the meeting, you will want to communicate this objective with your attendees — and get their buy-in. Establishing this strategic objective at the outset of the meeting will help ensure that you and the other attendees are able to quickly identify the moment the meeting gets off-topic, so you can steer it back on track. And if your meeting does drift from its single strategic objective, you’ll be ready with Step 2… Step 2: Pave paradise, and put up a parking lot for off-topic ideas In a free-flowing stakeholder discussion about your product’s future, it is almost inevitable that the conversation will lead to ideas and suggestions that are valuable, but not relevant to your single strategic objective. What then? These are the moments when you want to be able to say, “That’s a great idea… but a bit off-topic. Let’s park it for later.” And the best way to do this is to actually have an idea parking lot on which you can jot down the idea and the person who proposed it. Your idea parking lot can be a whiteboard on the wall or a freestanding flip board in the meeting room. You could also simply keep a piece of paper in front of you during the meeting — but ideally, the parking lot will be visible to everyone in the room at all times. Often if a person sees their idea captured in a visible place, with their name written beside it, they will feel validated as being heard. Step 3: Leave your egos at the door, along with sharp objects and tuna fish sandwiches Often a product strategy discussion will drift into controversial subjects… “Should we even keep focusing on this part of the product? Our competitors have this segment of the market already.” “Do any of our customers actually care about this functionality anymore? We’re spending a lot of development cycles on it, and no one seems to be using it.” Addressing difficult topics like these can be invaluable to the long-term success of your product. But sometimes the participants in your meeting who have firsthand knowledge or data about these issues are uncomfortable sharing them in a meeting full of executives who outrank them, product managers who obviously care about the product, and developers who’ve built it. This is why it’s a great idea to encourage open discussion about the product in these meetings — from anyone. Your product strategy meetings are by nature typically positive, forward-looking conversations. But you need to use these meetings to air everything related to your single strategic objective — good, bad, and ugly. One great way to set this open discussion for your meeting culture is with a sign on the door — “You are entering an ego-free zone.” Step 4: Be ready to defend your strategy with data Of course, this culture that you want to create for your product strategy meetings — where everyone is encouraged to offer their thoughts, good or bad — does not mean that every opinion itself should be treated equally. If you want to propose a specific strategic plan, you should be prepared to back up that plan with evidence — not merely your gut instinct. A product strategy meeting can easily turn into a battle of opinions. And in a meeting where many of the attendees are executives who outrank you, it can be difficult to have the confidence to stand behind your strategic ideas if you can’t back them up with hard evidence. Furthermore, executives often have a bias for data because they know that every decision represents a risk — and people are often more comfortable with risk if it has hard evidence supporting it. Step 5: Communicate your agreed-upon strategy after the meeting When you have achieved the ultimate goal of your meeting — an agreed-upon product strategy for you to begin driving — you will want to take one more step before digging into the execution. Because people often hear things differently in meetings like these, it is a good idea to recap for everyone who participated exactly what the team agreed would be the product strategy. And the best way to do this will be with a clear, plain-language recap — accompanied, ideally, by an early draft of your visual product roadmap. Nobody trips and falls into successful product strategy meetings — you have to create them on purpose If this formula doesn’t jive with your company culture, feel free to deviate and iterate. My problem-solving method of choice is to make a list of everything that might happen and what I’d like to have happened and draw up plans beforehand. As with everything, planning ahead is the key to success, even with challenges like competing ideas, strong opinions, and limited resources. You can still unite your stakeholders around a single strategic objective, and go from there.

We recently teamed up with Pivotal Tracker and Notion to host a product management networking event in Los Angeles called “Product Stack”. Over drinks and snacks at General Assembly’s brand new downtown location, we discussed tools and techniques with talented product managers from a variety of industries. The focus of the event was on how product managers can plan, execute and measure their way to better products. The “product stack,” similar to a development stack of commonly used technologies for developers, is meant to be an ever-evolving toolkit — composed of both literal software tools and figurative tools, like prioritization models and communication best practices — to help product managers be more successful at every stage of the product development cycle. We plan to hold more Product Stack events in the near future and to continue growing our toolbox. To start, we’re hosting a joint Product Stack webinar together with product leaders from Pivotal and Notion on March 15th — you can register here. Suzanne Abate, CEO of The Development Factory and host of 100 PM (a popular product management podcast), moderated our LA event and interviewed representatives from each of the three companies about the problem that their product helps solve. Jim Semick, one of our co-founders, discussed how LIKE.TG started after interviewing over 70 product managers and learning that communicating the roadmap was a common challenge. Below is the video (and full transcript, if you prefer reading) of Jim and Suzanne’s conversation. (You can also check out Suzanne’s interview with Pivotal Tracker GM, Dan Podsedly on the Pivotal Tracker blog.) Also in the interview: Benefits of doing exhaustive market validation before writing a single line of code Why we eat our own dog food at LIKE.TG How to stay agile — even when you’re an enterprise-level PM Full Transcript Suzanne Abate (SA): Jim Semick, welcome. Jim Semick (JS): Thank you. SA: Thank you for joining us. You are the Co-Founder of ProductPlan. What’s LIKE.TG? JS: LIKE.TG is web-based product roadmap software. We have companies all over the world using our software to visualize their product roadmap. SA: It’s interesting that you built a planning software because as I understand it, you spent a lot of time planning what kind of business you were going to build. I’m talking a little bit about the journey that you and Greg took to arrive at ProductPlan. Can you share that story here with our audience? JS: Sure. I’ve been in product management a new product development for almost 20 years. I was the first product manager for GoToMyPC and GoToMeeting, both Citrix products. Then I was part of the founding team of a company called AppFolio, which is based out of Santa Barbara, and they do B2B property management software. In all those roles, I was at the very early stages of figuring out what the product was going to be. I wrote the original PRD, for example, for GoToMeeting. At that point, you have a blank sheet of paper. You can envision whatever you want the product to be. I have a background in customer development and new product development, and in figuring out what new products are going to be. Who are the customers? What are the pain points that you’re going to solve? What are the features that it has to have? What’s the go-to-market strategy? When we decided to start LIKE.TG, it was essentially a blank sheet of paper, and it wasn’t even called ProductPlan. We didn’t have a name for the company. We had few ideas knocking around in our head, and based on my experience from starting and launching other products, we did extensive market validation. Some would say it was pretty exhaustive. We actually interviewed 70 different product managers to figure out what that product was going to be. I’m a little bit detailed I suppose. I documented every one of those interviews, and asked people if we could record the interviews, and had my matrices, and so on. I tried to figure out exactly what the problem was that we were solving. And so that was the beginning of ProductPlan. We actually had gone through this exhaustive market validation process before we wrote a single line of code. Unlike the lean startup method, where you start writing code, and then putting that in front of people, and scrapping it, and pivoting, and moving onto something else, we decided to do it right from the first moment. But before that point, Greg and I talked a lot about what we wanted to have in terms of a company. We talked about the culture that we wanted to build. We talked about the size of company that we wanted. We talked about what type of product we wanted to build. We talked about whether it would be B2B or B2C. So we had that framework before we started picking product ideas to validate. We went about it a little bit differently than I think a lot of startups go about it. I think a lot of that is because Greg and I have been around for a while and we’ve launched products before. We had an idea of how we wanted to do this ourselves. SA: You’re a practical gentlemen. I think what’s interesting about it for me is that you hear so much about the story of somebody who’s got a $2 billion idea. And the only thing between them and this $2 billion idea is a company to build it out. And then they’re going to be rich, and they’re going to sell it to Facebook. That’s rarely the actual story, but a lot of people start with the idea, and then if they’re lucky, figure out that it’s a salable, scalable idea. In your case, you said let’s just work backwards from what the market actually needs and create something compelling. JS: Exactly. The original validation that we started didn’t have anything to do with product roadmaps. We did our pivoting very early on in the process. Our original concept was another product for product managers to help them track their customer interviews, and to help them catalog and communicate the learnings that they were collecting. And while the market said, that’s an interesting idea, it soon became evident that the bigger pain point was around communicating the strategy, and around communicating the product roadmap. And so we caught on to that fairly early on, and did our pivoting early. SA: What is the primary problem that LIKE.TG is actually seeking to solve? Maybe I’ll preface it by saying, for the benefit of anyone in the room who doesn’t know what roadmapping is, what’s a high level description of roadmapping, and how does your product help? JS: Most companies have some sort of a document or some way of communicating to stakeholders, and to executives, and even to customers what it is that they’ll be building. Sometimes these are PowerPoint presentations, and sometimes they’re spreadsheets, but there is some product that they’re using. Sometimes it’s Google Docs. Every product manager in every company has a stakeholder — whether it’s your end customer, or whether it’s the CEO, or whether it’s the VP of Product, you need to communicate with those folks. And so the key challenge is that the current tools out there don’t do a good job of communicating the why. They don’t do a good job of explaining, why are we doing this in the first place? I also think that, in a lot of organizations, there’s this preconceived notion that because it’s on the roadmap it’s the right thing to do. The executives might sit around the table and say, okay, this is what we’re going to be building. That gets announced to all of the employees, and maybe the customers, and maybe the investors. And then the product doesn’t do very well. So what we’re trying to do is connect the strategy of why you’re doing something with the end result, which is building x, y, and z feature. That’s what our product does; the problem that we solve is that we help you through that process. We help you communicate the strategy effectively to stakeholders in a way that they understand. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); SA: You brought up the simplicity of tools. A lot of what we’re here talking about tonight is tools, right? Using tools to be effective as product managers, but sometimes, we don’t have the right tools. We’re using Google Docs, or we’re using spreadsheets. So what are some of the specific challenges that you’ve seen arise in the context of roadmapping from not having the right process? JS: Yeah, and just to be clear, I’m not plugging ProductPlan. I think there are a lot of different ways of communicating the strategy. But I think some of the deficiencies that we caught on to early in our market validation process were that a lot of product managers, especially those who are new or maybe don’t have formal product management training, create a list of features — or worse, they have the backlog in their ticket tracking system — and they consider that to be the roadmap. From our standpoint, and from the perspective of seasoned product managers that we spoke with early on, that’s not an effective way of communicating. You get lost in the weeds too easily. You can’t see the forest for the trees. You aren’t able to take those details, especially those detailed stories, and roll them up into the big picture. So that was a problem and a pain point that we caught on to really early. The product managers that have been around the block know how to do it. They know how to roll up features into the theme level, for example. They know how to say, okay we’re going to be implementing these features, and this is the reason why we’re doing this; this is strategically why it’s better for our customers, or better for the product, or better for the company. SA: Can you share with us how LIKE.TG goes about roadmapping. What is your process? Take us through it. JS: Our internal process? SA: Yeah, we want all your proprietary information. JS: Sure, okay. SA: And then we want to leverage it. JS: Yeah, just so you know, we do eat our own dog food. We use our own product. We have our own product roadmap that communicates what we’re going to be doing over about the next six months or so, and it constantly updates. I think some of you here work for larger companies, and that roadmapping process is probably longer term. The most common length of roadmap that we see when we’re talking to our customers is about a year. But, LIKE.TG has been around about four years, and we’re a smaller, more agile organization, so we tend to look over about the next six months. We just went through a planning process for 2017 and communicated that to all the folks who work for us. Everything was described in terms of bigger level themes. SA: What’s an example of a theme at a big level? JS: A theme might be an API. For example, we know that integrations are important for our customers; getting data in and out of various systems is very important, and so we’re going to be developing an API. It’s in development, but we don’t know exactly what it’s going to look like at the end of 2017. Saying exactly what we’re going to be building is not really the best way to go about it for a company like ours because we are constantly learning. Our roadmap should be constantly evolving. We should be working with our customers every day to really understand the pain that we’re solving. So, that’s a little bit about our big-picture planning process. And then we also use our internal prioritization tool, we call it the Planning Board, and it’s basically a scoring matrix. We can put different items on the scoring matrix and look at them on value versus cost scale. I think a lot of product managers use some sort of a framework or a scoring mechanism to rank items. How many of you use a spreadsheet? SA: Show of hands for spreadsheets. JS: Okay, I see a few. SA: Get those sheepish hands up. It’s a good tool. JS: There are a dozen different ways of doing this. There are a dozen different frameworks that you can use to prioritize, but most product managers go through, at least in their heads, this value versus cost matrix. Of course, you want to be developing the things that are highest value and lowest cost. That’s the low-hanging fruit. So we use our product, which kind of bakes that into the process. That’s a little bit about our internal process for prioritizing. But, I’ll tell you, we still don’t know at the end of the year exactly what we’re going to be building because it’s constantly evolving. SA: It’s interesting, you brought up before that people rely on the backlog to sort of be “the thing”. This is something that comes up on the 100 PM podcast a lot — the challenge for product managers to weave between the strategic role, the the forward looking role, and then the more more tactical, execution based role. If you’re too much in the backlog, you’re only seeing as far out as what’s going to ship next week, next month, or whatever it is. And as you mentioned, you’re agile, and you’re a smaller shop, so I’m curious about your thoughts for larger organizations. How do they avoid falling into that trap of being stuck in “well, this is what we planned” mode? I’ve talked to enterprise product managers who have roadmaps that have hooks into three and five years out. I’m like, I don’t even know what I’m doing for dinner tonight. JS: I know, that boggles my mind. SA: So what advice would you offer, or what can you say to enterprise-level product managers as a tips, I suppose, for staying agile in the planning process? JS: A lot of product managers have so many things that they need to accomplish during the day — so many fires that they need to put out, a backlog that needs to be prioritized, an engineer standing at their desk asking clarification questions. There’s a tendency to fall into that tactical mode, and I’ve been guilty of it myself, where it’s really hard to come up for air. I find that baking customer development and customer discovery into your daily process helps, and making sure that you’re continually engaging with customers. Whether that’s somebody scheduling a customer call on your behalf, or whether it’s you reaching out to customers or sitting in on calls with the customer success team or whoever usually engages with the customers. I think continually listening to that constant stream of feedback from the customers is the best way to get perspective. And I know, it’s really hard. I think probably all of you have that fighting fires mentality. And that’s one of the wonderful things about being a product manager, you can have your fingers in so many different things. But it’s also a curse because everybody looks to you for the answer. I think that keeping tabs on the customers is a really important thing. And I think another thing is letting go a little bit — not letting other people rely on you for the answer all the time. I’ve been in that mode myself in the past where you’re seen as the single point of truth for everything. Letting that go and letting dev teams make their own decisions, and if your corporate culture allows it, allowing the UX team to take on more responsibility — I think that’s another important thing that you can do. By doing those things, you can bring it up a level and be a little more strategic about what you’re doing. SA: You have been around for four years, do you consider yourself a start up still at this point? JS: Yeah absolutely. I feel that even though we’re selling into enterprises — we have customers like Intuit using our products — we’re still very much a startup in two senses. One is that we are very agile. We have the big picture plan of four big things we want to accomplish this year, but how we get there is still TBD, and the exact features that we build to get there are TBD. I think the other thing is that Greg and I have a vision for the product. We have a long term vision for where this product needs to be, years down the road. There’s still more to do, there’s so much more to accomplish to fulfill that vision. And so from those perspectives, I think we’re definitely a startup. SA: I’m curious how the landscape has changed? When you did come to market four years ago, were there other products like LIKE.TG? JS: Yeah, right about the time that we came on the scene some other products started to come out — products specifically for product managers. And since we’ve launched, there have been other products that do product roadmapping, and really that’s okay with me — SA: You’re going to allow competitors? That’s generous. JS: I’m okay with it; I’m not freaked out by any of it. When we were validating GoToMeeting, there were 70 other online meeting products on the market already. With GoToMeeting, we were still able to disrupt the market with a product that was easier to use and had a unique pricing model that hadn’t yet been introduced into the marketplace. I actually think that competition does so many things. It shows you that there is a market, for one, and it gives you an opportunity to differentiate. I think that with our company and our product, we have some unique differentiators, when you compare it to other products. The landscape is changing, but in a very positive way. And most importantly, I think it’s changing a lot for product managers. How many product managers do we have here who have been at it for more than five years? For those of you who’ve been in the industry for a while, you’ve seen the difference. You’ve seen all of these new products coming on the market, and you’ve seen organizations like General Assembly that are providing more education for product managers. I think that it’s a very positive thing for all of us when there’s more education, and when there are more tools and products available to help us do a better job. The important things that we do aren’t managing backlogs or creating product roadmaps or things like that, but rather thinking strategically. It’s about engaging with customers and understanding customer pain. Those sorts of things are the important things. So anything that product managers have at their disposal to do a better job at being strategic, I think is a positive thing for the industry and for the occupation. SA: And market research is so much a part of the role. It’s not that you come out into the market and then you can close your mind. There’s always someone lurking around the corner with the next disruptive idea. I think the challenge as it pertains to roadmapping and product vision really is, on one hand, you want to make sure that you are staying current and that you are not being disrupted. And on the other hand, you want to make sure you are not being blown about by every wind. “Well, my competitor just built this feature, so we should build it too.” How do you manage that? How do you differentiate yourselves or hold true to your vision despite whatever your competitors are doing? JS: Yeah, that’s a great question because we’re faced with that challenge every day. A small example is that we are a product management software, and we think of ourselves as this strategic layer on top of project management software — products like Pivotal Tracker, for example, which manage the more detailed tasks that need to happen to develop products. But we’re always asked for project management-oriented features, and so it takes a lot of willpower on our part to say no. We want to continue to maintain what we’re good at, which is visualizing the strategy, and we want to keep that focus. It’s kind of a constant battle for us to maintain that.