It’s a brave new world for pricing software-as-a-service products. Gone are the days of simply setting a per-seat fee and launching. How can you choose the best SaaS pricing model for your product? In this SaaS pricing series, I review lessons I’ve learned from helping set pricing for several successful SaaS products. In my first article, I reviewed why pricing based on customer value is so important. This second articlereviews why SaaS gives product and marketing managers unprecedented flexibility to chooseunique pricing models. Models that can differentiate your product in the marketplace. Models that ideallyalign with your customers’ goals. SaaS Pricing Flexibility One of the exciting advantages of SaaS is that youcan think differently about pricing models. Unlike traditional software, customers licensing SaaS products pay for your product on a recurring basis. Your product is no longer tied to a one-time purchase. And because the product is centrally hosted, you have additional flexibility for offering your product in unique packages. Read the Power of SaaS Pricing Experiments ➜ hbspt.cta.load(3434168, 'c948d259-0fb9-457e-aece-634799b48e6d', {}); SaaS Pricing Models: a Short List SaaS gives you the ability to consider revenue models that weren’t previously possible. Here’s a short (and by no means exhaustive) list of SaaS pricing models used today. Many products use a combination of these models: Per-user(many SaaS products) Per-user with free participants (GoToMeeting, LIKE.TG) Storage (Dropbox) Features(plans based on feature tiers) Project (Basecamp) Freemium (LinkedIn) Per item/contact (AppFolio, Hubspot) Per Node/Server (Hadoop) Per Visitor/Traffic(AdRoll) Processor time/Data transferred (Amazon Web Services) Open Source (free with paid services) Advertising (Facebook) Broker fee (AirBnB) Feel free to add to this list in the comments. My point is that with so many options, you now have the ability to discover a pricing model that aligns with your customers’ goals. To learn how to make subscription pricing work for you, watch our webinar: Success-Based SaaS Pricing Model Example For AppFolio’s property-management software, we developed a unique pricing model based on the number of rental units managed by a property manager. Because we charged a flat $1 per rental unit per month, the pricing was simple and easy to understand. This SaaS pricing model resonated with customers because it aligned with their business goals. They paid more for our product only if they grew their business by adding rental units to their portfolio. If they were more successful, we were more successful. Don’t be Tempted by Competitive Pricing When pricing a new product, there is a temptation to set your pricing relative to the competition. It’s common for new products to price using the same model as competitors, but slightly lower. Sure, you can price your product the same way as your competitors, and perhaps that’s what your customers expect. But with SaaS, there are so many ways to price the product that you have the ability to stand out in the market by thinking differently. Capitalize on the approaches that your competitors haven’t considered. In my previous article, I described how we launched GoToMeeting with innovative pricing that disrupted the competitors. Keep it Simple Don’t overly-complicate pricing. With so much flexibility in SaaS pricing model options, there is a temptation to offer various flavors and packages. Sometimes there are legitimate reasons for doing so. For example, it’scommon to have three packages based on features. Studies show that this approach anchors customers, and can be an effective technique for driving customers to your best-performing package. That’s fine if this is your goal. However, creating an overly complicated pricing scheme has the potential to confuse customers and create a nightmare for your finance team. Keeping it simple reduces headaches and may even provide more revenue over the long term. For example, atLIKE.TG (product roadmap software), we saw that products in our space had complicated licensing options. Many required a paid license for every software user. Several offered complicated pricing tiers based on packages. We took a different approach to simplify pricing. We charged only for editors of roadmap data and offered free licenses to other collaborators. Rather than offering complicated pricing tiers based on features, we offered unlimited use of all features for one price. Because the product managers want to widely distribute the product roadmap to stakeholders, this SaaS pricing model benefits the customer. It’s aligned with their goals. In addition, this model gives our product more exposure within the organization, so ultimately we sell more licenses when other departments ask to use the software. In the next article, I’ll review several tips for successful pricing, including estimating lifetime value.

New product managers will find themselves asking this question a lot: “How do we build a prioritized product roadmap so that we have the best chance of making something people want?” Purposeful Prioritization of Features In order to achieve our goals, we need to be clear about what the purpose of prioritizing product features is. There are two approaches to prioritizing product features: You prioritize the features and initiatives that you, your team, or your stakeholders think would be a good idea—and hope that it works out. You start by figuring out which features have the highest engagement and which ones don’t get used. Then you identify which steps in your workflow cause the biggest drop-offs—where users are getting stuck. And finally, seek to understand your users’ needs, their sources of hesitation, and the conversations going on in their minds. This should be a no-brainer. You have a much better chance of making things people want if you understand what the market needs are, and if you focus on fixing the areas where your product has the biggest leaks. hbspt.cta.load(3434168, 'e1e87713-3763-4c27-8f73-f817614e5f52', {}); Prioritization struggles of teams But many product teams still operate using the first approach—they make decisions based on their own opinions, rather than data-informed, educated hypotheses. LIKE.TG’s co-founder Jim Semick talks to a lot of product leaders in his line of work. And in one of his recent webinars, he mentions that even large, well-known companies struggle with: Decisions not being tied to strategic goals Stakeholders questioning prioritization Priorities being driven by the loudest executives or the latest sales prospects Clearly these organizations are doing something well, otherwise, they wouldn’t be well-known. But the wasted opportunity is huge. Companies that build products based on internal opinions will eventually get beaten by the competition. So how do you make sure you’re newly prioritized product roadmap includes features and initiatives that will really move the needle? What you need is a process for generating ideas, prioritizing which ones to focus on, and getting buy-in from key stakeholders. In the following sections, I’m going to break down a step-by-step framework—originally pioneered by conversion optimization expert Peep Laja—to help you do just that. Step 1: Gather Actionable Data Like we talked about earlier, rather than creating a prioritized product roadmap based solely on our opinion, we’re going to use a data-informed approach. So how do we go about gathering data? There are 5 steps (followed by creating a master list of all the issues you found that we will then turn into potential product features, fixes, and action items): Product analytics — Identify specific steps in your product workflow where users are getting stuck and leaving instead of taking the action you want them to take. Mouse tracking analysis — This lets you record what people do with their mouse, and this can give you insights into where users are paying attention to your product. On-page surveys — If you want to find out what’s stopping people from performing a specific action, put Qualaroo on your page and ask them. Support transcripts — Dig into your customer support transcripts to find out why people are reaching out and asking for help. They usually reach out with frustrations and confusion, and that can give you insight into things you can fix. User testing — Observe current users and potential users as they interact with your product while they speak their thought process out loud. User session is also great because they anonymously record videos of your users as they use your product, allowing you to see everything they do. As you analyze the results of your research, make a list of all the places where users get stuck or frustrated, where people aren’t doing what you want them to do, and where you see things that need to be improved. If you want a more detailed explanation of how to execute each of these research methods, go check out this article. Step 2: Identify the Highest Value Initiatives Okay, so you’ve generated all of this quantitative and qualitative data… what now? Well, at this point you’ll have identified a big list of product issues and feature ideas. The next step is to figure out which initiatives are worth working on, and weeding out the ones that aren’t. First, start by thinking through each of these potential opportunities and plotting them on the matrix below. The y-axis represents the value that each initiative delivers to either the company (e.g. gets you more sign-ups) or the customer (e.g. saves them time). And the x-axis represents how much effort, time, money, and other resources each initiative will take to implement (e.g. development hours). For example, let’s say ‘Item B’ is a redesign of one of your current features. It’s not going to take much effort, and it’s going to deliver high business value. Once you’ve plotted all the initiatives you identified in your initial research, the next step is to prioritize the highest value items and figure out which ones to say “no” to. To help you make this decision, start by overlaying this grid on your matrix: As you can see, the initiatives in the upper-left side of this graph provide high business value and require low effort—this is the low-hanging fruit that you want to start with. The items that fall into the upper-right quadrant will also deliver a lot of value, but they’re more complex and require more effort to implement. These are important but should get done after the items from the first quadrant. Some of the ideas in the lower-left section may be able to deliver some quick wins, but since they provide low business value you need to seriously question whether they’re worth prioritizing. And finally, you definitely shouldn’t consider any of the ideas that are high-effort low-value. Step 3: Score Your Initiatives Now that you’ve weeded out all the potential opportunities that don’t provide strategic value, the next step is to score your remaining initiatives. Think through the benefits that your organization will receive and costs it will require to implement, and then rank each factor on a scale of 1 – 5 (1 being low benefit/cost and 5 being high benefit/cost). You can either use tools like LIKE.TG for your scoring model, or you can create your own process using a spreadsheet. And of course, this scoring model isn’t the only factor that goes into deciding which features to prioritize—you also need to take your competition, market, and customers into consideration. But this analysis can be critical for getting stakeholder buy-in. Step 4: Get Stakeholder Buy-In on Your Newly Prioritized Product Roadmap Creating alignment with your product strategy and getting buy-in from executives and managers can be tricky. But you can make it less of a challenge by proactively addressing a few of their key concerns. Our first recommendation is that you walk your stakeholders through the process you used to create your prioritized product roadmap. Demonstrating that you used a structured thought process to evaluate opportunities—rather than just going by your gut or your opinion—is an effective way to get stakeholders on board. Second, bring customer evidence to the table. This is where the data you gathered in step 1 comes into play. You’ve gathered real evidence about your product from both existing and potential customers, and this sort of data is more compelling to executives and managers than your opinion. So back up your decision with hard data. Use the metrics you gathered from your analytics tool to show them what users are doing. And then use video clips of users interacting with your product, and direct quotes from your customers to explain why. And finally, always tie your priorities back to the organization’s strategic business goals. Doing this right off the bat will help answer the question in everyone’s mind of “Why are you doing this instead of something else?” Rather than just talking about what a new feature will do, tell them how it’s going to impact the bottom line and move the needle on the KPIs that your stakeholders care about most. For example, the data shows that we’re killing it when it comes to user acquisition, but we struggle to get those users to come back over the long-term. So we’re implementing this initiative in order to improve our retention rate. Takeaways Whether you’re using a scoring model or some other kind of model to evaluate and prioritize opportunities, the technique you’re using is ultimately less important than the conversation that you’re having with your stakeholders. Regardless of the tools and techniques you use, it’s important that you’re transparent with your stakeholders, and that you give them some insight into the process you used to create your prioritized product roadmap. By addressing their concerns and objections proactively, you make it much less likely that you’ll get pushback. And the best way to do that is to show them that you used a systematic process, you based your decisions on hard data (not your opinion), and that your priorities are aligned with the strategic goals of the organization. What do you think? What process do you use to make sure you’re prioritizing the right initiatives and building things people want? Share your thoughts on building a prioritized product roadmap in the comments below! About the Guest Author: Spencer Lanoue is a marketer at UserTesting, where he helps UX designers, PMs, and marketers create great experiences. Follow him at @slanoue.

Most product managers know the product roadmap can be your best friend, or your worst nightmare. When used in the right way, the roadmap can help explain how you’ll achieve your vision. And when used in the wrong way, the roadmap can sink you with endless PowerPoint updates, meaningless features, and commitments that can never be delivered. At a recent meetup, I sat with a diverse group of product managers, to get to the heart of the roadmap issue. The folks in the room came from corporate and startup and had a range of experience. Most were working locally in Sydney, Australia, but we were also joined by an expat who was on sabbatical from Silicon Valley. In two hours, five key insights emerged around the problems that can make roadmaps ineffective and troublesome. 1. Your Organization Has Too Many Priorities One participant shared with us that his startup had seven KPIs they were tracking, essentially seven priorities… as you can imagine, this was making his job as product manager incredibly difficult. How can you prioritize development when you’re trying to move the dial on seven things at once? In situations like these, it can be easy to fall into the trap of building a little bit of everything, to somewhat satisfy each of the KPIs. But it’s also easy to fall short on every single one of those priorities and create a Frankenstein product in the process. The hard road is to push back and work with the team to identify a single clear priority, whether that be revenue, user acquisition, learning goals, or something else. This is a potentially confrontational discussion to have, but one that will pay off in terms of being able to get traction on that single goal. 2. Your Roadmap Isn’t Visually Attractive This one may cause some debate. One of our participants recounted that his CPO claimed he’d never known an ugly roadmap to be successful. Roadmaps are communication tools, so if good design results in the roadmap being easy to understand, that’s obviously an essential requirement. But of course aesthetics can go much further than that, and represent real beauty, design and style. There’s a strong argument that aesthetics lend credibility. They give your document the sense of being crafted with care and attention. They suggest to the audience that you’re a professional who can be trusted to deliver on the vision. When the audience has that level of faith in you and the roadmap, it helps drive their future behavior to support those outcomes. The keyword, of course, is audience. It’s common to create different versions of a roadmap for different audiences – a practice often focused on the content of the roadmap, but sometimes design too. Some personalities will value aesthetics, while others won’t. A product manager can deduce the preferences of the audience and consider the context to hit the right note on visual appeal. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); 3. Your Roadmap Was Created in a Vacuum Stakeholder management is the bread and butter of product management. And I have a theory that the skill of being a universal translator is what lands many people in the product management field. (That means I think you’re pretty good at it already). But sometimes, the need to own the roadmap drives product managers to produce it alone, or without the input of some parts of the wider organization. This mistake is avoided with a balance of ego and humility. Product managers have to be humble enough to recognize the best ideas, even when they aren’t their own. They also have to be strong enough to push back on ideas that have no links to strategic objectives or the target customers. By walking this balance, product managers can own the roadmap, while keeping stakeholders involved in the process. Ultimately this provides the foundation for the organization to deliver on the roadmap together. Alignment like that is a powerful force. 4. Your Roadmap Lacks Links to The Product Vision A roadmap should describe how the product is going to move the product toward the vision. I hear this mantra a lot and our meetup group spent some time discussing this concept. It’s not that product managers disagree with this one, it’s just sometimes hard to bring to life in the roadmap document. Some say we never see good examples from real companies, while others aren’t sure links to strategic goals can be concisely communicated. Think of it this way. Your roadmap is not a list of features and functionality and it’s not a project plan. It’s the document that shows how your organization will get from where you are today to the product objective. Tell your product story in a compelling way. This story will include people (your users), the journey the product is going on (the roadmap), and why it’s important (the link to the vision). hbspt.cta.load(3434168, '5894a003-79ce-4ea3-9804-dae280a96106', {}); 5. Your Roadmap Changes Every Other Week One of our meetup participants shared that his roadmap was changing on a fairly regular basis. This creates a lot of busy-work to keep the roadmap up-to-date, but more importantly, when the roadmap changes constantly it’s unlikely you’re getting any closer to those strategic goals. Roadmaps can change, in fact they should change, in response to learning, shifts in the market, and sometimes competitor activities. But too many changes suggest indecision. They suggest the organization isn’t sure how to achieve its strategic goals. If that’s the case, then it’s time to take action around that indecision. Dig into what’s driving it and set learning goals designed to reduce risks and doubts. Ruined Roadmaps Saved… There is no magic wand. Like our products, we need to iterate ourselves, constantly observing our successes and failures to improve the roadmaps we present. Many of the senior product professionals I meet say their on the job experience provides the most powerful learning opportunity, but talking with peers about the challenges they face also figures strongly in the way they build their capabilities. Meetups – or getting the perspective of another product manager – can provide an alternate view on the roadmap, which just might help reveal you’ve fallen into one of these traps. We’ve all done at least one of these at some point in our careers (Yep, I admit to it!) And we’d probably like to avoid making the same mistake again. About the Guest Author: Jen Marshall is CEO at Brainmates, the Australian Product Management Training and Consulting company that organizes the Leading the Product conference in Sydney and Melbourne. In her spare time, Jen practices Vinyasa Yoga, dabbles in philosophy and listens to crime and mystery audiobooks.

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 you’re new to a product management role, you enter the situation with minimal credibility, name recognition, or trust beyond your hiring manager. When your entire job is to define a direction for the product and convince everyone else it’s the right one, that clean slate isn’t helpful. For this role, it’s essential to grow your sphere of influence. You need to win people over and give your ideas and suggestions a fair shake. Do this by convincing colleagues that your strategic decisions are based on sound data, adequate deliberations, and keen insight. This is why you need to establish allies and supporters early on and before you try to shake things up. 6 Steps to Building Your Sphere of Influence in Your First 90 Days A constant theme for new product managers is managing their sphere of influence. If you are new to the role or new to an organization, your starting months are critical. During a recent webinar hosted by The Product Stack entitled “Your First 90 Days as a New Product Manager,” Roxanne Mustafa, Design Lead at VMware, and Pivotal Tracker provides advice to new product managers. 1. Play the “newcomer card.” You only get to be new once. Don’t miss your chance to let your newness pay dividends. For a few months, you get to ask whatever questions you want. Explore assumptions and delve into the product and organization’s history with honest curiosity. Ask fundamental questions that you won’t be able to later. Probe in a non-confrontational way. Challenge ideas before the legacy of previous PMs clouds you. Learn the history, but don’t resign yourself to relive it. This will help you understand how and why things ended up where they are. Remember, you’re on a fact-finding mission. Your mission is to understand the tribal knowledge and what things were already tried and failed. To understand how failure was defined in the first place. hbspt.cta.load(3434168, '8bd83652-2868-48a8-9b9c-ebb8e0b9c945', {}); 2. Utilize one-on-ones. Mustafa says the most important thing you must do is figure out who you must talk to and what conversations you should be having. The best way to do this is to start scheduling intimate meetings withstakeholders across the organization. Starting with the product owners. Stay in listening mode as much as possible, using the various insights you gather to slowly build up your opinions. Be sure to see whose names keep getting dropped. This way you get a sense of where the power centers are and who are the key influencers, then add meetings with those individuals to your calendar. Make sure you get on any relevant email lists, Slack channels, or standing meeting invites. Ask how each stakeholder and team defines “value” and “success.” This may not be consistent across the organization. Knowing which benchmarks and preferences each team has are useful. Particularly in understanding product managers’ views. Keep your one-on-ones on the shorter side to be respectful of their time. Thirty minutes should be plenty for those initial getting-to-know-you sessions. Follow up after the initial round when needed. 3. Demos, demos, and more demos. Any product manager should be familiar with their product and value propositions to give aproduct demo at the drop of a hat. As someone new to the product, demos can play an instrumental role in understanding the product. Seeing what different stakeholders think about it, and emphasize is important. So is showing existing colleagues that you’ve digested what the product has to offer and how to position it. To do this, schedule sessions with multiple people or teams individually. You’ll want to see sales, engineering, and the existing product team demo the product in isolation. This way their commentary and presentation aren’t influenced by whoever else is in the room (or on the Zoom). Each demo will vary in what they show off (versus gloss over) and what language they use. Seeing how sales sell the product versus what engineering believes is essential can be eye-opening. This gives insight into what each group prioritizes. You can document the gaps. Once you’ve witnessed everyone else’s take, it’s your turn. Your demo will not only illustrate that you’re now quite familiar with how the product works and the key talking points. It can also synthesize the different messages you picked up from your colleagues to give a more holistic view of things. 4. Ride shotgun with sales and support. Salespeople and support staff are the folks having the most interactions with actual customers and users. Sitting in on their calls can be very illuminating. Not only will you get a heavy dose of the voice of the customer and reinforce your commitment to customer-centricity, but you’ll also get a sense of your new coworkers. Don’t try to jump in and take over, although you can occasionally interject with a question or clarification. The real opportunity for interaction is when the call is over, and you can debrief with your colleague. These interactions can help build a report with them and show them you’re an inquisitive, thoughtful product manager. Not just some new person with a pile of opinions and assumptions. You’ll also be able to spot low-hanging fruit for some quick wins when the time comes to start prioritizing items. Be sure to ask whether anything that stood out on the call was an outlier or something they encounter. This will help you categorize what you hear as anecdotal or pervasive. 5. Search the archives. Can’t get enough forthcoming team members to talk? Support tickets and the support team can be another great resource. Reviewing these gives you insight into the current state of your customers. From there, you can review the product backlog. Note which stories were accepted in the past, the key milestones used, and how releases were packaged. You can peel back the onion even further by reviewing the conversation logs. This helps your understanding of how decisions were reached. In addition to what variables got a lot of attention, and who were the key players. Retrospectives will give you a sense of morale and feelings. If there were minutes or action items from previous retrospectives, these could be mined for details. If you’re able to attend (or even facilitate) a retrospective of a recent release, you can witness it all in real-time without any prejudices or skin in the game. Just be sure to stay in “listening mode.” hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); 6. Take a holistic approach. When you’re first learning the ropes, it’s natural to stick close to the other product team members. Or devote much of your time to building your relationship with engineering, but Mustafa warns against this. It’s important to expand in order to create your sphere of influence. Instead, she recommends taking a 360-degree view of the organization. Getting input and making connections with every department will help you get a fuller, less-biased picture. This will help you to forge connections with the organization’s broader swath and develop your sphere of influence. You never know when that will pay off, and it will certainly help you build cross-company support down the line. Make sure you also know what you’re accountable for. If the executive team expects a weekly dashboard or monthly update at an all-hands, find out and get ahead of it. Takeaways It can be hard to avoid speaking your mind and fixing obvious flaws as soon as you notice something awry. Reserving your opinions until later in tenure is the right move. You don’t want to suggest new ideas or try to impose any new methodologies until you have a solid baseline of understanding and discretely vet your ideas among a smaller, friendlier audience. If you come out shooting, many of your good ideas will be ignored or forgotten. At least until you’ve built up a stable of allies and established a favorable reputation throughout the organization. While your first 90 days isn’t your only opportunity to build your sphere of influence, it’s a great opportunity can set you up for an easier path to ship great products moving forward. Read the Career Guide for Product Managers hbspt.cta.load(3434168, '51f4627c-aefd-4981-92a8-41fe12455dbe', {});

I have been a part of two successful startups and product development teams for the past 17 years. The first was acquired and thrives today with products such as GoToMeeting and GoToWebinar. The second one, AppFolio, went public and also thrives with its software for property management companies and law firms. The key takeaway from watching each of these companies grow from roughly 10 employees to 600+ each is this: It’s all about building relationships. It is just like exercise. If we exercise regularly, a side effect is that our diet typically improves. If we build relationships and really know and care about the people we work with, everything else comes easier. So how can we build relationships on our product development teams and thrive? Here are five ways. 1. Sit Together At my first startup, engineering and product development teams sat separately, and we all had our own individual offices. As our departments grew, we were spread even farther from each other. As a result, informal interactions between different groups went away, or became more challenging. Our communication would primarily take place over email or on the phone. Our engineering and product groups would only meet weekly or biweekly to review progress. We’d attempt to “be on the same page”, and that “page” was typically a schedule expressed in Microsoft Project. We weren’t exactly “strangers” but we really didn’t “know each other”. We learned — when we don’t see the people we work with on a regular basis, we make assumptions and distance grows — “us” and “them”; and “we” and “they” language emerges. Working together becomes harder. Years later at AppFolio, my second startup, we hired Jason, the product manager I worked with closely at the first startup. At that time, our entire company was in one room with an open floor plan. We’d have casual conversations, and share the antics of pranking people’s desks when they went out on vacation. Once when Jason was out we upgraded his computer with the latest hardware from the 80s as shown below! We were all thrilled when our property manager software was fired up on his screen. It was a fun moment for everyone, including Jason. It felt like we were all on “one team” when we were in the same room. Jason returns from vacation to find a “state-of-the-art” computer setup on his desk. I remember reflecting with Jason about being together with our groups in the same space at AppFolio versus being in different wings of a building when we were at the first startup. From there, we made a pact that our groups — engineering and product — would all sit together in the same open space going forward. It’s now about nine years later, and we still work in open areas and are together as cross-functional teams of engineers, QA, UX, product managers, and agile coaches. Example of a cross-functional team area at AppFolio. Sitting together does not come easy if there are remote teams and offices. Workarounds such as Google Hangouts and GoToMeeting are available to help in such situations. We promote the use of video for our remote friends as it helps to level the playing field and bring us closer. View of our satellite office via Google Hangouts at AppFolio headquarters. View of AppFolio headquarters on screen via Google Hangouts from our LA office. 2. Actively get to Know Each Other and Build Trust Doing activities to help get team members to know each other on a personal basis is an incredible strategy for team-building and raising the level of respect on teams. At AppFolio, when we reteam or change up team membership, we have deliberate discussions about how we want to “be together” as a team. We determine what we want it to be like in our physical team spaces. We elicit team members’ preferences regarding communication and interruptions, and vision out the characteristics for our team in order to flourish. This includes understanding how we will operate when things get difficult. Because they “will” get difficult. This raises the positivity in the environment and makes conflict easier to bear. Examples are: team members’ desire to go together for a walk outside if they have a conflict, or to give “alone time” to someone you overheard having a challenging phone call. The book, Creating Intelligent Teams by Anne Rød and Marita Fridjhon, gets into the specifics of designing “team contracts” like mentioned above. We also do many other activities to deliberately enhance the experience of getting to know one another and build trust. One of them is a modified version of the Market of Skills activity from Lyssa Adkins’s book, Coaching Agile Teams. If you walk through AppFolio today you are likely to find one of these Market of Skills posters hanging on a wall or the side of a desk. Team getting to know each other via Market of Skills activity at AppFolio. We also go on short outings together as a cross-functional team. We are fortunate to be located in Santa Barbara, California. I like to take teams out on hikes and combine it with sharing personal stories to bring us all closer. A favorite activity of mine is a “Fulfillment Hike”, an activity inspired by “Co-Active Coaching”. In this activity, we share with each other a “peak experience” in our lives about something that is personally meaningful to us. At the top of the hike, we stand or sit in a circle, and go around sharing the stories we heard from our partners. Together we derive the values from each of our stories and have a discussion about which values we would like to carry over into our daily work. We put up these values on a poster in our team area as a reminder of what we want. Photo of cross-functional team on a hike up Inspiration Point trail in Santa Barbara. By actively getting to know each other, we can empathize well with each other and can build great trust and camaraderie. 3. Share and own Challenges Together During the early years of my first startup, waterfall-style development was the norm. Unable to predict, product development teams would promise a deadline but deliver late. Discussions about this topic were extremely stressful and difficult. The saving grace of this type of thing was to cut back scope (ideally) in order to get as close to the committed date as possible. Conversations about this topic between engineering and product groups couldn’t just happen on the fly. They needed to be “scheduled” due to the distance between our groups. This took time and elevated tensions among our groups. We learned that our practices prevented us from sharing and owning challenges together. We had to fix that. Fast forward to AppFolio… due to physical proximity and actively getting to know one another, product managers and engineers are more open and honest with each other. Product managers get a daily or even hourly understanding of where things are at. Everyone is present together in their work-area and at regular team events. We can even discuss our work challenges during a team hike while going through a physical challenge. The chance of having negative surprises is greatly reduced. Example of product development teams discussing work visualized on a board in their team area. Cross-functional product development teams can also share the challenge of onboarding new team members. When team members share the mentorship of a new employee, the load is lighter. And, the person being mentored gets more attention, and is exposed to different styles of working. This can include cross-group mentoring. For example, experienced engineers can help out in mentoring new and experienced product managers. In summary, we are stronger when we face challenges together — regardless of what group we are in, or what reporting structure we have. Helping each other succeed helps us realize our goal of delighting our customers with our product development roadmap. hbspt.cta.load(3434168, '9e6140b2-e382-45fd-ace0-16435228cf7b', {}); 4. Help Each Other Succeed I remember talking to our AppFolio co-founder and CTO Jon Walker about a challenge I was having with a fellow team member. He looked at me and said, “Heidi, how can you make this person successful?” That simple phrase changed everything for me, and I’ve come back to it over and over again as I coach people around me. When we hire people, we want them to thrive and be successful. That’s why we hired them. Helping to educate team members on this simple yet powerful topic can make an incredible impact. When I hear complaints about another person, I even find myself echoing Jon by saying, “How can you help them be successful?” When I mentor people at AppFolio I like to teach them the concept of Net Promoter Score (NPS) applied to us as individuals. We use the concept of NPS with our AppFolio customers on a regular basis. It tells us how likely our customers are to recommend our software to other people, as well as collects qualitative comments that we analyze for improving our products. It comes from the book The Ultimate Question by Fred Reichheld. When applied to people, I encourage people to think about their behavior and actions and how they think others might perceive them in their teams and outside their teams. Are they “creating promoters” for themselves? What are the chances that their behavior will be championed by other people around them? Teaching team members tools and techniques for communication challenges they are experiencing is a great way to support them and to help them grow. In recent days I have been teaching managers techniques to use with people on their team to help prepare them for having what they perceive as “difficult” conversations with others. We do an empathy building exercise based on a modified “3rd entity” activity from Organizational Relationship Systems Coaching (ORSC). When you reteam at AppFolio, you have the opportunity to work and learn together with different people. But you might be used to the style of a particular team member and expect that the people on your new team will act in the same manner. This is the type of scenario you face with a fast-growing company like ours. Deliberately promoting the attitude to help one another encourages everyone to be “in it” together. This might mean building more patience and helping fellow team members along the way that are new to their roles. It also might mean putting our named “roles” aside and doing whatever to help the endeavor move forward. 5. Have Outings and Learn Together At the first startup, we had the tradition of having annual retreats where our engineering department would go camping, white water rafting or some other trip typically involving the outdoors. The tradition originated, according to our founder Klaus Schauser from an experience he had with a student group that he was a part of at UC Berkeley. AppFolio was co-founded by Klaus, and when we were a startup we continued this tech retreat tradition, starting with our inaugural retreat white water rafting on the Kern river. Photo of AppFolio as a startup after its inaugural tech retreat rafting on the Kern river. Since we had the pact to always sit together with product and engineering, it seemed fitting to continue that vibe by inviting and having our product development teams go with us on every tech retreat. It’s now almost nine years later and the groups have gotten much larger. Still, all of the people who work on building the products together — engineers, QA, UX and product managers go on this annual trip together. It’s nothing short of epic! We have done camping at the Channel Islands together, white water rafting, high ropes, and have even been to Disneyland. Teams have quarterly budgets to do local events together as celebrations to mark milestones, or they can do them just for the sake of bonding and getting to know each other better. This organizational support has helped us thrive, especially for the years in which our engineering and product teams doubled in size. Often different groups also bond by going to conventions together, where we learn together and get to know each other in a setting apart from the office. We’d also plan and organize extra social events while in the corresponding city. Last year we were in Washington DC together, and we visited several sight seeing locations, and even rode a ferris wheel. In the photo below are two engineering directors, two agile coaches, three product managers, one UX engineer and one QA engineer. Having this shared learning and joyful experience brought us closer together and it was just plain fun. Photo of team members after they rode a large ferris wheel in Washington D.C. Summary Reflecting back on the experiences I have shared at both startups, I can tell you that relationship building is critical. As individuals, we are at our jobs to make money and to survive as independent people in the world. We spend more time at work typically than we do with our families. The time we spend with our co-workers, our friends, can include some of the most memorable and incredible times in our lives. We can work together and create incredible products for our customers, and love every minute of the experience together. If you know and care about the people you work with, everything else comes easier. About the Guest Author: Heidi Helfand has 17 years coaching and influencing cross-functional product development teams at pioneering web software companies. At Expertcity, Inc. (acquired by CitrixOnline) she was on the initial team that built GoToMyPC, GoToMeeting and GoToWebinar. She is currently Principal Agile Coach at AppFolio, Inc., a SAAS workflow software company with property management and legal practice management software. Prior to that, Heidi consulted for the State Dept. on website development, and has taught ESL at several US Universities. She has an M.A. in teaching from the University of Illinois at Urbana-Champaign and is a Certified Professional Co-Active Coach (CPCC) and Associate Certified Coach (ACC) through the International Coach Federation (ICF). Follow her on twitter @heidihelfand For more information visit heidihelfand.com Acknowledgements I would like to send out a special thanks to my AppFolio friends Jon Walker, Rahul Sawhney, Regina Rodwell, Jennifer Payne, and Ellie Thomas for their feedback on early drafts of this blog. I’d also like to thank Joshua Kerievsky of Industrial Logic for his thoughtful comments and encouragement. References Rod, Anne Fridjhon, Marita. “Creating Intelligent Teams” KR Publishing, 2016. Adkins, Lyssa. “Coaching Agile Teams: A Companion for ScrumMasters and Project Managers in Transition” Addison-Wesley Signature Series (Cohn), 2010. Kimsey-House, Henry; Kimsey-House, Karen, Sandahl, Philip, Whitworth, Laura. “Co-Active Coaching: Changing Business, Transforming Lives.” Nicholas Brealey America, 2011. Reichheld, Fred Markey, Rob. “The Ultimate Question 2.0: How Net Promoter Companies Thrive in a Customer-Driven World.” Harvard Business Review Press, 2011. CRR Global, Organizational Relationship Systems Coaching (ORSC), http://www.crrglobal.com/coach-courses.html

Be a hero, follow the money, and market yourself. Got it? Really? On top of everything I am responsible for as a product manager, you’re telling me I should care about content, too? Isn’t that someone else’s job? Yes, you should care. Even if there is a dedicated product marketing manager responsible for messaging, demand generation, and sales enablement, as a product manager, you should contribute content. And if you are responsible for the go-to-market side of product management, you absolutely positively should contribute content. But who has time? If one more person asks me for screenshots, I’m going to scream. Sounds like a software product manager! Screenshots are not content marketing. Not that marketing doesn’t need them to create product assets, but what I’m talking about is providing context around personas, market problems, market stories, and customer successes with your product. Content that leads to your product, not with your product. Content that helps buyers buy and helps move them along their journey to buy and use your category of products. Raw content that can blossom into engaging content that buyers want to consume. The content might spawn an ebook or video or blog entry or infographic or short social media post. And no, I’m not saying you are responsible for producing the content into finished form (more about this later). About screenshots: If you just grab a lot of screenshots without first understanding what story the screenshots should tell, you’re wasting time (yours and marketing’s). Start with the problems you solve and tell the stories of how your product solves those problems within the context of your personas’ lives. Otherwise, why should they care? Seriously, why should I care about content marketing? One more time, three great reasons: 1. Be a Hero Product managers are often compared to superheroes. After all, it takes superhuman strength and superpowers to identify market problems worth solving, get your product funded, guide development to build what the market wants to buy, help marketing tell the world your product exists, help sales figure out how to sell it, and keep the product, marketing, and sales machines fueled, maintained, and operating at full capacity. All good. But even if you are doing a great superhero job, you might still blend into the background at your company. Like Clark Kent. Sometimes you need to put on your cape and tights and let everyone see your heroic activities. Translation: Create some content to help market and sell your product. After all, you can have the greatest product in the world, but if no one knows about it, who is going to buy it? You need this to have a successful product. Be a hero for the product manager (you). If you’ve been doing your job right, listening to and observing the market, looking for compelling problems to solve, understanding the context of users trying to get their jobs done, and hearing what buyers want and why, you have the basis for content to help buyers buy. Share, share, share your knowledge! I’m freaking out. Are you saying I need to produce all of this amazing, finished content? Breathe. Unless you’re two guys in a garage in pre-startup mode with no money, what you need to provide is the market context, not the finished production-quality content. It’s like working with development. You provide context about what the market needs and they build the product. Which brings us to the second reason you should care about content marketing. 2. Follow the Money If you look at the departments you work with, only one of them seems to have money to spend. Marketing! According to an infographic created by TAMBA (a social media agency), the average marketing organization is spending a sizeable chunk of their marketing budget on content. B2B marketers are spending 28% B2C marketers spend 25% According to TAMBA’s research, the top 2 most outsourced content marketing activities are writing (44%) and design (41%). Cool! Let marketing fund the production of the content while you provide the context. Just like working with development where you create user stories, requirements, or some other form of context so they can build the product, you need to transfer your market knowledge to someone who will manage the production of the content and turn it into tasty, engaging content treats. If done right, some of the context you provide for development may be reusable to educate marketing. The essence of what you need: Problems you are trying to solve for your customers. Describe this as if you were telling a friend or family member what the situation is that causes the problems. If you’ve been spending time in the market like you should, share specific stories about the problems customers face and why they need the problems solved. And the problems are not “need more revenue” and “we’re spending too much”. You need enough context that the resulting content is not so generic (“for everyone”) that it resonates with no one. Buyer and user personas.The better you can profile your personas around the issues they face, how they consume information, where they go for advice, how to find them, what their spending authority is, what their aspirations are, and how they are motivated, the better your content will be. If you don’t know anything about the people who buy and use your products, focus your research efforts on learning about them. How your company can help: Offer advice, resources, survey results of others like them, “how to” tips and tricks, “what’s cool”, “what’s new”, risks and rewards, customer success stories, and how your solutions solve the problems. If you stay close to your market, every time you learn of a new problem they have can be an opportunity to create content that empathizes with them and advises them on how to solve the problem (whether it’s through your product or not). You may be begging marketing to create marketing stuff to generate demand for your product. If you want them to pay attention to you, give them what they need most from you: context to create the finished marketing asset. To create effective marketing programs, marketing needs context about why buyers should care about what you sell, starting with non-product advice about solving their problems. It’s really hard to market without effective, relevant content. It might be impossible. The content is the fuel that drives marketing activities and the marketing machine. You will be a hero to marketing (see reason #1) if you provide the market context that will help the product fly off the shelves, and marketing will be more likely to spend money promoting your product if you give them the delicious raw materials of compelling market stories that engage buyers. 3. Market yourself As product managers we get so busy, we forget to market ourselves. Don’t wait until you need a job to focus on your career. Do a great job for the company you work for, but use your successes to help you reach your career goals. If a job opportunity comes to you next week, what will your potential employer find when they Google your name? By sharing great content on your social media platforms, you can build a presence and reputation that can help you in the future. “Don’t wait to dig the well until the well goes dry.” Too late! Remember that you don’t have to “build” all content yourself. In your product, you should be making “buy, build, or partner” decisions to solve problems, why not do this for content? BUY No money? See #2. And help marketing spread the word about the content by sharing on your social media platforms. BUILD If you want to be considered a thought leader in your category or industry, you need to create some of your own content (not the creative design, but the ideas). Maintain a list of potential topics and carve out time to periodically: Write a post for your company or personal blog Write an update for LinkedIn Post comments on LinkedIn groups Participate in LinkedIn discussions Do a speaking engagement (online or in person) and post the slides on SlideShare Tweet to drive traffic to your content PARTNER Curating content from other sources is a great way to amplify your social media presence. Be thoughtful about what you share, however. If a potential employer or recruiter sees the post, does it help tell the story of who you are and what you care about? And have you added your point of view to the content you are sharing? Always respect copyrights and source the content you’re curating. It’s the right thing to do. But add your point of view to augment what you’re sharing to illustrate your expertise, knowledge, or opinion. So what is content marketing, anyway? One of my favorite marketing bloggers is Jay Acunzo. He wrote the funniest blog at Sorry For Marketing defining what content marketing is (and isn’t). According to his Jargon Monster: “Content marketing is an umbrella term covering a set of strategies, techniques and tactics to fulfill business and customer goals by using content across the customer life cycle and the business functions in a consistent, integrated and continuous way.” Read that again because you may not have really gotten it. What?? Really? If someone can’t get what you write the first time, then maybe it’s gobbledygook. Sadly, this was probably written by a marketer… Shameful. Here’s what Jay’s Naked Little Truth says: “Content marketing is just solving the same customer problems as your product but through media you create and distribute.” (My emphasis.) Imagine that. Solving the same customer problems as your product. That’s when the lightbulb went on for me about why product managers should care about content marketing. You already have the knowledge to create great content. You need the same context to define your products and services. A great example of content that solves the same customer problems as your product is this ebook from LIKE.TG: This ebook is chock full of ideas and content addressing the challenges product managers have. When I first saw this on Twitter, they had me at the title. Click, register, download. If the title isn’t enough for you, what about: How to develop a winning product strategy Best practices for building your roadmap 9 example roadmaps to get you started If none of this resonates with you, you’re not a good prospect for the product anyway. Move on. If you want more examples of great content, check out what my marketing team at Sage Construction did with our Job Ready program. Don’t be intimidated by the depth and breadth of content, however. We built this program agilely, theme by theme, quarter by quarter. Content became the basis of our marketing strategy, fueling the marketing machine throughout the customer journey. I’d love to hear your successes about how your content rocked it. Did content make you a hero? Did marketing embrace your content and create awesome assets leading to lots of business? Did content help your career? About the Guest Author I wasn’t always a marketing executive and consultant. My journey from the trenches to management to the executive suite to becoming an elite member of the Pragmatic Marketing team of instructors and back to the executive suite has given me a unique perspective on technology marketing. Let me apply my expertise and passion to help you unlock your story to engage colleagues, customers, and buyers. From idea to content to visuals to delivery. Contact or follow me: [email protected], @barbaragnelson, LinkedIn.

I still cringe when I think back to the first roadmap I put together. Like most of us who find ourselves in product management, at the time I didn’t even realize I was doing “product management.” I was the lead of a UX team and saw a bottleneck between our work is designed and being implemented by the development team. So I sat down and wrote out the requirements and the order in which I thought the work should be done. As you might expect, it was a terrible roadmap. Cobbled together in a spreadsheet with links to a prototype serving as the only design specs, there was little visibility into what we were building, let alone why. I can’t believe my teammates put up with it. Thankfully, much has changed since then. For starters, I’m officially running product at my new company, Notion. More importantly, we have a process in place for team-wide alignment on our roadmap thanks to increased visibility and understanding of why we are building what we are building. We accomplished this by gathering what we call Little Data to tell the story of how we align and adjust our roadmap. Aligning the Roadmap LIKE.TG’s Planning Board feature is a great way to align your team around upcoming features. Thanks to their built in Weighted Scoring Model, it’s easy for the entire team to rate features as they relate to your goals as a company. At Notion, our benefits are designated by Customer Signal, Quarter Strategic Value, and Growth Opportunity. In other words, we rate a feature based on how high the demand is, its alignment with our growth goals, and how marketable it is. Our costs are broken down by Estimated Sprints, Unknowns, and Risk. These help us identify how long a feature will take to build, how much discovery still needs to happen, and whether or not the feature jeopardizes other elements of the app or user experience. After rating and reviewing these as a team, we are left with a prioritized list for the quarter based on the final score of each feature. That doesn’t mean we always build in that exact order, but we now have a baseline to measure any changes to the roadmap against. If anyone on the team wonders why we are building something, we can point back to the list and (hopefully) be able to explain our decision process. It’s a massive improvement from the laundry list of features I used to keep in Excel and has really increased team buy-in on what we are building. To learn how to build a data-driven roadmap of your own, watch LIKE.TG’s webinar: Adjusting the Roadmap The prioritized list from LIKE.TG serves another purpose. The synthesis of the costs and benefits correlates to the perceived value we are delivering to our customers. The higher the rank, the higher the value. This is critical data to reference as we measure our success goals since the other half of owning a roadmap is being able to make adjustments to it. hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {}); We gather this data in Notion itself. As a tool, Notion brings together team, product, and performance data to help you make smarter, faster decisions. This means as a team, we are able to dogfood our own product to improve our own product. At the end of each sprint, we poll the team on a few team health metrics, one of which is how much value we think we are delivering to our customers. We can compare that value alongside other metrics we track in Notion like conversion rates, growth rates, and user activity around specific features. A dip in delivered value may result in undesirable drops across the board. We’re also in frequent contact with our customers to get a better sense of what is and isn’t working for them. If adjustments need to be made, we use this data to support our decisions. We can go back to the Planning Board and identify where we may have missed in our initial estimations, make the necessary adjustments, and document it so we can avoid the same mistake again in the future. Getting Started If you are interested in approaching your roadmap this way, my best piece of advice is this: Start small and be flexible. There is no secret set of metrics that will apply to every team or company. Plus, your needs and goals as a company will most likely change over time. Align your team by creating visibility into and understanding of your roadmap goals. Once this exists, the metrics you need to track should be easier to identify. For more tips on how to get started, you may find our School of Little Data helpful. Or feel free to reach out, we’re always happy to chat. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); About the Guest Author: Kevin Steigerwald has been designing, researching, marketing, planning, and building products big and small for over 10 years. He is currently the co-founder and CPO of Notion in Portland, Oregon.

At LIKE.TG, we meet hundreds of product managers across virtually every industry. Their experience gives us invaluable insight into the profession, its challenges and its best practices. Today’s post is based on an interview with Julie Hyman, Senior Product Manager for Dell Software Group. A product manager with more than a decade of experience, Julie now manages several data prep applications in Dell’s Toad suite. LIKE.TG: If you could give only one piece of advice to a new product manager, what would it be? Julie Hyman: This one really took me a long time to learn — you always, always need to keep customer experience as a top priority. It sounds obvious, because in the end, of course that’s what makes for a successful product. But what you’ll find throughout the development process is that many constituencies in your organization are going to be coming to you with different agendas. Sales will come to you and ask to break the app you’re building into two separate pieces, “So we can sell two SKUs.” Development might recommend you code the product differently from the way you have it on your product roadmap, “Because this other way will work more seamlessly with our backend system.” Even your executives might ask for shortcuts, “Because we really want that product rolled out for GA this quarter.” You know what’s missing from all of those conversations? How any of those decisions will affect the customer experience. So that would be my one piece of advice: Always be your customers’ strongest advocate. Always keep their interests and their experience in mind. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); PP: What are the big mistakes that you’ve seen product managers make? JH: The biggest misstep I see is product managers getting too comfortable in one of two areas — either a strategic focus or a tactical focus — and then staying in that mindset all the time. To be an effective product manager, you really need to bounce back and forth between the two. Here’s what I mean. Let’s say a software product manager really enjoys thinking big picture. So he holds lots of high-level, strategic meetings with executives and with marketing and sales to discuss five-year plans for his product. Or to discuss huge undertakings, like how the product will be adapted for mobile or the cloud. These are great conversations to have, but that same product manager is also responsible for the next release of the product, which means he’s got to spend time with his developers and his scrum master talking about features and other more tactical details. I’ve also seen product managers make the exact opposite mistake — spending all of their time in the weeds, working every day with their development teams on the smallest details like the product’s background color and the size of the shadows on a button. Those are valuable conversations to have, too, but that product manager needs to lift his head up regularly, step back, and examine his product from a more strategic perspective. What I’m saying is, product managers can’t really afford to be specialists. You need to know your product, yes, down to small details. But you also need to spend time and focus gaining insights into your company’s overall strategic goals, your market, your customer personas, your competitors, and plenty of other strategic items. To be an effective product manager, you’re going to need a big shelf for all of your hats! PP: How do you learn what your customers really think about your product and what they want from future versions? JH: I ask them — directly. Feedback tools like SurveyMonkey can be effective, but in my experience nothing beats actually meeting with someone who is using your product in their everyday workflow, sitting next to them, and watching how they actually interact with it. Or getting on the phone with someone who is using your product and hearing what they have to say about it, the good and the bad. This is another misstep I’ve seen a lot of product managers make. We can easily become too insulated, reading the industry magazines and analyst reports, and talking with our own colleagues, and substituting those opinions for our own market research. When you think about it, it makes no sense to do it that way because we obviously have a much richer source of feedback — our own customers! We still need to use that third-party research from the analysts, of course. That research also includes invaluable information on the personas who don’t actually buy our products, the people who instead buy from our competitors, or who decide they don’t need a solution from any of us. We need to learn about what informs those decisions. But I am always surprised at how many product managers I meet who have all of these opinions about why their products are succeeding or failing, and yet don’t go out and actually talk to their users, or who talk only to the same handful of “friendly” users all the time. So my advice here would be to use it all. Read the independent industry research. Do your own SurveyMonkey surveys, but use them sparingly enough that you’re not turning off your customers or wasting their time. But above all, go visit your customers face-to-face, or get them on the phone for 20 minutes. Let them tell you in their own words what they like, dislike and want in your product. PP: What would you say is the most important skill for a product manager to have? JH: Above all else, I think that to succeed as a product manager you have to be an effective influencer. Here’s why. Your title in most cases won’t give you the luxury of ordering people within your company to do things in a certain way or within a certain timeframe just because you want them to. In fact, you’ll often find that in many situations where you need to work with other teams, you won’t have any organizational authority. The development constituents you work with could be anything from scrum masters to vice presidents — farther up in the company’s hierarchy than you are. Same with sales or marketing or PR. The people in these departments whose help you’ll need to drive your product development could all be higher than you are on the org chart. So, how can you move these constituents to work with you, in a way that’s consistent with your vision, and bring your product successfully to market? You have to use your powers of influence. In other words, you can only earn your authority with these constituents, by convincing and persuading your colleagues to see and agree with your strategic vision for your product. And to do that effectively, you need to use your knowledge, your reason, and your ability to paint the picture for them of where you want the product to go. (Enthusiasm doesn’t hurt, either.) And how do you do this? Have good data. Use logic. And just as important, tell good stories. There’s an emotional component to a story, and it is how people will understand and relate to what you’re suggesting. That means you need to communicate a successful vision of your customer’s experience. You need to paint a clear and compelling picture of what you’re trying to achieve for your customers. Then you need to use your powers of persuasion to bring all of these constituents onboard. In the end, I think that the simplest way to think of your job as a product manger is as your product’s chief influencer. Here’s another way to think of it. Being a product manager is more like being a coach than a supervisor. You can’t force it. These different teams, who will be so instrumental in helping you bring your product to market, will need to stay motivated and working toward a common objective through a development cycle. You need to convince them — and keep convincing them, over this development period — that the path they are taking with you is the best road to a successful product.

Public speaking isn’t usually included as a required skill in a typical product manager job description. But it should be. Today’s article on public speaking tips is written with product managers in mind, but is broadly applicable to many trades. We’ve been trained to think of public speaking in only the narrowest sense: a professional standing on a stage or at the front of a large room, often behind a podium, delivering a speech to an audience. But for product managers, public speaking can take many other forms. In this broader context, a product manager’s job often requires public speaking — at product roadmap meetings, development meetings and daily scrums, sales meetings, executive stakeholder meetings, analyst briefings, product demonstrations to prospects, customer site visits, and many other settings. Then there are all of the other public speaking opportunities designed to establish product managers and their companies as thought leaders in their industries. These include sitting on discussion panels at conferences, tradeshows and other events; hosting educational webinars on issues related to their products; and being interviewed by reporters or analysts as public representatives of their products and industries. In fact, you can even think of a product manager as her product’s chief public speaker. Given how important public speaking is to a product manager’s job, here are some tips and strategies to help you become a more effective public speaker — and, as a result, more effective as a product manager. How to be an effective public speaker Speak with Authority — by Using Data This tip will apply in virtually every situation where you have to speak to a group — whether you’re running a development meeting to discuss features and product details, or delivering a high-level product roadmap overview to your executive stakeholders. As a product manager, you have the data that support your decisions for which features your next product iteration should prioritize, how to adjust your pricing scheme, and what the best time will be to roll out your product for general availability. The data can take the form of quantitative metrics related to the product or qualitative data such as the results from customer interviews. Using data to support your talk can give you two important advantages in persuading whatever audience or constituency you are speaking to. First, bringing relevant data into your discussion positions you as the authority on the topic. This credibility can help you overcome the barriers product managers often encounter when, for example, trying to convince executives to green-light to a new initiative, or when trying to persuade a sales team to agree to a new pricing structure for the product. A second advantage of supporting your talk with data is that it signals to your audience that your suggestions and requirements are not simply your opinion but rather the result of real-world evidence. This will often give your constituencies more confidence in your decisions than if they believed those decisions were only the result of educated guesses. Some product managers are reluctant to deliver presentations or run meetings based on statistics, charts or other data, because they worry that the material will be boring. This is a valid concern: A talk or meeting driven entirely or primarily by dry statistics can cause you to lose your audience to thoughts about what to have for lunch. But you can find ways to include credibility-enhancing data points in your discussions without losing the room’s attention or enthusiasm. The best way is to use your data points sparingly, and to build them around a lively, more interesting mechanism for delivering your talk. Which leads to tip 2…. Build Your Talk Around Stories Often the best way to structure a presentation or other public talk is to deliver it in story form. People respond to stories. They remember stories. Stories provide a convenient framework for a complex discussion, allowing you to quickly bring everyone in the room onto the same page in terms of the big picture, before you dive into any details. To explain why this works, let’s use a story. Say you need to present your strategic plan for an overhaul of your site’s e-commerce experience to your executive team. You’ll need their buy-in before you can move forward and commit development and marketing resources to the project. You could walk into your discussion with a slew of data to back up your argument that your online shopping page needs an overhaul. Your shopping experience currently takes 45 seconds longer than the average site selling a comparable product. Your e-commerce page has been rated among the lowest of its kind by third-party review sites. Your shopping-cart abandon rate is 23% higher than the industry norm. And on and on. Some of your executives might even be persuaded — if the PowerPoint slides filled with charts and raw statistics don’t send them deep into thought about lunch. But now imagine that instead, you walk into your meeting and open with a story. It goes like this. “Our new marketing campaign catches the attention of Kirk, our primary persona and ideal customer. He comes to our site, spends a few minutes reading our blog… a few minutes more checking out our testimonials page, and then he….” (Note: At this point, your executives are likely all listening intently, interested to know what happens next with Kirk. Not one of them is daydreaming or making mental lunch plans.) “Finally, Kirk heads to the pricing section of our website. After a few minutes on that page, he clicks buy. Everything is working according to plan! “Kirk selects the most expensive version of our product, inputs his credit card information… and then four minutes later abandons his shopping cart. He also ignores our follow-up asking if there’s anything we can do to help him complete his purchase. “What happened?” Because you’ve introduced the discussion topic — your strategic plan to improve your site’s e-commerce experience — using an engaging story, told from the point of a customer, your executives are now ready to listen to your evidence. And because you’ve established the framework for your topic using a story that everyone in the room intuitively understood and related to, your evidence will carry far more weight with your stakeholders than if you had simply recited it without first putting it in context. Be Flexible Let’s say you’ve built your new product roadmap and have scheduled a one-hour meeting with your sales and marketing teams to run through it. You’re planning to start the discussion at a high level, providing a strategic overview of the product’s current position in the market and where you plan to take it with the new roadmap. Maybe you’re even planning to open with a story. These are all smart public speaking strategies. But a couple of sales executives who will be in the meeting tell you just beforehand that they’ll need to cut it short. Now you’ll have to deliver essentially the same talk in only 15 minutes, including QA. Or assume one of the sales executives catches you in the hallway and asks you to pop into an empty conference room and quickly explain your thinking behind the new roadmap. In other words, in this instance you’ll have to deliver the same talk in five minutes! As a product manager, you might be called on to discuss your product vision at length, or in just a few minutes; to a technical audience, or to a non-technical sales rep. Part of the value you bring to your company is the ability to quickly and persuasively articulate that information under just about any conditions. Keep Your Talks Positive Enthusiasm is contagious. So is negativism. That means as a public speaker, you have more power than you might realize to influence your audience’s perceptions and feelings about your topic. One of a product manager’s many roles is to serve as her product’s chief evangelist. So it is important that when you speak about your product in any context, to any constituency, you remain positive, and focused on moving forward to achieve your strategic goals. It’s easy in a product roadmap meeting or a scrum meeting to be taken off track and discuss past development cycles, or dwell on what went wrong with a previous release and who’s to blame. These detours almost never lead to any enthusiasm or positive feeling among the people whose hard work and dedication you will need to move the product forward. Because you are the person driving these meetings, you can implement a culture that guides your teams to focus on the positive. What’s more, as the lead speaker in many of these settings, you always have complete control over what you say. Another trait of great public speakers is that they stay positive and forward-looking — and, leading by example, they encourage similarly positive feelings among their teams. Conclusion: Public Speaking Ability is Essential to Effectiveness as a Product Manager You might not have been asked about your public speaking ability in your interview for any product manager position you’ve ever applied for. And you might never have given much thought to the importance of honing this skill just as you would the ability to understand technical jargon or read a profit-and-loss statement. But as you have probably found if you’ve spent any time in a product management role, it is difficult to make it through a week without having to do some form of public speaking — whether that means leading a meeting, presenting a product roadmap to one of your constituencies, or accompanying a sales rep to a customer site to talk about your product. Public speaking is a vital tool in the arsenal of any product manager, not to mention an invaluable skill to have in any area of life. So there is plenty of upside — and no downside whatsoever — in devoting time and energy to becoming the best public speaker you can be.

There’s no shortage of sage advice for product managers. However, all advice may not be the best advice. To rectify this, we’ve sifted through years of our articles, blog posts, and booksto provide you with the top six product management tips. These nuggets of wisdom—based on decades of experience in this unique profession—focus on what’s essential. While you might disagree with our curated list, we believe you will find at least one of our product management tips useful in your career. Our 6 Best Product Management Tips 1. Always take a collaborative approach Probably one of the most important product management tips is to take a collaborative approach. Each individual has a unique approach to accomplishing a task. They have different work styles, communication preferences, and opinions. Working with others comes with a host of challenges. Yet, though complex at times, those challenges bring a ton of value to the table, especially when working with engineering and design teams. In some organizations, the three-way relationship between the coders, designers, and product people may lead to teams challenging each other. Collaboration can help each team come to a consensus and find common ground. Contentious environments discourage innovation and risk-taking. Product professionals need to be aware that varying insights and ideas are available when everyone gets a voice. By welcoming stakeholders from different departments into the conversation, the product and its customers reap the rewards. From assessing an idea’s feasibility to unconventional user experience concepts, feedback helps the product team prioritize better. They can provide optimal solutions that encompass the ideas and solutions from both the engineering and design teams. The partnership often pays further dividends throughout the product development process as a closer and trusting relationship creates a more open and honest dialogue. Minor issues get raised and addressed before they become big problems when everyone feels like they’re on the same team. Watch our webinar below: 2. Be confident in your soft skills Product managers don’t necessarily need to be technical, but they need to work well with others. They have become adept at communicating with stakeholders, listening to customers, and developing empathy, which doesn’t come naturally. Developing your soft skills remains an essential product management tip. It’s essential to understand why these soft skills are imperative. Practicing and honing these things makes you a better product manager while simultaneously making your job easier. Listening skills Let’s start with listening. Addressing your customer’s problems requires a deep understanding of the issues they face. Though, it’s understandable that a lot of us dream about the prospect of reading our customers’ minds. Instead, you find out what really matters by talking to customers, asking them questions, and—most importantly—listening to what they have to say. The most successful product managers are active listeners who engage in follow-ups and have a general openness to customer feedback, which doesn’t come easily to everyone. Check your impulses, move into “receiving mode,” and take the feedback in with as open a mind as possible. Empathizing with customers allows you to feel their pain. By placing yourself in their shoes, you can evaluate and appropriately respond to their feedback. Communication skills Communication, of course, is a two-way street, so your listening skills should match your ability to convey information clearly. As a product manager, you need to understand their biases and assumptions when framing your message and deliver it via a method that will garner a response. Not everyone has the same communication style or prefers the same medium. The burden then falls upon you to tailor your communication based on the individual or group. The skills listed above merely scratch the surface when utilizing soft skills to improve your effectiveness and efficiency as a product manager. Serving as a product evangelist, facilitating stakeholder alignment, and leading prioritization exercises are a few other examples where these essential capabilities come into play. hbspt.cta.load(3434168, '83f51649-b6bd-42f2-9c45-d58c5fba5ca3', {"region":"na1"}); 3. Manage your own career A fatal flaw for any employee is to expect others to worry about their career development and progression. For this reason, we ranked “manage your own career” as one of our top product management tips. While managers and mentors may step up and take you under their wing, your boss may be solely focused on shipping products and keeping things under budget. Product professionals should always be mindful of their career path with no guarantee that anyone else will look out for their interests and invest in their future success. Successful product professionals build up their skills by getting the experiences they need to round out their resumes. Furthermore, they identify and pursue opportunities for growth and advancement. Product management professionals face additional challenges in advancing their careers because so much of what they do is behind the scenes. To bolster your image and get on the radar of hiring managers, use platforms such as all-hands meetings to promote yourself internally while participating in industry events to maximize networking opportunities and finding other chances to become a thought leader in your space. 4. Embrace visual roadmaps In the age of Agile, product managers don’t produce as many requirements documents. Our user stories reside in the tools of the product stack, and our insights get shared in standups and prioritization meetings. In turn, a scant “paper trail” of evidence of our hard work and an absence of documentation reviewed and referenced by stakeholders. Product roadmaps, however, remain the exception, and their importance has never been greater. Some product managers cram everything into their roadmaps since it’s the only documentation colleagues will see. Then again, the concept goes against the “less is more” rule of thumb, which guides everything product managers produce. Instead, leave out the details and allow visualroadmaps to be one of your essential product management tips. Themes tell the story, color-coding ties work items to desired outcomes and goals, and the focus remains on the items of strategic importance. And, when you use a purpose-built roadmapping tool such as LIKE.TG, you’ll spend less time creating and updating these visual roadmaps and be confident that stakeholders are always viewing an up-to-date version. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); 5. Don’t settle for a stale prioritization framework Figuring out what to build next and leave out is a key part of product management. To make it collaborative and incorporate multiple viewpoints and opinions, using prioritization frameworks for these exercises gets more folks involved and creates additional transparency to silence the naysayers. However, we live in the golden age of prioritization methods, so product teams shouldn’t stick with a framework that doesn’t truly fit their business. With dozens and dozens to choose from, each with its strengths and weaknesses, make sure you and your team are satisfied after using them. It can also help to shake things up now and then and try a new framework. Not only can it turn up some new insights, but it may also reinvigorate the entire prioritizing team by giving them something new. 6. Lead with IMPACT Our final top tip emphasizes prioritization differently. It’s a mindset universally applicable to every aspect of product management, from who you hire to what you work on to how you spend your time. Using a consistent lens, product teams can ensure they’re focused on what matters most by assessing how each potential item rates against these six fundamental aspects: I – Interesting: Does this address the things our customers care about? Can we tell a story of how we’re creating positive change for them? M – Meaningful: Are we moving the business forward toward measurably reaching its goals? Are we providing real value to our users? P – People: Who is impacted by this? Who uses it, who sees the benefits, and who pays for it? A – Actionable: Are we coming up with ideas that can be implemented and realized? Do we have the resources, budget, and expertise to execute? C – Clear: Do we truly understand what we’re trying to do? Can it be concisely articulated so even a child could understand? T – Testable: Can you try things out before committing? Are there ways to experiment and measure success on an ongoing basis? Keeping IMPACT top of mind helps everyone maximize the value they’re creating and keep their eyes on the prize. Download our free ebook to explore how to incorporate it into different facets of your work and career. Looking for more pointers on excelling in product management and other product management tips? Visit our Learning Centertoday.

As a Customer Success Manager at LIKE.TG for the past two years, I’ve worked with hundreds of our customers on establishing their roadmapping processes. Throughout my time with LIKE.TG, one of the most common roadblocks I see inhibiting a successful roadmap process is a lack of accountability on roadmap editors. 6 Ways to Create Roadmap Accountability with Your Team So, you’ve invested in a standardizable roadmapping tool for your team. That’s a great first start, but how do you ensure that they actually update their roadmaps? As you build out your roadmapping process with your team, the tips below will ensure roadmap accountability. 1. Establish a Champion of the process An essential part of creating accountability is establishing one or more persons as responsible for the outcome. This person can be an executive sponsor or a champion of the process appointed by the team. The champion must set expectations, goals, and guidelines for success with the Roadmapping Process. Setting expectations early on in the process is essential. However, without a champion to hold the team accountable, they will be ineffective. The champion can also continuously evaluate whether they’re meeting the goals of the roadmapping process. If so, then champions have fodder to provide the team with ongoing motivation. Whereas if the team is not meeting goals, having a champion to shepherd a change in the process is key. Build a Visual Product Roadmap ➜ hbspt.cta.load(3434168, 'a81908bd-d7dd-4be2-9d7e-cb09f3f90137', {}); With LIKE.TG, the champion of the account typically has admin rights to the account. It gives the user the ability to see each team member’s last activity as well as a list of roadmaps created by each member of the team. It’s an efficient way to verify editors are meeting expectations and following guidelines. The team’s champion also plays a critical role as the liaison between the software and the team. As a Customer Success Manager, I’ve worked with several teams that lacked a clear and established champion of the tool. These are the most common outcomes I see in response: users don’t end up using the tool in the first place, or they start using it but without direction and not following best practices—which causes frustration and ultimately leads to non-use, as well. More often than not, these accounts end up reverting to whatever the inefficient process was they were trying to move away from and end up back at square one. 2. Start with your “Why?” Realistically, not many people like being told to do something blindly. An essential step for getting any team invested in the roadmapping process is communicating the why behind it. Start at a high level; why does your team need to implement a new process? What challenges are you looking to solve for the team? Then move towards the specifics, why did you choose the tool you’re asking the team to use? If your team evaluated multiple tools, it could be valuable to share the criteria your team was looking for and how the tool you selected stacked up. Switching to a new tool or implementing a new process is always going to require some manual effort, understanding the why behind it is essential to motivate users to put in that effort. Understanding a team’s “why” is also critical for me to help, well, manage a Customer’s success. Every team has different goals they are trying to achieve with their Roadmapping process. Establishing those goals at the beginning of the process gives the team something to work towards and gives both you and your Customer Success Manager something to measure against. If I don’t know what your idea of success is, how can I help you get there, and if your team doesn’t have an idea of what success looks like, how do they know that the work they’re putting in is worth it? 3. Team-wide roadmap sharing One of the most important ways to ensure roadmapping success is to keep the process collaborative. One easy way to do this is to encourage users to share their roadmaps right away. Often a user’s gut reaction is to keep the product roadmap hidden until the final draft. While this might work for a static PowerPoint slide, a live roadmap will never be finalized. Roadmaps are continually evolving, sharing your roadmap from the start will give your audience context to its development. Knowing that your roadmap might be viewed at any time will help foster an environment where Editors update their roadmap on an ongoing basis rather than only before a big presentation. The importance of sharing roadmaps early on clicked with me while working with a group that was entirely new for roadmapping. I scheduled a call with all of the Editors of this group a few weeks after their first training to make sure there weren’t any lingering questions and hear how the roadmapping process was progressing. When we got on the call, my questions were met with an awkward silence because, as it turns out, no one had touched their roadmaps since our last call. When I asked why the users admitted they didn’t know when they were supposed to have their roadmaps ready, so they didn’t work on them. By sharing your roadmap at the beginning, there’s no concept of a roadmap deadline, so updates stay an ongoing habit. Luckily LIKE.TG and most roadmap software include a team-wide sharing functionality that grants roadmap access to your entire team as quickly as one click. As an easy way to ensure roadmaps are being shared throughout the roadmapping process, encourage users to share new roadmaps with the team upon creation. 4. Implement a cadence for roadmap presentation Setting up a recurring roadmap meeting or designating time in a pre-standing meeting for roadmap updates can be an effective way to give users a sense of urgency to update their roadmaps. In an ideal state, roadmap editors are regularly updating as work items progress or change. Unfortunately, though, this is not always the case. Devoting a recurring time to the roadmap presentation will create a baseline cadence for updating. Some of the larger companies I work with establish bi-weekly roadmap forums where the team can get together and go over their roadmaps, talk about what’s working and what isn’t, and discuss updates to the process. One champion mentioned to me that this was the key to establishing standardization in their roadmapping process because it allowed them to quickly identify users who weren’t following the guidelines as they presented their roadmaps. A built-in presentation mode makes pulling your roadmap up during a meeting easy. We recommend sharing your roadmap live during these meetings so that it remains interactive. With a live roadmap, you can present in differing granularity levels, dig deeper into any items you want more detail on, and adapt as necessary. 5. Utilize integrations Keeping editors motivated to update their roadmaps is an easy way to keep editors by making the process as simple as possible. One of the most valuable ways the roadmapping process can be simplified is through the use of integrations. Nobody wants to be doing redundant work, the goal of Roadmap integrations is to make getting information that has already been created elsewhere into your roadmap with ease as well as keep it updated with no manual effort. The more places a user has to update information, the more opportunities arise for something to fall out of date. Why not only worry about updating information once and have that carry over to your roadmap? For example, LIKE.TG integrates with several Project Management Softwares: Jira, Trello, Azure DevOps, and more. Use these integrations to import items directly into your roadmap, making it possible to build an entire roadmap within minutes. Syncing your roadmap automates the process of keeping your roadmap updated. It removes the burden of tedious updates from your editors, leaving them time to focus on the big picture of the roadmap. Integrating your roadmap simplifies the process for editors, but it also helps to establish your roadmap as a source of truth by creating less opportunity for error. 6. Regular account reviews with your Customer Success Manager Okay, I might be a bit biased on this one, but hear me out. It’s your Customer Success Manager liaison’s job to help your team establish and maintain a successful roadmapping process. The best way we can help your team maintain success is through account reviews. These are a way for us to touch base with the champions and perform a pulse check on the account. We’ll ask the team leads to gather feedback from both editors and roadmap viewers; this will tell us where the process is working and also help identify any areas for improvement. We’ll also take an in-depth look at the team’s usage with the champions. We’ll uncover what features to utilize or not and any patterns in team use. Together we’ll analyze the overall account health and compare the current process to the goals. While reviewing guidelines set at the beginning of on boarding, we’ll see where they are being met or falling short. It helps us develop the next steps for training, but it will also equip the champion with concrete usage metrics that they can bring back to the team to foster accountability. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); Takeaways Getting your users to adopt a new roadmapping process isn’t as simple as buying a shiny new tool. However, with the proper structures in place, getting your team to update their Roadmaps doesn’t have to be like pulling teeth. Best of all, with LIKE.TG, you don’t have to do it alone because that’s what I’m here for. Ready to build your own roadmap? Get started with a free trial.

The year 2020 shifted the world in fundamental ways. It changed the way we work, learn, play, travel, and socialize. It catapulted some industries into dominance (video conferencing, food delivery) while decimating others (hospitality, tourism). In fact, 2020 brought us so many shocks and surprises that it made identifying top trends in product management more challenging than ever. This year conditioned us to the reality that industry, a nation, and even the world can change overnight. How can we predict the future with any confidence? Will our governing systems change in light of new threats to world health? Will a vaccine eradicate COVID-19? How long before we can attend a public event without wearing a mask? Who knows? As a product leader, entrepreneur, and product management author, I have paid close attention to the product community throughout 2020. My team at LIKE.TG has worked with hundreds of product professionals this year. We’ve gained an understanding of how the pandemic has affected their goals, concerns, and plans. We even recently released our 2021 State of Product Management report where we learned what the #1 thing product managers hope changes in their role in 2021 (hint: it’s not a higher salary). Here are a few top trends in product management I’ve seen and that I’m predicting will continue through 2021 and beyond. 5 Tops Trends in Product Management for 2021 1. Distributed product teams will be the new normal. I anticipate that the world’s health experts will bring the pandemic at least somewhat under control in 2021. But one temporary consequence of the 2020 lockdowns—remote work—will become a permanent part of the culture for millions of organizations. After talking with hundreds of product teams throughout the year, I sense that many companies will adopt a hybrid model of remote and office work. There are strong business reasons for this: It allows organizations to find the best product talent anywhere. With an office-bound culture, a business limits itself to the best staff it can find within a reasonable commuting distance from its building. Without the artificial limitation of hiring people only in the company’s geographic location, the business opens its pool of viable candidates to the best talent available anywhere in the world. This gives an organization the ability to build a world-class product team. It makes an organization a more appealing place to work. Many product professionals worked from home for an extended period in 2020 for the first time in their careers. A lot of those professionals realized both that they can remain highly productive and creative working remotely—and that they love it. Businesses caught on to this as well. By allowing more flexibility in both when and where their employees work, an organization can attract and keep better people on their teams. It can lower an organization’s fixed costs. Another common theme my team and I heard during the 2020 lockdowns were our customers re-examining their office real estate. Many found that if they implemented the hybrid model of remote and onsite work, they could downsize their office space and lower their real estate costs. With more employees interested in working at least part-time from home and businesses are discovering they can reduce their overhead with a smaller office footprint. The remote-work trend will become the new normal. 点击播放声音 @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; } 1:02:52●●●●●●●●●●●●Meet the PanelToday's AgendaAre you currently working from home?Our Remote AwakeningsAre you temporarily working from home, or do you always work from home?Remote Work Best PracticesRemote Key TakeawaysWhat tools do you use to create sources of truth?Managing AlignmentHow effective is your team's communication?Staying Connected and Having FunLive QA #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset{font-size:14px;} #wistia_chrome_23 #wistia_grid_57_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_57_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_57_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_57_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_57_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_57_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_57_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_57_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_57_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_57_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_57_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_57_wrapper a.w-css-reset{border:0;} #wistia_chrome_23 #wistia_grid_57_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_57_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_57_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_57_wrapper p.w-css-reset{margin:1.4em 0;} #wistia_chrome_23 #wistia_grid_57_wrapper a.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_57_wrapper span.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_57_wrapper svg.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_57_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_57_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_57_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_57_wrapper ul:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_57_wrapper ol:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_57_wrapper li:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_57_wrapper ul:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_57_wrapper ol:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_57_wrapper li:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_57_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_57_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_57_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_57_wrapper .w-css-reset button::-moz-focus-inner{border: 0;} #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset-tree {font-size:14px;} #wistia_chrome_23 #wistia_grid_57_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_57_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_57_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_57_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_57_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_57_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_57_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_57_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_57_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_57_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_57_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_57_wrapper .w-css-reset-tree a{border:0;} #wistia_chrome_23 #wistia_grid_57_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_57_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_57_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_57_wrapper .w-css-reset-tree p{margin:1.4em 0;} #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset-tree a{display:inline;} #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset-tree span{display:inline;} #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset-tree svg{display:inline;} #wistia_chrome_23 #wistia_grid_57_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_57_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_57_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_57_wrapper .w-css-reset-tree ul:before{display:none} #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset-tree ol:before{display:none} #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset-tree li:before{display:none} #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset-tree ul:after{display:none} #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset-tree ol:after{display:none} #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset-tree li:after{display:none} #wistia_chrome_23 #wistia_grid_57_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_57_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_57_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_57_wrapper .w-css-reset-tree button::-moz-focus-inner{border: 0;} #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset-max-width-none-important{max-width:none!important} #wistia_chrome_23 #wistia_grid_57_wrapper .w-css-reset-button-important{border-radius:0!important;color:#fff!important;} Complete the form to access the full webinarFirst Name*Last Name*Job Title*Email*LIKE.TG is committed to protecting and respecting your privacy, and we’ll only use your personal information to administer your account and to provide the products and services you requested from us. From time to time, we would like to contact you about our products and services, as well as other content that may be of interest to you. If you consent to us contacting you for this purpose, please tick below to say how you would like us to contact you:I agree to receive other communications from ProductPlan.In order to provide you the content requested, we need to store and process your personal data. If you consent to us storing your personal data for this purpose, please tick the checkbox below.I agree to allow LIKE.TG to store and process my personal data.*You may unsubscribe from these communications at any time. For more information on how to unsubscribe, our privacy practices, and how we are committed to protecting and respecting your privacy, please review our Privacy Policy.#wistia_grid_57_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_57_wrapper *{-moz-box-sizing:content-box;-webkit-box-sizing:content-box;box-sizing:content-box;} #wistia_grid_57_above{position:relative;} #wistia_grid_57_main{display:block;height:100%;position:relative;} #wistia_grid_57_behind{height:100%;left:0;position:absolute;top:0;width:100%;} #wistia_grid_57_center{height:100%;overflow:hidden;position:relative;width:100%;} #wistia_grid_57_front{display:none;height:100%;left:0;position:absolute;top:0;width:100%;} #wistia_grid_57_top_inside{position:absolute;left:0;top:0;width:100%;} #wistia_grid_57_top{width:100%;position:absolute;bottom:0;left:0;} #wistia_grid_57_bottom_inside{position:absolute;left:0;bottom:0;width:100%;} #wistia_grid_57_bottom{width:100%;position:absolute;top:0;left:0;} #wistia_grid_57_left_inside{height:100%;position:absolute;left:0;top:0;} #wistia_grid_57_left{height:100%;position:absolute;right:0;top:0;} #wistia_grid_57_right_inside{height:100%;right:0;position:absolute;top:0;} #wistia_grid_57_right{height:100%;left:0;position:absolute;top:0;} #wistia_grid_57_below{position:relative;} 2. Product leaders will become more effective. Based on my interactions with product leaders throughout the COVID-19 lockdowns, I believe 2020 triggered in the product profession a phenomenon known in the physical sciences as stress-recovery-adaptation. Developed by a medical doctor and researcher, Hans Selye (pronounced “say”), this theory argues that when we’re exposed to a stressor, we go through three stages. There’s the fight against the stressor, a recovery period after that fight, and a general adaptation that makes us more resilient against similar future stress. (This is the process we go through during and after physical exercise that makes our bodies stronger.) The pandemic forced everyone to adapt quickly to many new threats against their organizations. These stressors included the lockdowns, the sudden and forced transition to remote work, financial pressure on their businesses, and sudden changes to their customers’ priorities and demands. From what we at LIKE.TG witnessed during this time, many product leaders handled these external stressors with intelligence, patience, and compassion. They accepted—even embraced—the uncertainty. Product leaders trusted in their teams and strategically went about building new processes that would work under these rapidly changing circumstances. I believe product leaders have already begun to adapt successfully to the new realities of a post-pandemic world. In the future, I foresee product leaders running their teams more effectively and successfully as a result. They’ve undergone an enormous stressor. They’re recovering from that struggle. And they will emerge stronger from it. If you’d like to delve more deeply into crisis leadership strategies, I recommend this article from LIKE.TG’s Chief Executive Brad Wills: A CEO’s Tips for Resilient Leadership During Challenging Times. 3. The essentialist product management movement will grow stronger. When your house is on fire, you don’t run to the closet looking for your box of multi-colored paper clips. Your mind homes in on what matters—people, pets, photos, etc.—and ignores everything else. This year left people feeling overwhelmed with level-one priorities. Many had to adapt to new working arrangements. Many others lost their jobs or businesses entirely. Parents had to manage children learning from home for the first time. And everyone had to figure out how to adjust their lifestyles to protect themselves from a worldwide viral pandemic. In these chaotic times, many people began cutting away the things that didn’t matter so they could focus on the ones that did. This is essentialism, and it’s a useful approach for living a more productive, balanced, and fulfilling life. Product managers, in particular, are vulnerable to overwhelm. They’re constantly putting out fires in their organization. They have so many responsibilities, so many teams, and projects to coordinate that they can fall victim to worrying about everything equally—even those multi-colored paper clips. What I’ve seen repeatedly throughout 2020 is product professionals realizing the need to narrow their focus. The crazy events of the year forced them to de-prioritize all but the projects that could truly move the strategic needle for their products and their businesses. Many product managers and leaders have adapted by: Focusing on their product’s highest purpose Creating space and time for thinking Saying no when necessary Doing less, but better. As a longtime technology product manager, I’ve experienced firsthand how effective the essentialist approach can be. That’s why I expect this trend to gain more traction through 2021. Download The Essentialist Product Manager ➜ hbspt.cta.load(3434168, 'be753440-dc4d-40c5-9808-cad744d00a28', {}); 4. Diversity awareness and action will increase. Successful product teams don’t exist in a vacuum. They are a part of their larger society. Smart product leaders were paying close attention in 2020 to the changing cultural and political climate. If they hadn’t already made a material effort to create a corporate culture fostering diversity, collaboration, and integrity, these organizations must have realized that this was the year such policies became must-haves. The civil unrest in dozens of cities around the country, primarily emerging out of protests against systemic racism, made diversity and inclusion top-of-mind for many product teams. This was true even for organizations that had already prioritized building diverse teams in the years leading up to 2020. But based on what the LIKE.TG team has seen firsthand in working with product teams in all industries around the world, I anticipate these noble goals becoming even higher on product organizations’ priority lists for 2021. You can see what product professionals had to say about diversity at their organizations in our 2021 report. hbspt.cta.load(3434168, '35d36a84-b157-43a1-acb7-b972dcb1d1ad', {"region":"na1"}); 5. Product teams will re-examine and update their strategies. A product strategy that would have been effective in the 2018 world might fall short in 2021. For reasons, the product team could not foresee when they developed their strategy. For example, a B2B software product sold only through a long-term subscription might have been wildly successful in the booming-economy days of 2018 and 2019. But by 2020, the product team overseeing that business app might need a new pricing model to accommodate its customers’ post-pandemic fears of committing to long-term expenses. An ingenious COVID pivot: One small but brilliant example of a product team that adjusted its strategy in light of COVID was a company that manufactures hollow, plastic eggs that parents can fill with toys or candy for Easter egg hunts. The lockdowns went into effect in mid-March 2020 for most of the world, just weeks before Easter Sunday. Of course, egg hunts all over the world were canceled. But the product team hit on a great idea. They recolored their eggs from traditional Easter tones (light blue, yellow, pink, light green) to a black and orange that showed up under a blacklight. Then they marketed their new product as eggs that would be perfect for a “Halloween hunt.” Throughout 2020, many product teams found themselves playing defense. They had to react to major disruptions to their businesses, their markets, and their employees’ personal lives. As I’ve noted throughout this post, I think many product teams have done an admirable job of adjusting to a chaotic situation. But as we head into 2021, I’m confident these teams will become increasingly proactive. They’ll be taking an objective look at their pre-COVID strategies. Examining them against new realities and updating their plans to ensure they can continue to deliver outstanding products that solve real market problems in a post-pandemic world. If you’d like ideas for creating a winning product strategy, even in the challenging period we’re living through now, I recommend the book written by our Vice President of Product, Annie Dunham: hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {});

The most successful products I’ve been involved within my career came about when the entire cross-functional team opened the door to the mission at the same time, with similar expectations, and on equal footing. In other words, these teams started together. Not in organizational silos. Not with each individual immediately going off to work on different aspects of the project. Together. To explain why I believe starting together is so important for a business team, let me tell you a story about the music career I had before entering product management and UX. What does starting together mean, and why is it so valuable for cross-functional teams? In my 20s, I toured with a rock band. Just as we were about to launch our first national tour, our lead singer developed voice problems. (Coincidence? Who knows?) Download the Anatomy of a Product Launch ➜ hbspt.cta.load(3434168, '0edb2611-2761-4434-90b0-f055704d9daa', {}); We canceled upcoming shows so our singer could get medical treatment and voice coaching. While he was away, the rest of the band had to camp out in a run-down hotel room. All six of us, one room. When he returned, our singer was stressed—about his career, about doing the vocal exercises his coach prescribed, about making sure we kept the hotel’s humidifier full of water so his throat wouldn’t dry out. And after waiting in that smelly room for our singer’s return, the rest of us were stressed as well. As you can imagine, this led to frustration and conflict. The band had functioned as a single unit up to this point, and that cohesion and chemistry led to our national tour bookings. But now, because of this disruptive experience, we were no longer starting together. We were heading into our new tour not as one unit but instead with an “us-versus-him” dynamic. So, what exactly do I mean by starting together? Do you know those movie scenes where the band of imperfect heroes walks into the haunted house, or the cave with bats, or the scary room? It’s that shared experience of the entire team opening the door, all wondering at the same moment, “What’s in here?” The point is, we’re all in this thing together, and we’re going to make the same mistakes together, too. The benefits of starting together can be enormous for a product team, or any team. Think of all the wonderful things that happen when people grapple with a problem together, where everyone on the team brings their unique perspective to a shared challenge. What does not starting together look like? Another way to understand the value of starting together is to think about what happens when you don’t. Think of the lone UX researcher spending months getting ahead of the team, doing interviews solo, testing prototypes solo, etc. You might also recognize the not-starting-together approach as a team holding lots of status meetings, assigning individual tasks, and occasionally gathering for small brainstorming sessions. On the surface, that might look like teamwork. What’s really happening day to day, however, is that all of these team members work in silos on their to-do lists. Not until the last moment, when they have a near-finished product, will this group come together as a cross-functional team. Is your organization failing to create a starting-together culture? Here are some questions to ask yourself and your team, to help spot the signs that you’re fostering a culture of not starting together: Do you allow individuals to spend a lot of time isolated from the team because they’re busy and have a lot of tasks to complete? Do some of the people on your cross-functional team like to go off and work alone so they can “get ahead” of a new project, and bring an airtight case to the team? Do you find that your team does a lot of backtracking and re-planning because various members weren’t on the same page about the mission? If you recognize any of these scenarios, you might want to step back and think about how you can adjust this culture to create a safe environment for doing the messy but valuable work of starting together. The value of working together The benefits of a together culture don’t end after the team starts a project, either. That team needs to keep working together beyond the kickoff, the design sprint, the spike, or whatever the initial event is. Remember, working together does not mean providing status checks or reporting to stakeholders. It also doesn’t mean individuals working in parallel toward the same goal. That’s not working together—it’s working as many teams of one. Working together involves: Occasional pairing of members in different areas of a cross-functional team Swarming as a team on impediments Bringing the whole group to the whiteboard to brainstorm or solve issues Continually making sure the entire team is having a shared experience of making progress toward a common goal I’ve experienced firsthand the many benefits of working together in this sense. Product management learns an enormous amount from engineering. Engineering gets a much better understanding of why product management prioritizes initiatives the way it does. Design and development gain fresh perspectives and improve each other’s work. Team members build bonds, trust, and concern for each other. They develop a shorthand language that speeds things up and makes everyone more efficient. The list here could go on for pages—and the end result, in many cases, is a much better product. The importance of finishing together Finally, what does it mean to finish together, and why is this important for your team and your company’s success? Product and service companies don’t experience many clear moments of “finished.” Sure, the work crosses the kanban board from left to right. Maybe it even reaches a column on the far right called “Done.” But done in this sense doesn’t mean the same thing it means at the end of a movie, where we all know it’s time to stand up and walk out of the building never to come back for that movie again. For a cross-functional product team, finished probably means something more like, “We don’t need to think about this for while” or, “Wow. That was hard. We can breathe a sigh of relief now.” Another reason done rarely means done in a business is that your product team’s “finished” might represent another group’s start—a team that now has to support the product you’ve just released. (Let’s hope that this support team is starting together!) For a cross-functional team, then, finishing together can mean the team has had the shared experience of working on a project long enough to generate an outcome the group feels proud of. And now, instead of just handing off the work to the next group, that team can fold those people into the larger mission and support them. In other words, finishing together involves a team finding a shared sense of closure at a given stage of the cross-functional team’s work. Then, understanding that in our line of work we’re never really “finished” with our projects, the team can continue working together to find ways of helping the rest of the organization fulfill its mission. A few ideas on creating a cross-functional, finishing-together culture I’ll leave you with some questions you can ask to start fostering a company culture of finishing together. I hope you give this approach a try. Starting, working, and finishing together can yield big benefits to any professional team. How are we helping our teams not get lost in the whirlpool of work, as efficient as that task-driven approach might be? How do we make shifting to a new project something to celebrate without the nagging guilt of leaving a bunch of debt in the product, or a booby trap for the next team? And how can we keep the gang together as much as possible, so they can finish and celebrate each success together? hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});

Product managers are also problem managers. Crashes after a new version launch? It happens. Users dropping off after initial download? That happens too. Rather than waiting for problems to arise in aggregate and then fixing them, you can take a proactive approach. This means tracking usability, UX, and performance issues as they happen to individual users. With the proper strategies and analytics tools, you can quickly track and fix issues while they’re still small. Today’s article will arm you with analytics hacks for product managers to solve key issues in your application early on. 1. Use session recordings to correct crashed sessions It’s a fact of life app-making: Crashes happen. When they do, your users will always be affected to a certain degree. Whether a crash affects just a handful of users or many is ultimately up to you and your team. One way to keep this in check is by monitoring and fixing crashes in real time, before they turn into high churn rates and negative reviews. Maybe the crashed sessions have only happened a few times on a specific screen, but these “few times” can quickly turn into “many times.” And these “many times” on one specific screen just might begin to affect other screens, too. What happens once or twice may start happening more frequently to more users. This could spell disaster, especially if you’ve just released a new version. Furthermore, when and why are these crashes occurring, and what is the effect of these crashes on user satisfaction? If you’ve noticed a sudden (but small) spike in crashed sessions, it may be time to take action. How to use analytics to monitor application crashes Most mobile product teams have crash logs and general crash rates but no visuals delving into the reasons for the crashes. If they want to see the crash for themselves, they have to recreate it. If mobile apps teams could simply view crashes as their users do, instead of having to recreate them, they can reduce both dev/QA hours and the risk of unhappy users. So how can you effectively do this in practice? Some mobile app analytics tools support things like user session recordings and allow you to replay real sessions. Tools like this can help product teams deal with crashes effectively and immediately. By watching session recordings of crashed sessions, teams can see exactly at what point the app crashed and what user interactions led up to the crash. Maybe the payment screen crashed just after visiting the cart, or perhaps the payment screen crashed after a different series of events. 2. Improve retention rates with action cohorts Retention, retention, retention is the prized pig we all want to win. For product managers of mobile apps, retention KPIs, such as time between sessions or percentage of returning users per timeframe, are some of the most important metrics to mind. One of the best ways to understand where, when, and why drop-offs are happening is action cohort analysis. Action cohorts analyze groups of users who performed a common action (or series of actions) during a specific timeframe. By performing an action cohort analysis, you can identify patterns in your users’ behavior, pinpoint improvements that will have the most dramatic effect, and gain valuable information about how one action relates to another action. Action cohort analysis in action Perhaps you want to assess your users in terms of follow through. You can use a cohort analysis to identify users who do not continue to a second session (perhaps within a given week or month), or to track whether or not users return for a second session to sign-up or login. This not only says something about users’ intent, it also gives insight into your app’s stickiness, and last but not least, allows you to be proactive in understanding your users’ behavior. 3. Upgrade user engagement with touch heatmaps Engagement metrics can come in many shapes and sizes, depending on the app category/type of app you manage. You may track user engagement metrics like DAU (daily active users), daily app launches, and churn rate. But these metrics, only take you to a certain point in analyzing users in your app. Why is it important to go beyond these metrics? At the end of the day, your users are human, and their behavior and interactions with your app can’t be explained by numbers alone. One way you can get deeper insight into the humans using your product is right at your fingertips, or rather, your users’ fingertips: their gestures. Each tap, swipe, and pinch your users make give you precise insight into user preferences and tendencies throughout their journey. To mine your users’ gestures for actionable data, you can look for an analytics tool that supports touch heatmaps. Touch heatmaps provide you with a full picture of all your users’ gestures, by coloring the areas of each screen according to the level of interaction they receive. You’ll see what features are the most popular, what elements grab users’ eyes, where they encounter frustration, and how they navigate their way through your app. Why is this important? As previously stated, engagement is quite nuanced, and there is good engagement as well as bad engagement. Sometimes users will engage in a way that is not preferred, for example with a part of the screen that does not aid a user journey. There is also good engagement, which means that your UI is appealing and satisfying to your users. Touch heatmaps will also show if users are engaging in places that are not “engage-able” like tapping on an image that looks like a tappable button, which could demonstrate that there is a flaw in the UI. Conclusion If you’re sitting idly by, waiting for user feedback or for a major UX issue to appear… don’t! Be proactive, and take charge of your app and your users. Start using the above metrics and tools to better monitor your product and easily iron out any usability and performance issues.

As we head into a new year, we tend to talk more about gratitude. We talk about what we’re grateful for in our own lives, and often express gratitude for the friends, family, and coworkers we have around us. We’ve tried to foster a culture of “thank you” at LIKE.TG. And lately, I’ve thought a lot about what gratitude means for the people we work with. Today, I’d like to share a bit about the role of gratitude at ProductPlan. Hopefully some of these thoughts might help you at your workplace. I’d like to say that there’s some magical formula for fostering a grateful culture within your organization, but there isn’t. A culture of gratitude, or a culture of thank you doesn’t materialize on its own. Our culture at LIKE.TG is the result of consistency in our values and decision-making from the very beginning. We wanted LIKE.TG to be a place where people genuinely enjoy coming to work; a place where people feel that they are contributing towards something important. We wanted our team to see the significant ways they help build great products and we wanted them to enjoy working with our customers and with each other. Gratitude and appreciation are key to creating the environment we set out to create from the get go. I’ll discuss how we did this shortly, but first let’s look at why. Why does gratitude matter? Why is it something we should all strive for? Let’s see what science has to say. The Science of Gratitude To start, what exactly is gratitude anyway? Gratitude, to me, means taking a moment and recognizing the good things that we have and the good things that other people are doing. It sounds easy right? But if we look closer, there are actually a few different ways in which we interact with gratitude. We can feel grateful, we can express our gratitude, and we can receive expressions of gratitude. Various studies over the past century or so exploring our different reactions with gratitude have revealed multitudes of benefits of gratitude in the context of both health wellness and social . For example, feeling grateful not only increases life satisfaction but also one’s willingness to help others. And, the act of taking time to express gratitude is a proven mood-booster. The Importance of Gratitude at Work My co-founder Greg and I both have previously worked with enough teams and at enough companies to recognize what it feels like to operate in organizational cultures that lack a sense of appreciation. It’s not surprising that research shows our perceptions of gratitude in the workplace can be fairly complex. A recent study on US Americans’ relationship with gratitude found the majority of people wish they were thanked more often at work. Meanwhile, that same study found that the office is the place where people are least likely to express gratitude. So let’s break that down: employees feel that they should be appreciated more, yet don’t feel that they should verbalize their appreciation for others at work. Yikes. We strive to foster an environment in which everyone not only feels appreciated, but also freely expresses their gratitude to others. Initially, this was the product of our belief in practicing the golden rule “treat others as you’d like to be treated.” But, beyond simply being the right thing to do, we’ve also noticed many other positive benefits of our culture of gratitude. Gratitude Keeps our Team Motivated In the office, I see and overhear people doing small things for each other every day; helping them on something, picking up the phone to help someone who is away, volunteering to take on extra work to help out a colleague who already has a full schedule. It’s wonderful to witness this. It’s exactly the sort of environment that I want to create. We never hear someone say “that’s not my job!” but quite frequently hear “how can I help you out?” When you’re on the receiving end of an expression of gratitude, you feel appreciated and that your work is being recognized. But beyond those emotions, researchers found that people who are thanked for their efforts are driven to work harder and volunteer to help more in the future. So if you want to motivate your team, don’t forget to take time every now and then to thank them for their efforts. It doesn’t take much, but your sentiments can go a long way. Gratitude Improves Relationships and Encourages Collaboration In addition to keeping our team motivated, gratitude plays a role in promoting better teamwork. Sharing our appreciation with the team has encouraged them to do the same amongst each other. I hear it all the time in the office. And while knowing gratitude is present is reward enough for me, there’s an even bigger upside for the team as a whole. Gratitude exchanges among colleagues are proven to positively impact prosocial behaviors. Those who feel and express gratitude to colleagues are more motivated to spend time with others and work on improving the relationship. Meanwhile, those who are thanked for their work are often more willing to broaden the scope of the help and support they offer others at work. Something as simple as hearing a colleague say, “hey, thank you for helping me out with this project,” can promote closer collaboration and teamwork. Receiving Gratitude Reduces Likelihood of Burnout We care deeply about the health and wellness of our team at ProductPlan. And that’s another reason gratitude is important for our culture. In addition to motivating and driving collaboration, when people feel appreciated, they are less likely to experience burnout. Software startups and other fast-paced organizations are notorious for having high rates of burnout amongst employees. We don’t want that, and it turns out gratitude helps. A 2015 study found nurses (one of the professions with the highest burnout rate) who received expressions of thank you from patients were significantly less likely to experience burnout than their peers who did not. This is not surprising. If our work benefits others, we want to know about it and feel valued by them. But what is surprising is how little effort it takes to show people they are valued. Taking just a few moments out of every day to express your appreciation can make a huge impact on your team’s happiness and employee retention. Don’t pass up gratitude at work. There’s no doubt that there are countless benefits of gratitude at work. But in fast-paced environments, it can easily slip off the radar. So let’s look at how to avoid that by diving into how exactly we can make gratitude part of the employee experience. How We’ve Fostered a Culture of Gratitude at LIKE.TG Part of our success in fostering a culture of gratitude is arguably due to our motivations for founding ProductPlan. Greg and I founded LIKE.TG because we like to build products and solve problems. We didn’t get into the business of product roadmapping software for ego-based reasons. Of course we saw value in improving product roadmaps, but we founded LIKE.TG largely because we saw a fun and interesting opportunity to create something. But there was more to it than a motivation to have fun and a few well-timed thank yous. Here’s a few of the ways we’ve established and maintained a culture of gratitude at ProductPlan. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); Make Gratitude a Habit Everybody is busy and everybody has their own experiences. Sometimes we can feel completely overwhelmed at work, and to top it off we all also have personal lives too. When we have all these things going on, it can be hard to come up for air and recognize how good we truly have it. So, I think it’s important to make gratitude a habit. And by this I mean, making time to step out of yourself to be aware of what’s happening right now. If you’re stressed at work, it can be as simple as remembering that you have a job to stress you out in the first place. And beyond that, there are most likely other people around you going through the exact same thing that you are. Why not be grateful and appreciative of them? Get in the habit of taking moments of time to yourself for gratitude. Step away from the chaos for a moment, and you’ll give yourself a better opportunity to recognize the good things happening. You don’t necessarily have to start a gratitude journal or meditate to do this, the separation alone is often enough to get you thinking. I like to go for walks around the block; getting a little exercise and breathing fresh air helps me remember and appreciate the good things. Sometimes it’s hard to get the blocks of time for this habit. What works for me is making it part of my daily routine. There’s this tendency for many people to sit there and work while eating lunch at their desks. And that’s ok, but I still think it’s important to take breaks to get you outside and into a different headspace. That’s why I love to take advantage of my lunch break for this. Pay it Forward “Actions speak louder than words” they say. And that applies to gratitude in some ways as well. Leadership plays a significant role in an organization’s relationship to gratitude. My first job was a very typical corporate job where you walked in and there were rows upon rows of desks. I was just out of college and eager to learn. Productivity was of the utmost importance at this organization, so I worked hard. Certainly people said “thank you,” here and there, but I see now that something critical was missing: the culture didn’t value people or support helping them grow. I, like many others, was simply a cog in the wheel of this 40,000 person company. My career and happiness did not matter to them. I think everyone with enough years in the workforce has been somewhere like this. Even in larger organizations, a lot of this culture has to do with management and how they approach things. It is possible to foster this culture at a large organization if management consciously commits to it. For us, it’s common sense: our team’s success is directly correlated with our own. We truly value each individual on our team. After all, we couldn’t possibly be successful without them! So, management is on board to support every member of the team in not only getting the experience they want, but also in general being happy in their career (even if this means eventually they’ll take their talents to somewhere other than LIKE.TG). This is just one way we put gratitude into action here. Hire the Right People As we’ve grown, we’ve hired a lot. And we look well beyond talent and experience when we hire. A big part of building our culture is hiring genuinely kind people who share our values. For us gratitude is not a tactic, it’s a philosophy. It’s the golden rule: treat others as you want to be treated. “Thank you” should not come with ulterior motives. We don’t express gratitude because we want somebody to do something. This sort of manipulative pseudo-gratitude isn’t how we operate here. We say thank you because we genuinely care and want the people around us to be successful. And we hire people who bring that same philosophy with them to work. But how do you make hiring decisions that help us continue driving this culture? It can be tricky to suss this out completely during the interview process. Sometimes the version of someone you meet in an interview is not the same as the one who comes into the office on the first day. And, I’d be lying if I said we’ve never made a mistake there. For the most part, we have been incredibly fortunate. It seems that we somehow attract people with similar values. In addition, Santa Barbara is somewhat of a small town and because of that, we’ve been able to hire and work with many people with whom we’ve previously worked. That history counts for a lot because we know who they are and the philosophies they bring to work. Of course, we can’t always hire someone we’ve worked with before. For key hires it’s really important for us to understand their past history. And that’s where references become incredibly helpful. When we talk with references, we look beyond experience. It’s important for us to understand who someone is as a human, too. Practice Patience Finally, there are some days when it’s easier to feel gratitude than others. For example, sometimes people can frustrate you. Perhaps it’s because they’ve disappointed you, or they’re not reaching their full potential or meeting their goals. I think that taking a deep breath and finding the gratitude and the good things that you see in other people helps a lot with patience. And patience is an important part of gratitude. Thank You. To wrap things up, I’ll leave you with this: it’s never too late to start being grateful. I know I’ve mentioned many times that what we have is the product of long-term efforts. But, you too can drive a shift in your organization toward a culture of thank you. Here’s a few things you can do starting today. Think of one thing you’re grateful for. Write it down in a journal or vocalize it to a cherished friend. Incorporate gratitude into your daily standups. Have people share “I’m grateful for _____” in addition to their normal talking points. Make time every week to personally express your gratitude to someone on your team either verbally or in a written note.

If you’re a product manager, then you know that demands for new features come from all directions. Sometimes these demands come from key customers asking for a specific feature to support a workflow unique to them. Other times they might come from your sales team hoping for that one last feature they need to close their next big deal. Still, other times these demands might come from your general user base simply asking for more features in your product. But with all of these new ideas, how are you to decide which is the best investment for your product? Luckily, there’s a simple way to evaluate the impact of adding new potential product features to your product by asking three simple questions. These questions will help you understand not only whether a new feature is worth pursuing, but also how that feature might contribute to your product vision. Are you intrigued? Excellent, then let’s learn what these questions are. 1. Who is this feature for? The first and most important question you should ask about every potential feature is which of your users are most likely to benefit from it? Is the beneficiary a persona known to be a regular user of your product? Or, would this feature appeal to a buyer who is known to influence the purchase of your product? Perhaps the beneficiary is neither a current user or buyer but instead maps to a persona you hope your product will appeal to in the future. For example, imagine that your product is a CRM application designed to help busy sales executives track interactions with prospects more effectively. Your next feature allows sales executives to record notes from interactions with clients using only their voice. This feature likely appeals more to day-to-day users of your product rather than salesforce managers or IT administrators influencing product purchases. On the other hand, if your next feature provides oversight into a salesperson’s daily activities to help managers understand how proactively they are engaging with their prospects, it’s likely to appeal more to salesforce managers who approve the purchase of your product than day-to-day users. In any case, if you can’t articulate exactly which of your personas will benefit from a potential new feature, or if that persona is known not to be a beneficiary of your product, then you should be wary of investing time into bringing that feature to market. 2. What capability will this feature enable? The next question you should ask about each potential feature is what capability it will actually provide. For example, will this feature support a previously-defined initiative that your product is already pursuing, or does this feature clearly map to the desired capability already on your roadmap? While there’s always room for a bit of unexpected inspiration, you should carefully consider any potential product features that don’t directly move your product closer to its stated direction. Generally speaking, users tend to show more affinity to products with a tightly cohesive feature set compared to products with a large set of unrelated features. Products with cohesive feature sets tend to be better able to solve your users’ specific problems in obvious ways. That’s why you should favor features that are more likely to contribute to the direction that you’ve already chosen for your product. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); 3. Why are you building this feature? The last question to ask is, why you are building this feature in the first place? Specifically, what benefits does your organization stand to gain from bringing this feature to market? Will bringing this feature to market give your product a competitive edge, potentially opening up new market share? Or will this feature add value to an already strong product offering or generate incremental revenue opportunities? Are the benefits of this feature even more subtle, such as increasing your organization’s operational efficiency or increasing the value of your organization’s brand in the market? Regardless of what benefit a feature stands to bring, if you can’t articulate exactly how your organization stands to benefit from investing in that feature, then you should be wary of doing so in the first place. hbspt.cta.load(3434168, '3fdc3ac9-84a7-4278-9401-1468475b8db9', {}); Starting with who Odds are, you’ve probably already seen variations of these questions in your career as a product manager. In fact, you may have even asked these same questions about some of your own features, in the past. The difference, however, is that most teams who follow this approach start with what. Starting with what often results in product managers first identifying a feature, and then working backward in an attempt to justify how it might contribute to the product vision. This often results in products bloated with features of dubious value. Or, products lacking a coherent vision or purpose. But by starting with who, you take time first to understand not only who your target users are, but also what problems they are facing. As a result, you’re more likely to create features that will add value to your users’ lives and deeply resonate with the problems they face on a daily basis. However, there’s also another, less obvious advantage. By first focusing your efforts on developing a deep understanding of who your users are and the problems that they face, you increase the likelihood that you’ll also identify additional opportunities to solve similar problems for those same users in the future. Not only does this better position your product to become more entrenched in your users’ daily lives, but it also enables you to grow your product by offering more capabilities to your current user base rather than forcing you to continuously identify new types of users and problems to solve. Putting this to work for you Now that you understand what questions you should be asking about each potential product feature that you’re considering, how do you put this to work with your product? A great place to start is by looking at some of the requests at the top of your product backlog. Ideally, these should be requests that have been made by some of the parties mentioned earlier but that you haven’t yet committed to delivering. Download the free Backlog Refinement: How to Prioritize What Matters Book➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {}); For each request, evaluate it according to the Who/What/Why framework described here. And then, consider what you learn as a result of doing so. For example, does the priority of any of these features change as a result of being viewed through the lens of this framework, or do some features simply not seem as important to your product’s future as they once did? Whatever the outcome, it’s likely that the Who/What/Why framework will add a new way of evaluating which features will genuinely add the most value to your product, and thus the best return on investment for your organization.

Is it Time to Declare Roadmap Bankruptcy? Whether your product finds a market or falls flat, your team needs to understand why this outcome occurred. That way, you’ll know if your strategic plan is working and your roadmap is on the right track, or if it’s time to declare roadmap bankruptcy. In my years as a product manager and product leader, I’ve seen many product teams draw the wrong conclusions from both failures and successes. Even a product that’s earning money and pulling in new customers can be enjoying that success for reasons that have little or nothing to do with what the product team is prioritizing at the time. In fact, those can be the costliest misjudgments. They could lead the team to misallocate resources away from work that could build on its successes and focus on things that don’t move the needle at all. In this post, I’d like to share with you what I’ve learned about when you might need to make major adjustments specifically to your product roadmap—whether your product is falling short of expectations or exceeding them. Then I’ll suggest a few steps you can take to build your roadmap in such a way that you won’t have to declare it bankrupt in the first place. If you’re curious, I’ve also written my thoughts onwhen it’s time to declare backlog bankruptcy. 3 Signs that Declaring Roadmap Bankruptcy is a Fit 1. Fundamental realities have changed since you last updated it. For this example, we’ll use LIKE.TG ourselves as a case study. Throughout the 2020 COVID crisis, we closely monitored customers’ usage data around the world using ourproduct roadmap platform. Based on those data trends, we found that product teams are shifting their behaviors and priorities according to new realities brought on by the pandemic. Our product team has updated our own strategic plans and priorities on our roadmap with this new information. No, LIKE.TG didn’t need to declare roadmap bankruptcy. We needed only to move certain initiatives higher on our priority list and shift others to our backlog. But if we were not paying close attention to how our customers were using our product, we might eventually have found that our existing plans—now based on a changing paradigm—no longer supported our business objectives. Another example: If fundamental realities change for a product’s key persona or industry, those changes could render the existing roadmap no longer viable. At that point, the product team might need to find a way to pivot its product or focus on a new solution. My take: The pandemic and the lockdowns led to such serious disruptions across so many industries that any company’s pre-COVID product roadmap will benefit from a fresh look in light of the new realities. Declaring such a roadmap ready for an overhaul might not be nearly as harmful to your business as insisting on continuing with a product strategy that fails to account for the major shift we all just experienced. 2. Your work on the product is not contributing to your KPIs. Whenever you build a new product or update an existing one, your team might set any number of key performance indicators (KPIs), or success metrics, for it. For example, you might be hoping the product will: Grow your market share relative to a key competitor Win over a new type of user or buyer persona Help your company earn customers in a new market Increase monthly recurring revenue (MRR) from an existing market Increase free-trial signups You might be releasing new product features and enhancements regularly. You might be aggressively advertising to your target markets. But if all of those efforts are not translating to a boost in the specific success metrics you’ve established, you might be misallocating your resources. While product metrics are not an exact science when all signs point to a downward trend, it may be time to declare roadmap bankruptcy. At a minimum, it might be time to review your strategic priorities in light of this. If most or all of your initiatives fail to achieve the objectives you’ve set for them, it might be time to declare roadmap bankruptcy. Note: As you might have noticed, this type of warning signal can be present even for a product that succeeds in the market.Maybe you’ve released a new version of your product, and it receives a lot of free-trial signups. But if the roadmap initiatives your team completed for this release had nothing to do with that KPI, there is a disconnect between your roadmap and the market’s priorities. For example, if your team prioritized bug fixes and eliminatingtechnical debt in the product. In this situation, you can’t simply declare success because you saw a spike in trials. You’ll need to review all of your company’s efforts to figure out what led to the spike in signups. This includes efforts across all teams—marketing, advertising, sales, or social media activity. You’ll also want to review your roadmap to determine if your team is working on the wrong things. Download Product Success Metrics ➜ hbspt.cta.load(3434168, '18f5a8aa-393b-4397-9fd4-f7758c1edf55', {}); 3. Your product team is falling for the “post hoc” fallacy. Post hoc, ergo propter hoc is a Latin phrase meaning: After the thing, therefore because of the thing. It’s a logical fallacy that confuses sequence with causation. To use a silly example: I took a different route home this evening, and it rained overnight. Therefore, when I deviate from my normal drive home, it rains. You can find examples of the post hoc fallacy everywhere, and falling for its subtler versions is easier than you might think. Let’s say your company releases a new version of your product. Let’s also assume your team packed this update with cool new features. Six months later, the overall revenue from the product is up. Post hoc, ergo propter hoc? Not necessarily. What if… The spike in revenue had nothing to do with the new release? Your sales team hit on an effective new strategy for presenting the product to customers in demos? Your marketing team created a brilliant piece of social media content that went viral? A persona in an industry you weren’t even targeting somehow discovered your product? Word got out in that industry, and the orders flooded in. Word got out in that industry, and the orders flooded in. If you’re not monitoring these details carefully, you might make this pervasive post hoc error: We did a lot of work on the product and released it to the market. Product revenue increased. Therefore, our work on the product led to an increase in revenue. By the way, the post hoc fallacy works for the opposite outcome as well. Your team might just as easily attribute a product failure to a poor sales presentation or a badly designed eCommerce experience. But those things had nothing to do with why your solution failed to find a product-market fit. hbspt.cta.load(3434168, 'ad657ba8-be75-4be1-a163-e71ff5498018', {}); 3 Steps to Developing a Bankruptcy-Resistant Product Roadmap As I pointed out above, sometimes a roadmap becomes bankrupt, not due to anything the product team does but simply because external realities demand a new approach. For many companies today, the fallout from COVID might have caused such a shift. I bring this up again to note that no matter how carefully you build your product roadmap, you might need to declare it bankrupt in the future because of the ground shifts beneath you. In other words, you can’t create a roadmap that is truly bankruptcy-proof. But the following steps should help you develop a roadmap that’s at least bankruptcy-resistant. 1. First, make sure you’re actually solving a real market problem. You should never begin developing a product roadmap until you’ve determined—based on evidence—that the product idea addresses a market problem worth solving. Here’s the easiest way to find yourself in roadmap bankruptcy. Start with a product idea your team is excited about but that you haven’t also vetted with a ready, eager market. Now, even if you have vetted your idea, your team can still fall short in executing the details. But if you don’t first make sure you’re building a product that solves a real problem for real people—one they’re willing to pay to solve—your roadmap won’t stand much of a chance of success. hbspt.cta.load(3434168, '9754e937-d766-41b6-acef-85c0aefaaa24', {}); hbspt.cta.load(3434168, '8d90fe78-17c8-4e9d-b664-8a5e4e8a2afb', {}); 2. Set specific success metrics for each initiative. Okay, let’s assume you’ve compiled data supporting the case that your product idea is worth pursuing. Your next step will be to start building the roadmap itself. For each theme, epic, and other strategic initiatives you add to the roadmap, you’ll want to make a note of the key reasons it belongs there. As well as the success metrics you’ll be monitoring to determine if it’s serving its purpose. This is one of many reasons to use native roadmap software instead of spreadsheets or slideshows to build and maintain your roadmap. You’ll find it much easier to attach a strategic note to each item on the roadmap with a click than by having to create your own color-coded legends and tags. In this screenshot of LIKE.TG’s roadmap app, you can see how easy it is to add a strategic goal to each container or bar you drop into your roadmap. You can also review each initiative’s goals and share them with your team, with a single click as well. Remember, specificity is the key to gaining the only business insight that matters. Is this project we’ve prioritized on our roadmap moving the needle the way we hoped? If so, then it’s worth the continued effort and resources. If not, it might be time to scrap this initiative, or at least shelve it for later, and shift those resources to another project with a better chance of meeting your goals. 3. Check on your data regularly.Assigning success metrics to each item on your product roadmap is the best practice. But those metrics can guide your team as to the effectiveness of your roadmap only to the extent that you look at them—and often. Remember, the ground can shift under your plans for any reason, at any time. As you release a new version of your product, for example, you should have a specific set of KPIs for anything you’ve added. This includes new functionality, product enhancements, an additional pricing option, etc. Then, you’ll want to check in at some point after the launch, review all relevant data, and check those data against the KPIs you’ve set. Is the new functionality leading to the added trial downloads as you’d hoped? Great! Are the enhancements helping to slow your churn rate? Also great! But if you’re not analyzing your data with this level of granularity, you can’t expect to know which initiatives warrant continued resources and which don’t. You also won’t know if, for whatever reason, it’s time to declare your roadmap bankrupt. Sign up for our email courses or watch our roadmap webinar “Common Roadmap Communication Challenges” for additional support in creating your product strategy. hbspt.cta.load(3434168, '56aa459c-cbe7-403b-b3aa-96d107286b55', {}); 点击播放声音 @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; } 6:28 #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset{font-size:14px;} #wistia_chrome_23 #wistia_grid_75_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_75_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_75_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_75_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_75_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_75_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_75_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_75_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_75_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_75_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_75_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_75_wrapper a.w-css-reset{border:0;} #wistia_chrome_23 #wistia_grid_75_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_75_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_75_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_75_wrapper p.w-css-reset{margin:1.4em 0;} #wistia_chrome_23 #wistia_grid_75_wrapper a.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_75_wrapper span.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_75_wrapper svg.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_75_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_75_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_75_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_75_wrapper ul:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper ol:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper li:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper ul:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper ol:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper li:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_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_75_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_75_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_75_wrapper .w-css-reset button::-moz-focus-inner{border: 0;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree {font-size:14px;} #wistia_chrome_23 #wistia_grid_75_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_75_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_75_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_75_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_75_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_75_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_75_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_75_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_75_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_75_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_75_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_75_wrapper .w-css-reset-tree a{border:0;} #wistia_chrome_23 #wistia_grid_75_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_75_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_75_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_75_wrapper .w-css-reset-tree p{margin:1.4em 0;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree a{display:inline;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree span{display:inline;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree svg{display:inline;} #wistia_chrome_23 #wistia_grid_75_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_75_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_75_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_75_wrapper .w-css-reset-tree ul:before{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree ol:before{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree li:before{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree ul:after{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree ol:after{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree li:after{display:none} #wistia_chrome_23 #wistia_grid_75_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_75_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_75_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_75_wrapper .w-css-reset-tree button::-moz-focus-inner{border: 0;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-max-width-none-important{max-width:none!important} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-button-important{border-radius:0!important;color:#fff!important;} #wistia_grid_75_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_75_wrapper *{-moz-box-sizing:content-box;-webkit-box-sizing:content-box;box-sizing:content-box;} #wistia_grid_75_above{position:relative;} #wistia_grid_75_main{display:block;height:100%;position:relative;} #wistia_grid_75_behind{height:100%;left:0;position:absolute;top:0;width:100%;} #wistia_grid_75_center{height:100%;overflow:hidden;position:relative;width:100%;} #wistia_grid_75_front{display:none;height:100%;left:0;position:absolute;top:0;width:100%;} #wistia_grid_75_top_inside{position:absolute;left:0;top:0;width:100%;} #wistia_grid_75_top{width:100%;position:absolute;bottom:0;left:0;} #wistia_grid_75_bottom_inside{position:absolute;left:0;bottom:0;width:100%;} #wistia_grid_75_bottom{width:100%;position:absolute;top:0;left:0;} #wistia_grid_75_left_inside{height:100%;position:absolute;left:0;top:0;} #wistia_grid_75_left{height:100%;position:absolute;right:0;top:0;} #wistia_grid_75_right_inside{height:100%;right:0;position:absolute;top:0;} #wistia_grid_75_right{height:100%;left:0;position:absolute;top:0;} #wistia_grid_75_below{position:relative;}

Today, software development is all about the need for speed. Feature updates, UI changes and bug fixes are all done in near real time, and the frenetic pace is ever-increasing. Users have grown accustomed to constant updates to apps and expect any issues to be fixed immediately. Pushing new features or software fixes has always been fraught with anxiety, but the speed and frequency of today’s release cycles bring even more pressure. As soon as code is released to the public, users can instantly access the feature, leaving many variables out of developers’ control. But, there is a way to take back control and maintain visibility over the release: feature flags. Raising the feature flag At a basic level, feature flags allow development teams to turn features on and off without deploying new code. Think of flags like dials in the cloud. When the dial is attached to any feature in a product–whether a new one or an old one–it controls who sees it, who has access to it and how quickly it is delivered to an entire customer base. Feature flags let organizations break the tyranny of the Thursday night release by breaking it into smaller bits to control exposure and enable a continuous release motion. You might start by “releasing” only to internal users or beta testers so you can test in production (TiP) to make sure nothing has been missed. From there, you might roll out to your customers gradually before going to 100% availability. This controlled exposure approach removes the panic and anxiety around the weekly release schedule. Having the ability to completely turn off features means that feature flags also increase application stability and remove the need for hotfixes. It’s less often necessary to assemble a war room if there is a problem when you can simply turn off the feature in a matter of seconds. By working feature flags into the release process, teams take control of the who, what and when in terms of releases. They can dictate types of users, demographics, locations and scale the release of the new feature. Not another thing to manage Outside of the DevOps team, feature flags can also be really powerful for product managers. Historically, the release of a new feature meant that product managers had to coordinate with cross-functional teams to ensure the release was executed successfully. This coordination involved making sure marketing was ready to publish a blog post about the feature, the sales team knew how to use and sell the new feature, and the product marketing team had documentation prepared for how the feature set works–and this all had to be perfectly synchronized with the engineers’ timeline for releasing the feature. Feature flags give product managers the keys to the kingdom. Product managers can now go into the user interface and turn the feature on for some or all of their customers without waiting for engineers to complete their next deploy. Not having to coordinate that extra piece of the schedule gives a lot of power and time back to the product manager. Feature experimentation: data-driven customer feedback Another aspect of a product manager’s job is collecting feedback. They need answers to questions related to business KPIs, like “How is this feature performing for my customers?”, “Are customers able to do the action the feature is intended to perform?” and “Are we generating more revenue from the feature?” Feature flags can also help in this area. As product managers ramp-up a feature, they are simultaneously shortening the feedback cycle. Since feature flags allow for segmentation, where one customer group sees one set of features and another customer group sees a different set of features, and since key metrics can be captured into separate buckets for each group, product managers can now run controlled experiments as part of a release cycle. Seeing KPIs aligned with the different customer groups helps you understand which features are performing the most successfully. hbspt.cta.load(3434168, '3fdc3ac9-84a7-4278-9401-1468475b8db9', {}); Let’s escape to the Swiss Alps for an example If you’ve read this far, you probably have a pretty good idea about how this approach could add value to your work as a PM. To really cement your learning, consider reading the brief post my colleague David Martin wrote, “Feature Experimentation: Choosing the Best Route.” In this four-minute read, David puts you in the role of commercial tour planner choosing the best route for families to hike along the Tour Mont Blanc in France, Switzerland and Italy. Feature experimentation teams you up with actual customers to help you find the best path forward. Aligning your entire team to deliver value As product managers embrace usage measurement tied to feature rollouts, entire teams can better align with agile best practices to continuously push out the smallest incremental set of new features. By understanding the performance of every feature, you’ll be better equipped to iterate and refine your ideal product roadmap. Download How Agile Product Managers Can Build Better Products ➜ hbspt.cta.load(3434168, 'b4eb5c0b-bf4b-4a7e-9b0a-75f92005c127', {});

Last week I had the pleasure of attending the ProductCraft conference, a one-day event for product managers in San Francisco. For those of you who are unfamiliar, ProductCraft is a community for product managers that is run by Pendo. This being the first year of the ProductCraft event (and because I lead product marketing at a company in the product management space), I was especially curious. What would the attendance be like? Who would be sponsoring? What would be the hot topics under discussion? On the whole, I thought the conference was great. Well done to Pendo and everyone else involved in pulling it off. Everyone I met with throughout the day seemed to share my sentiment—the event seemed to satiate (at least in part) product managers’ desire for education, encouragement, and community. For everyone who couldn’t attend (and even for attendees who went to different sessions), I thought it might be helpful to give a quick summary of the key takeaways from the talks throughout the day. Here’s what stood out to me: 1. Failure is your friend. Guy Raz, host of How I Built This and the TED Radio Hour In the opening talk of the day, Guz Raz shared seven lessons he’s learned from interviewing the world’s leading entrepreneurs. While his presentation was peppered with nuggets of product management wisdom (from Stuart Butterfield’s “always be ready to pivot” to James Dyson’s “listen to the doubters but never lose sight of the big picture”), the lesson that resonated with me most was an old classic: failure is your friend. The phrase “failure is your friend” has taken many forms over the years, but it has always been a mantra of the tech community. Guy Raz presented it in a slightly different light. Instead of sharing how entrepreneurs can learn from their failures, he emphasized distancing yourself from your business failures, giving Joe Gebbia (the founder of Airbnb) as an example. When Joe and his co-founder first launched Airbnb, they struggled to generate interest and create a smooth experience for customers. Instead of giving up or letting their challenges bog them down, they tried to zoom back and view the challenges objectively. Doing so allowed them to improve the product and turn it into the global hospitality powerhouse it is today. In business and in product, it’s easy to be discouraged by a failed product launch. Just remember to keep things in perspective. And sometimes zooming out and distancing yourself from the problem can make everything a little clearer. 2. Don’t be afraid to sleep around (with different frameworks). Jen Dante, Head of Product for Payroll at Square Product managers today have a plethora of frameworks and tools at their disposal. In her amazing talk, The Promiscuous PM, Jen Dante walked through a few of her favorite frameworks she picked up while working in Product at Google, Netflix, and Square. She advocated for product managers to not tie themselves down to one specific framework or toolset, but to assemble a collection of frameworks to use for different situations (to be a fox, not a hedgehog). Rather than focus only on one of her examples, I’m going to lean into Jen’s advice and share as many of her tips as I can remember and let you do some further reading. Jobs to be done – Ask the question “what job is your product hired to do?”. Classical economics – The macroeconomic principles that drive our users and buyers. Behavior economics – The fun side of economics, such as price anchoring and status quo. The user is drunk – Try designing your app as though your users are drunk. The Kennedy principle – Ask not what your user can do for you, but what you can do for your users. 3. Check your biases. Benjamin Evans, Inclusive Design Lead at Airbnb In my favorite presentation of the day, Benjamin Evans began his talk by sharing his first experience as a customer of Airbnb. He was taking a trip to South Africa and he thought he would try out this new service called Airbnb. He found a host with a room available in a good neighborhood and booked his stay. After a long day of travel he arrived at his host’s house. And she told Benjamin that he couldn’t stay there because he was black. Fast forward a few years and Benjamin now works at Airbnb, leading a team of designers responsible for making Airbnb for accessible for everyone. His team works on a tool set called “Another Lens”, which is essentially a collection of questions that help everyone at Airbnb (especially the product team) check their biases. Here were a few great observations he shared: We naturally build problems for ourselves. It takes a concerted effort to see our products and world through a different worldview. Metrics-driven teams often design for averages (and it is a lense). Language localization was one of the biggest drivers of growth at Airbnb. Making Airbnb’s site ADA accessible improved the site in other areas (usability, search indexing, etc.). 4. Ask your customers the right questions. Steve Sloan, Chief Product and Marketing Officer at Twilio SendGrid Steve Sloan was a panelist on a great session moderated by Megan Quinn of Spark Capital called “At the Frontier of ‘Product Led.’” The panel shared a lot of great tips for product managers, but one quote from Steve stood out to me in particular: Asking a customer “what do you want?” is like asking your significant other “where do you want to go for dinner tonight?” There are better questions we can ask. When interviewing customers, you already know so much about them. You probably know their job title and their role. If you’ve done your homework, you know a little bit about their company and how they are using your product. Unless you don’t have the tools, chances are you have metrics on their product usage so far. So why throw all that insight you have and start from scratch with a question like “what do you want?” (which also puts the effort/onus on them). This echoed that theme that many of the panelists brought up throughout the session: product managers are being held to a higher standard than ever before. Because product managers have so much more at their disposal (tools, data, insights, resources), a lot more is being asked of them. While asking a customer “what do you want?” might have worked in the past, it doesn’t cut it today. Similarly, presenting your justification for developing a new feature without doing your homework (customer interviews, user metrics, market info, etc.) doesn’t work anymore. 5. Spend your decision effort on the big decisions. Justin Dilley, Head of Product at FullStory In a collaborative, working-session style presentation, Justin Dilley gave an inside look into how product is structured at FullStory and the tools and processes they have used as the product team grows. The main thrust of his talk was how to be more efficient with your decision-making process. Referencing Parkinson’s Law of Triviality (which essentially claims that members of an organization give disproportionate weight to trivial issues), he talked about how important it is as a product manager to spend your time and energy on the big decisions. For example, you can spend all day arguing about a button color in a group meeting while neglecting the fair more significant decision of which payment processor you choose for your application. Justin shared two tactics that the product team uses that I thought were particularly interesting. First off, they have a unique team structure that allows ~10% of their engineering force to work on what they call “valor” projects. These are the sharp edges, “pebble in your shoe” issues that might be low effort but can pile up if they go addressed. I liked the idea of committing to chipping away on these types of things every sprint. Secondly, the teams at FullStory use a prioritization framework called 9-block. 9 block is essentially a visualized version of the value-vs-effort framework that makes it easy for the entire team to understand what is being prioritized and why. 6. Don’t be a “mini CEO.” Be a conductor. Jeff Lash, Vice President and Group Director, Product Management at Sirius Decisions In a fun, 45-minute conceit, Jeff Lash of Sirius Decisions walked a packed house through the idea that product managers should be conductors of an orchestra, as opposed to the popular concept of “mini CEO”. One of Jeff’s observations that stood out to me was how product management has resisted the natural progression to specialize roles. While some companies might have Technical Product Managers or Growth Product Managers, a majority of companies just have product managers, and these product managers need to be generalists. 7. Get coffee from Wrecking Ball Coffee Shaun Juncal, Senior Product Marketing Manager at LIKE.TG Next time you’re in the Cow Hollow neighborhood of San Francisco, get coffee at Wrecking Ball Coffee Roasters. It’s good.

As product management continues to evolve, many new practices have been put in place to optimize product teams. Agile, Kanban, and similar methodologies have helped shape the landscape of product management in the 21st century. And the landscape continues to change at a rapid pace. New tools for product management teams appear frequently, each promising to improve the process in some way. Data is an increasingly significant component of product decisions. And, organizations can innovate at a faster pace than ever before. Many of these changes have led to the rise of a completely new discipline within the product management landscape: product operations. In this blog post, I’ll share an overview of this new role, explain what product operations does, and take a look at how product operations are the new discipline powering product excellence for growing product teams. What is Product Ops? To understand product ops, it might be helpful to look at another similar discipline: marketing operations. In 2005, MarketingProfs defined marketing operations as follows: “Marketing operations builds a foundation for excellence by reinforcing marketing strategy with metrics, infrastructure, business processes, best practices, budgeting, and reporting.” I believe that the same definition can easily be applied to product ops. You could, therefore, define product ops as follows: “Product ops builds a foundation for excellence by reinforcing product strategy with metrics, infrastructure, business processes, best practices, budgeting, and reporting.” In short, product ops serves to support the product team and help build better products. But how does that look in practice? The answer to that varies significantly from company to company. Product ops is a very new field; as such, you will see massive differences in how different companies define the roles and responsibilities of product ops. To give you some perspective of just how much variation there is, here’s how a few organizations leverage product ops. Lever has a Product Ops team that essentially serves as an intermediary between front-line support and Engineering. Uber has a fleet of Product Operations Managers that are responsible for getting out of the office and talking with as many customers and users as possible. DataXu has a Head of Product Operations role that reports to the CTO and is responsible for “measuring the product development process and implementing the necessary changes to make it more effective”. What does Product Ops do? One easy way to understand the role of product ops is to break it down into three main categories: tools, data, and experimentation. In general, product ops provide support to the product team in these three critical categories. More tools, more problems One of the biggest changes in product management over the last 10 years has been the increase in the number of tools built specifically for product managers. From roadmapping to prototyping, the modern product manager has more tools at their disposal than ever before. Tweet This:“The modern product manager has more tools at their disposal than ever before.” While product managers often have a wide skill set, managing (and administrating) all the different tools that make up the modern product stack isn’t always the best use of those skills. As product teams grow, the administration component becomes bigger and bigger, and this is where product ops comes in. In a large organization, the product ops team is often responsible for managing the plethora of vendors used by the product team. They also work to establish best practices and processes for the use of those tools within the product organization. hbspt.cta.load(3434168, '3be75db1-0d50-46dd-b222-ce0aa84f6b08', {}); An explosion of product data Just as the typical product stack has grown over the last 10 years, the amount of data available to product managers has grown exponentially over the last decade. When you look at the volume of data produced the world’s most popular products (Facebook has over 2 billion active visitors, Netflix has 137 million paying subscribers), it’s not hard to imagine the product managers working on those products being overwhelmed by the amount of data available to them. Even if you don’t work at Facebook or Netflix, chances are your product team has a data problem. It’s possible that you don’t have enough data available to make informed decisions. But, it’s far more likely that you either have too much (and are overwhelmed with the sheer volume of it) or you aren’t sure about the accuracy of the data available to you. (This is the most common “data problem” for product managers I’ve talked with). In a growing product organization, a product ops team can lay the foundation for a successful, data-driven team of product managers. If you’re a new product ops hire, or even if you’re a small team of product managers looking to put data best practices in place, here are a few tips to get started. Three quick tips for taming the product metrics chaos: Understand what you want to measure before you roll out new systems. Make one person responsible, at the end of the day, for data integrity and cleanliness. Establish naming conventions and make your team stick to them. Actionable experimentation Creating and optimizing an experimentation culture is key to successfully scaling a product organization. As your user/codebase grows, you will inevitably end up running more and more experiments. And, as your product team grows, you will inevitably have different product managers motivated by different metrics. If you want to foster a culture of experimentation in your product team, it’s important to have the processes in place to make those experiments as reliable and actionable as possible. In a recent article with First Round Capital, Alex Le and Kavin Stewart (co-founders of Reddit), talk about the importance of having a “traffic cop” when it comes to experimentation. This can be another important area for products ops to support the product team. At Reddit, for example, product ops plays an important role in looking holistically at the product experience and making sure that all of the product-level experimentation is tied to company goals. As Reddit’s product team grew, it was important to have someone “keeping track of the various projects that are underway, how they relate to each other, how the results of tests might be interacting, and how changes are ultimately implemented.” Do You Need a Product Ops Team? At its core, a product ops team is about supporting the product team and making it easier to ship great products. When your product team only has 3 team members, they should be able to multitask and take ownership of the areas discussed above. As the team grows, however, you’ll begin to encounter these challenges first-hand. Here’s a handy list of questions to ask yourself when determining whether your product team needs to hire someone for product ops. Are your product managers spending more time with administrative tasks than they are with their core responsibilities? Does your product experimentation culture feel out of control? Do you not trust the data that your team is making decisions with, and do you not see a clear path to fixings that problem? So, if you’re experiencing any of the challenges above, perhaps it may be time for you to consider creating a product ops role, or even a product operations team. On the flip side, you could consider adding a product ops role to help improve your team’s effectiveness before you face any of the common growing pains above. The LIKE.TG team discussed How to Get Started in Product Ops in the webinar below. The discussion covered what signs to look out for to know when to start product ops, how to make a case, who and how to hire, where to focus, and what are your next steps. If product ops is of interest, it’s actionable and a great place to start your product ops journey.

“But we’re agile. We don’t plan.” If you’ve ever worked with an agile team, chances are you’ve heard this excuse. However, even agile teams need a disciplined approach to planning. Teams who invest time in proper planning tend to have a better understanding of long-term goals for the product, and more realistic strategies for achieving those goals. How Does Traditional Planning Work? But to help your team get the most out of agile planning, you first must understand how agile planning compares to more traditional planning with which you might already be familiar. We dive deeper on this topic in this quick guide to deconstructing agile product management. Traditional planning methods typically follow fixed cycles, with those cycles often occurring very far apart. For example, a team planning on an annual cycle might define their entire strategy for the upcoming year in a single session in January. During this session, they might not only define their goals for the year, but also a detailed plan for achieving those goals. And they’d likely assign just as much specificity to their plans for December as their plans for January. By the end of the session, everyone agrees the resulting plan will chart their course forward for the next year. But despite everyone’s best intentions, sooner or later, reality will strike. Unforeseen developments such as customer demands, competitor movements, or developments in the overall market will render pieces of the plan unattainable, or even irrelevant. However, rather than attempt to reconcile the plan with the new reality, the team presses forward in hopes of catching up to their earlier aspirations. Ultimately this results in a team forever struggling to meet the expectations of an unachievable plan and an organization forever disappointed in their inability to do so. In many cases, this is the reality of traditional planning. What is Agile Planning? Let’s compare traditional planning to agile planning. In agile approaches, a team might plan with different levels of detail depending on the timeframe for which they are planning. For example, they might plan their goals for the year at a high-level, their strategy to achieve those goals over the next few months in a bit more detail, and the steps necessary to implement that strategy over the next few weeks in the most detail. In addition, as they move through the year, the team is likely to progressively elaborate their plans based on what they learn throughout the year. This approach gives the team clarity on their responsibilities in the short-term while at the same time helping them understand how these responsibilities contribute to long-term objectives. But how do you strike the right balance between short and long term planning? Many agile product teams use an approach called the Planning Onion. Get Strategic Project Alignment ➜ hbspt.cta.load(3434168, 'bfb5032e-5746-4c05-9f2a-54b36ba0e871', {"useNewLoader":"true","region":"na1"}); Agile Planning, Meet the Planning Onion The Planning Onion helps teams choose the right level of planning for each timeframe for which they are planning. Most often, it’s represented like this.To get to know the Planning Onion let’s walk through each layer, starting from the top. Download How Agile Product Managers Can Build Better Products ➜ hbspt.cta.load(3434168, 'b4eb5c0b-bf4b-4a7e-9b0a-75f92005c127', {}); Defining Your Vision At the top of the Planning Onion, we have the visioning layer. In this layer, the goal is to define the overarching problems your product is solving as well as for whom it is solving those problems. Considering these questions at the outset will help you understand the true value your product brings to users as well as how your product might differentiate itself from other products attempting to solve the same problems. A great way to do this is collaboratively completing a product vision canvas with the leaders of your organization. There are many great canvases available, but my personal favorite is the Product Vision Board by Roman Pichler, as this canvas can help your team focus on the questions they need to answer to be successful. Charting Your Course At the next level, we have the roadmap level. At this level, you and your team will create a high-level plan of how the objectives defined in your product vision might be achieved over the long-term. Often the contents of the roadmap are grouped into releases to better communicate to your broader organization when the features identified in each release might be available. The specific contents of each team’s agile roadmap will vary, but generally speaking, your roadmap should define the features your team will deliver to achieve the stated objectives. These features should be described at a high level, rather than as individual stories and tasks. In addition, your roadmap should visually display dependencies between features so your team can determine the most effective approach for tackling those features. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); Stacking Your Releases Moving one level lower is the release planning level of the Planning Onion. At this level, your goal is to elucidate the specific features that will comprise each release defined in your roadmap. If individual stories and tasks are too specific for the roadmap level, then they’ll find themselves right at home in the release plan level. With a well-defined release plan, your team will be better equipped to describe a realistic timeline for the delivery of each release. A thoughtful release plan will help set more realistic expectations across your broader organization. Looking a Few Weeks Ahead Near the bottom of the onion is the iteration level. In this level, your team selects the individual stories that will comprise the next iteration and create a plan for how to deliver each story. If your team is following a Scrum approach, then you might recognize this stage as your Sprint Planning session. However, even agile teams who aren’t following a Scrum approach tend to do some form of iteration-level planning by selecting and planning their upcoming work in small batches. Planning Your Day At the bottom of the Planning Onion is the daily level. At this level of planning your team assesses their status at the beginning of the current day and collaborates on a plan for moving forward over the next day. Many teams accomplish this through a daily standup in which they discuss progress made the previous day, progress they expect to make on the current day, as well as anything that might threaten that progress. While this morning ritual begins with a discussion of what was accomplished the previous day, the most successful teams recognize that the daily standup is a planning meeting, not a status meeting. Therefore, it should focused on creating a plan to move forward, at the daily level. Finding Your Stride While the Planning Onion clearly describes multiple levels of planning, its true power comes from its iterative nature. Each layer of the Planning Onion is not intended to be executed once, but multiple times throughout a product’s lifetime. However, the frequency of each layer’s execution will vary depending on where that layer falls in the onion. Generally speaking, you’ll plan at the lower levels most often but progressively slow your planning as you move towards the higher levels. For example, while your daily planning is likely to occur, well…daily, you may only need to revisit your product vision every few months or even annually. In addition, the participants of your planning sessions change as you move through the layers of the onion. Specifically, the participants in planning at the topmost layer are likely comprise mainly of the executive-level decision makers in your organization. As you move towards the lower levels of the onion, participants are likely to shift to individual contributors of your team. The nature of this layer of planning favors collaboration with those closest to the work that is to be done as they are often best suited to decide how to do that work. Making Agile Planning Work With Your Team If you’re ready to put the Planning Onion to work for you, you must first understand where your organization is in its current approach to agile planning. A great way to find out is to ask how many layers of the Planning Onion your organization has already implemented. Most agile organizations do some level of daily planning. Many also have some form of iteration planning in place. If your team is missing either of these layers, then close that gap first. This is because without the ability to plan reliably in the short term, your team can never hope to plan for the long term. In addition, most teams already have a stated vision for their product. But, it’s not uncommon for that vision to no longer reflect the broader goals of the organization or the team’s capabilities to deliver those goals. If you haven’t revisited your product’s vision in the past few months to ensure that it accurately reflects your organization’s goals, then now is an excellent time to do so. Once you’ve confirmed that your organization has solid daily and iteration level planning routines in place, and that your product vision accurately reflects your organization’s goals, you can address where most teams fall short: roadmapping and release planning. For many agile teams, the roadmap and release planning levels of the Planning Onion are the most common omissions. If this sounds familiar, start by defining a roadmap based on the desired outcomes in your product vision. Once you have a roadmap in place that accurately represents your desired features, as well as the dependencies between them, then you can use that roadmap as a starting point for developing a more detailed release plan. The combination of these two planning tools will give your team the clarity they need to understand what success looks like for your product as well as the guidance they need to plan how to achieve it best. A structured approach to planning is essential to a team’s success, even for agile teams. However, you must first understand the different levels of planning at your disposal. You must then discern which level is the right choice at the right time. These skills are what separate those teams who simply deliver a product from those who truly enable the success of their customers.

The IMPACT approach to product management’s primary goal is creating the maximum value for the broadest target audience while remaining aligned with the company’s mission, vision, and goals. Filtering everything through the IMPACT lens can be extremely beneficial. It helps product teams level set every action, process, and decision to ensure they’re staying true to that objective. But if there’s one part of product management that needs IMPACT more than anywhere else, it’s roadmapping. Roadmaps set the tone for the coming months and years. They typically direct dozens—sometimes hundreds—of people involved in the implementation and rollout of product releases. Not to mention they dictate what marketing and sales will be able to promote and sell going forward. No one wants a plan for the future that isn’t exciting, inspiring, and positioning the product for growth and success. Yet far too often, bug fixes, custom client requests, and features of dubious value take up valuable bandwidth. These items snap up spots on the roadmap that would be better filled with innovative, value-added customer benefits and revenue-goosing enhancements. Where trouble begins Most product teams don’t set out to create lackluster roadmaps, but they’re often dealt a sub-par opening hand. You ideally begin with the company’s mission and vision. However, many organizations aren’t great at strategy, so there’s often a disconnect between those lofty ideals and reality. Senior leaders’ KPIs and metrics fixate on don’t always align with the long-range objectives and key milestones required to get there. This leaves the next crucial steps up to product managers. Yet PMs are sometimes given little direction when it comes to setting priorities and goals. This doesn’t prevent them from being met with withering criticism or—even worse—deafening silence when coming up with and presenting a plan. So these roadmappers need a rubric to continually measure the overall impact of their blueprint for the product, and IMPACT can do just that. Laying the groundwork for a roadmap with IMPACT IMPACT doesn’t begin with the roadmap. It must be part of the process in earlier stages of product development, particularly during prioritization. According to its own impact, vetting and judging each potential roadmap item culls the herd and eliminates requests and ideas that won’t move the needle where it matters most. IMPACT also shouldn’t be thought of as a component of the roadmap. There shouldn’t be any swimlanes dedicated to each letter of the acronym. Nor should “Clear” or “Actionable” appear in the legend. IMPACT’s value comes into play in a few other ways. First, by utilizing the IMPACT scoring approach during prioritization, there will be far more confidence it consists of worthy endeavors stakeholders will agree on merit inclusion. The roadmap’s overarching themes should also stand up to the IMPACT test. Each major goal and the desired outcome should meet the same criteria that any individual development items have already attained. You can also judge the roadmap as a whole based on its IMPACT. Looking out six, nine, or twelve months, will the planned themes and projects deliver results that adhere to this credo? If not, what’s driving the prioritization of work that doesn’t improve things along these lines? Staying true to a roadmap’s true purpose Product roadmaps aren’t projected plans, schedules, or a laundry list of deliverables. Not that stakeholders don’t try to turn them into that occasionally. You can’t necessarily blame them—these folks are desperate for updates and information that they can use tactically to do their own jobs. Despite this frequent bastardization of purpose, product roadmaps are supposed to be about why you’re doing something as much as they explain what it is and when it might show up. To shift that mindset, product managers must change up the internal conversations around roadmaps and evolve the organization’s product culture. And here’s one more opportunity for IMPACT to play a role. hbspt.cta.load(3434168, '7c551d2b-ed71-444c-888b-18461bcb6944', {"region":"na1"}); The roadmap is a canvas to tell a story, not a checklist or Gantt chart. And that story is laced throughout with IMPACT. Everything on there should fit the narrative, benefitting users while advancing the corporate strategy. I personally structure our roadmap by value areas—the value we want to deliver to create that impact. I then structure the legend to reflect our differentiators. Before I actually put anything on the roadmap, its bones already indicate what’s most important for our business. With that foundation, I can start looking at opportunities, resources, and investments. Combined with using IMPACT for prioritization within each area, I know the product delivers value in all of the most impactful areas. Interesting Roadmaps are a way to tell your story visually. They connect your audience with the journey, so they walk away with the most pertinent information. Regardless of what the roadmap contains, it all comes back to why you prioritize that work and tell a story that belies the successes and victories to come after implementation. Meaningful Tailoring your roadmap to specific audiences is key by leaving out anything that distracts from the narrative or isn’t relevant to each stakeholder. External customers need to see which problems you’ll solve for them in the coming year. And internal stakeholders want to connect the dots between what’s on the roadmap and their impact on OKRs and KPIs. People Put yourself in the shoes of the different people your roadmap is for. Next, customize it for their own areas of interest and concerns. With this relevance top of mind, decide which parts of the roadmap you want to share, how far into the future it should go, and which methods are most effective to communicate your plans. Actionable Every roadmap is “actionable,” assuming things are implemented according to that plan. But I tend to worry about what I expect the audience to do with the information they’ve just received? I’m looking for customer validation and feedback, sales and marketing to update their pitches and collateral, customer success to anticipate how they’ll roll this out to customers, and how the technical teams will determine feasibility and make things happen. That means my roadmap needs the necessary information and context to enable these behaviors and actions. hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"}); Clear Roadmaps should answer existing questions and not raise too many new ones—you’re shooting for generating excitement, not doubts. That’s why conveying the why is vastly more important than the what. Measure their engagement and comprehension based on the questions they ask. Testable Roadmaps can also be tested by trying them out on different crowds. Socializing your proposed plan with small groups can generate valuable feedback instead of waiting for a grand reveal and falling on your face when presented with a tough question. Creating that space for failure and challenges gives you additional opportunities to polish things up while also acknowledging that your course may vary based on an always uncertain future. Impress them with IMPACT If your roadmap holds up to the IMPACT test, you can confidently enter any presentation. You’ll know that even if everyone doesn’t agree or approve, they can’t argue with your rationale or reasons. You could still get overruled by an executive or a flagship customer, but you can still stick to your fundamentals even if a few wrinkles are thrown your way. Most importantly, you’ll have value creation on your side as you lobby to retain the items you know will create the most impact for customers and the business. For more examples of how IMPACT can guide your product management endeavors, download the free IMPACT ebook today. Watch Annie talk through IMPACT: Processes in the webinar below.

I’ll admit it, in the past, I’ve wrestled with needing to control uncertainty. For years I thoroughly planned most everything and felt the need to know the eventual outcome of decisions. I had expectations, and if the expectations weren’t met, I was disappointed. Whether it was a product I managed or a vacation I took, I wanted to control the inevitable uncertainty. Uncertainty is uncomfortable. As a result, I found myself with a lingering sense that things were out of control. As a product manager, the uncertainty manifested in really detailed and lengthy Product Requirements Documents. I know I’m not the only product manager with this challenge. Over the years, I’ve realized through observation and personal experience that the most successful and happy people are those who are willing to embrace uncertainty. They are the ones who make “risky” decisions without knowing 100% of the information. It’s especially true for product managers, entrepreneurs, and others who want to launch products or ideas. Download The Essentialist Product Manager ➜ hbspt.cta.load(3434168, 'be753440-dc4d-40c5-9808-cad744d00a28', {}); I’m much better now about letting things unfold without needing to know how the plan eventually will materialize. And yes, I get the irony that I’m the co-founder of LIKE.TG, software that helps product managers visualize their plan. More on that later. The Psychology of Uncertainty The fear we all feel from uncertainty – and the feeling that we can control it – can cloud our thinking. After all, research consistently shows that humans are wired for seeking comfort, safety, and loss aversion. Our inner cave-person wants to avoid getting eaten by the tiger. A couple of years ago, our team read the fantastic book Thinking, Fast and Slow by Daniel Kahneman, a Nobel Prize Winner in Economics. His research demonstrated that we choose options to avoid loss. We don’t behave logically when presented with the same choice framed in different ways. In one example from the book, a disease that kills 1,286 people out of every 10,000 is considered more dangerous than a disease that kills 24.14% of the population. In studies, we believe the first disease to be more threatening even though the actual risk is significantly less than the alternative. We also tend to overestimate our ability to control events – and this feeling that we can control a situation is an illusion. If we can stop for a moment and change our thinking that we’re not in as much control as we think, and surrender to it, we’re more likely to succeed because we’re open to change and opportunities we wouldn’t see otherwise. hbspt.cta.load(3434168, '6291e080-7d48-43d6-99df-4a101a0c4487', {}); I’m not saying that we never need to plan. I think two ways of living can co-exist – it’s possible to have outcomes-based goals and, at the same time, take decisive action without knowing the exact path with certainty. And I’ll add that it’s a lot more fun to work once I learned to live with the uncertainty. Lessons for Product Managers I think there are many lessons for product managers in this philosophy. Here are a few thoughts for how product managers – especially those in an agile development environment – can embrace uncertainty and live with the inevitable discomfort. Hopefully, these ideas will help you focus on what matters. Make decisions based on outcomes One way to live with uncertainty is to relax about the exact plan, and instead make decisions based on an outcome-driven goal. For example, rather than creating a list of arbitrary and disconnected features for your product, instead, focus on what your desired outcome is for customers – what is the goal you want them to achieve? By focusing on an outcome-driven roadmap, you (and your team) have room to think about new possibilities, about different ways of achieving the goal. Focus on today (and maybe a few sprints out) There’s an expectation of product managers to spell out the vision for our products and what the product looks like one or two years down the road. But it’s problematic if this planning is too detailed. One or two years out any plan is only a fantasy. There’s no way things will go exactly to plan, and the goalpost will probably change along the way. You’ll never achieve perfection. This detailed planning, unfortunately, sets an expectation in your head (and your stakeholders’ heads) that simply won’t come true. It sets up everyone for disappointment. My advice: Don’t plan too far ahead. Focus on the big picture vision in broad terms. Then, focus on what is in your control today to meet that vision. For your product planning, a few sprints out are far enough. Get comfortable with the discomfort Stop spending as much time dwelling on problems at work and what-if thinking. You’re causing stress, which will affect you in all areas of your life. Spend more time working to solve the problems your customers are facing. Those are the fun problems. For all the worst-case-scenario planners out there… cut the negative thinking. Why worry about all the endless gloomy scenarios that your (fearful) mind can conjure up? Plus, I believe that if you expect the worst, you’ll put yourself in a position of being close-minded to recognize new options and opportunities. I’m not saying that you should avoid realistic contingency planning, but truly, the five percent chance of a worst-case-scenario is unlikely to unfold. Spend your brainpower toward an optimistic outcome. Positive thinking really does affect. And your nights will be more restful. Embrace confrontation Another tip: Embrace confrontation. Stop avoiding the conversations you know you need to be having. I’m not saying to pick fights, but rather address conversations directly. Rather than avoiding conflict, micromanaging, or trying to prove someone wrong (controlling), have an honest upfront conversation about the situation. Incorporate stress reduction daily The last bit of advice on another way I’ve found to embrace uncertainty at work and in life: give myself time for exercise and other mindfulness practices daily. I’m finding that when I prioritize this above other items, the rest of my day (life?) is happier, even when I get thrown a curveball I hadn’t expected. Takeaway In the end, will you be a product manager who embraces uncertainty or one who plays it safe and avoids unpredictability? While it’s not a guarantee of success, I think I know which one stands a better chance. Read the Agile Product Manager's Guide to Building Better Roadmaps hbspt.cta.load(3434168, 'f7b97c22-2e32-45da-99f7-1ddcb66e57d3', {});

“Being Agile” and “being predictable” may seem mutually exclusive, at least when it comes to product management. A good sprint cadence creates a predictable frequency of software releases but divining what’s actually in them feels harder. Isn’t the whole point of Agile that we can continuously adjust, making on-the-fly tweaks to seize opportunities? Contrary to some prevailing opinions, managing products in an Agile environment doesn’t mean surrendering planning to the whims of the development team. In fact, Agile can help you be more predictable in some ways. I say this speaking from personal experience. I’m predictable in an agile product environment. Agile ≠ Chaos Those unfamiliar with Agile often have some misconceptions about how it really works. Let’s start by dispelling a few Agile myths: Agile is a free-for-all. Developers don’t code what they feel like, and the software doesn’t just ship at random points of time. Agile is merely empowering the product development team to make iterative progress while adjusting to incoming data. Product managers don’t have a role in an Agile environment. Product managers are still prioritizing features, gathering and synthesizing customer feedback, defining a strategy and product vision, and offering input to the implementation process. None of these tasks go away. You’re no longer writing lengthy product requirements documents with the same exacting detail as before. But developers still both need and value your input. Dates don’t matter. Agile certainly embraces a more fluid approach to project management. But if something needs to ship by a specific date, there’s nothing in the Agile Framework preventing it. In fact, by iteratively developing the software over multiple sprints, chances are the desired functionality will ship with fewer defects. Unlike in the waterfall model, it’s reviewed numerous times during the process. There’s no visibility into what’s happening. With waterfall, there are often project plans detailing what every resource is doing all the time. Anyone can take a peek and know precisely what folks are up to and how things are progressing. This type of visibility may be murkier during the actual sprint, but that’s not the case before and after. Setting sprint goals before a single line of code is written, and retrospectives (or micro-retrospectives) provides an opportunity to dig into what transpired and improve things going forward. Plans are useless as everyone chases the latest shiny object. First of all, once a sprint begins, what the team is working on for those two or three weeks shouldn’t change. The sprint goals remain locked. However, if something new does come up, the sprint planning team (including the product manager) can decide whether it’s worth altering the course for future sprints. hbspt.cta.load(3434168, '4a6bc7bb-4a31-4597-a392-485a84e4207f', {}); Applying Agile Values to Product Management The Agile Manifesto has four core values. These Agile Values are the central tenets that drive everything else. Looking at each one, we can see their potential to make product management (and product managers) more predictable in agile environment. Individuals and interactions over processes and tools At first glance, you may already be scratching your head. How does this make a product manager more predictable? But note that this value uses the word “over” and NOT “instead of.” There is still plenty of room for tools and processes. Agile needs those to be in place to avoid developers idling and things from getting out of hand. But it also elevates the importance of communication and addressing stakeholder concerns. By creating more frequent dialogue, there is an increased level of transparency; when people know what’s happening and why they can better predict what’s to come. There’s no black box, no guessing about when things might ship. In an Agile world, things may change a little more often. But everyone will also know about changes much faster and understand any potential ramifications. Working software over comprehensive documentation By removing the requirement for, well, detailed specifications, teams can deliver updates and new functionality faster. This process shortens the distance from prioritization to ship date. When there are fewer hoops to jump through and hurdles to clear, it’s easier to predict availability. After deciding to build, product managers should have a solid sense of when things will debut. They can then provide clear communication to coworkers and stakeholders. Customer collaboration over contract negotiation Customer-centric companies are committed to doing everything with the best interest of customers in mind. They’re continually processing user feedback and turning those requests and complaints into a better product. Guess what gets in the way of that kind of responsive, ongoing progress? Having to renegotiate a contract every time something changes. When the lawyers get involved, there’s no telling how long things can get held up. Removing those entanglements lets teams focus on building a great product. It removes this common source of uncertainty from the equation. Customers need to pay for things, and a contract might be required. But Agile-friendly companies structure those agreements, so they don’t hinder innovation and iteration. Responding to change over following a plan Of the four values, this one seems the most contentious with our thesis. Plans make things predictable, don’t they? Well, executing a plan properly is predictable. But while the plan’s elements are predictable, you can’t always predict what transpires after a product ships. Adoption, usage, churn, reviews, net promoter scores… there’s no way to know what’s going to happen until it happens. If you’re operating with an inflexible long-term plan, it’s hard to adjust based on the product’s reception. When the cruise ship is chugging along, it’s tough to change course. The best part of Agile is being able to measure, learn, and adjust. That means plans must be a little more dynamic instead of plotting out every single move for the next 18 months. That’s why roadmapping is a predictable product manager’s best tool for managing expectations and hitting target goals while still utilizing the benefits Agile has to offer. Download Strategic Project Alignment in an Agile World ➜ hbspt.cta.load(3434168, 'bfb5032e-5746-4c05-9f2a-54b36ba0e871', {"useNewLoader":"true","region":"na1"}); The Art of the Agile-Friendly Roadmap One reason some product managers can turn negative toward Agile is that their “capstone” project (the product roadmap) might seem at odds with the framework’s fluidity. Well, if your product roadmap is chock full of particular features and exact dates, then you’d be well within your rights to be frustrated. However, including that level of detail and specificity isn’t the only way to build a roadmap. We’d argue that approach isn’t doing anyone any favors, including product managers. Feature-Less Roadmap Instead, product roadmaps featuring goals and themes are usually a much better way to go. Themes illustrate what parts of the product will be worked on at different times, along with the desired outcomes of those efforts. You can escape the trap of promising features and dates—which are inevitably destined to change in an Agile environment—while still communicating the direction and priorities for the product. If there’s concern that a feature-less roadmap is too vague and open to interpretation, add milestones as specific scheduling targets. This change doesn’t guarantee a particular feature will be available by a specific date, but it conveys that you’ll reach a goal by that time. Remember, a roadmap’s primary purpose is communicating a vision for how the product strategy will become a reality. Implementation details and schedules aren’t required to build stakeholder alignment. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); Getting on Board with Agile We get that Agile can sometimes feel like it’s taking control away from product managers and handing over more power and decision-making to the implementation side of the house. But wary PMs should take comfort in a few Agile principles that simplify their ultimate goal of delighting customers. #1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Customer satisfaction is the first principle of Agile. Not “building cool stuff” or “unshackling the creativity of our development team.” #2) Business people and developers must work together daily throughout the project. We used to throw requirements “over the wall” and see how things shook out. But the ongoing dialogue between product and development should result in products meeting expectations and delivering customer value. Moreover, you get the chance to stick your nose into things every day! #3) The most efficient and effective method of conveying information to and within a development team is face-to-face communication. We mean, you might need to attend daily standups. But it also means you’re not spending as much time writing lengthy documents no one ever reads. You can continually assert yourself as the business owner and voice of the customer. You can be Predictable in Agile Ready to learn even more about how Agile and product management can not only coexist but simultaneously thrive? Read the Agile Product Manager's Guide to Building Better Roadmaps hbspt.cta.load(3434168, 'f7b97c22-2e32-45da-99f7-1ddcb66e57d3', {});