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', {});

Sometimes it’s hard to let go of something after discovering it no longer works as you expect. Especially if it’s something you were passionate about. All of us, especially product managers and entrepreneurs, are faced with this occasionally. For example, you’ve put a sprint of development effort into a new feature, and the team has now discovered new information that doubles their estimate of effort. Your Value vs. Effort estimates are out the window, and you’re now questioning whether to proceed. You believed in this feature so much and put so much time, customer interviews, UX work, and now a full sprint of effort into the feature. It’s, well, just hard to let go. I’m here to splash some cold water on you and tell you that all the work and energy you and your team put into this doesn’t matter. What’s done is done, and the only thing that matters is future costs. An essentialist product manager knows this – they know that goals, objectives, markets, and development estimates change. I’m not suggesting that you abandon every project, feature, or idea that turns out to be more difficult than expected. Successful product managers and entrepreneurs know when to persevere despite headwinds. I am saying that the equation has changed, and you need to re-evaluate whether it’s still the right thing to work on. If you say ‘Yes’ to continue to work on this new feature I described at the beginning of the article, you’re saying ‘No’ to other opportunities that might yield better results. Download The Essentialist Product Manager ➜ hbspt.cta.load(3434168, 'be753440-dc4d-40c5-9808-cad744d00a28', {}); The Sunk Cost Fallacy A few years ago, I learned about the concept of the sunk cost fallacy, the mental errors we make when deciding to continue with a project, investment, or even a relationship long after it’s become clear it’s no longer working for us. In sunk cost theory, we will often decide to stay with something because we’ve put time or resources into it. We believe that because we have “sunk” that cost into it, we somehow need to recoup it. That’s a fallacy. In a sense, you’re “throwing good money after bad.” In Thinking, Fast and Slow by Daniel Kahneman, a Nobel Prize Winner in Economics, demonstrated that we choose options to avoid loss. We don’t behave logically when presented with the same choice framed in different ways. Think of a purchase you made a few years ago that you no longer like, but continue to use because you’ve already paid for it. You don’t want the money to go to waste after all. This is the sunk cost fallacy in action. The way to avoid the sunk cost trap is to think about how you feel about that purchase today. I think a great way of thinking is Marie Kondo’s approach to decluttering. She places past purchases on the floor and then asks whether an item “sparks joy.” If not, it’s time to donate it or trash it. The fact that you invested money in the past is no longer relevant in the decision. For product managers, sunk cost theory means that sometimes logic dictates that you stop working on something you’ve invested considerable time and energy into. It might mean that it’s time to sunset a feature or entire product if it is no longer achieving its objectives. I know these decisions to abandon a project are hard. A few years ago, I was faced with this decision on a new feature where I’ve invested a lot of passion and advanced work, and the development team had spent a lot of hours on coding. It was a complex feature. As we kept discovering new cases that had to be a part of the first release, it became clear that the development effort was going to be significantly higher than we expected. It was in our best interest to stop developing that feature and work on something easier to develop and gave customers higher value. I learned lots of lessons about avoiding these situations, to begin with, but that didn’t make the decision any easier, especially when developers I had worked closely with had been putting in the extra effort. Make Go / No-Go Decisions Based on Outcomes It’s never crystal clear whether to stop working on a project or dive in further. One way to manage the inevitable 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? And are there alternatives that would help you more easily accomplish that goal? By focusing on an outcome-driven roadmap, you (and your team) have room to think about new possibilities, about different and possibly faster ways of achieving the goal. Again, the effort you have already invested rarely matters in that decision. [Free book] Backlog Refinement: How to Prioritize What Matters ➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {}); Revisit Prioritization When the equation changes (either the effort you need to exert or the outcome you expect has changed), it’s OK to revisit your priorities and evaluate whether you’re working on the right things. If you use a roadmap prioritization framework such as LIKE.TG’s Planning Board, you can use the weighted scoring model to re-score the project against other items in your product backlog. Product managers know that it’s acceptable to re-evaluate opportunities (and work in progress) to assess if the roadmap still has the right priorities. Does this sound familiar? As a product manager, you’ve finally got a groomed backlog that aligns with the product vision and roadmap. Teams are cranking away and delivering. Everything is on track and then it happens—some unplanned work pops up that is deemed URGENT by someone outside your department. All eyes are on you to set the priority—do you have the tools to do it?[/caption] Focus on today (and maybe a few sprints out). Product managers expect to spell out our products’ vision, and 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 and a waste of time. This thinking can keep you too biased towards completing that plan, rather than asking if it’s the right thing to be working on. There’s no way things will go exactly to plan, and the goalpost will probably change along the way. You’ll never achieve perfection. Unfortunately, this detailed planning sets an expectation in your head (and your stakeholders’ heads) that 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. Embrace Uncertainty to Make it Less Stressful 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 spent a lot of time that, in the end, wasn’t necessary. Uncertainty is uncomfortable, so I often 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. All of the research, time spent writing long documents, and time spent worrying were, well, non-essentialist. 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. 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. 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. And I’ve realized these opportunities somehow align with my most important goals. hbspt.cta.load(3434168, 'd3fa5225-9b84-4eae-8910-23016a8b8f99', {}); Learn More To learn more about letting go of what’s not working and making a more meaningful contribution to your product management career, download my free book, The Essentialist Product Manager. This book blends my passions of essentialism and product management into ideas that you can bring into work and your life to make it all more fulfilling. Download The Essentialist Product Manager ➜ hbspt.cta.load(3434168, 'be753440-dc4d-40c5-9808-cad744d00a28', {});

A few years ago, I was the acting product manager at a startup, developing an enterprise software product. Building the product was hard: it was taking longer to develop than everyone expected (of course). The complexity of what we were trying to accomplish became more evident as each day passed. The product backlog I managed grew daily. I heard requests from customers, domain experts, consultants, our development team, and internal stakeholders. And I diligently added the stories to the backlog. Feature request? Add it to the backlog. Bug found? Add it to the backlog. Corner case we needed to handle one day? Backlog. Declaring Backlog Bankruptcy I diligently prioritized and managed the epics and stories, moving them into the next two or three sprints in the sprint backlog. As the months passed, it became clear there was no way we’d be able to develop what was in the product backlog over the next few months. There was rising frustration from the whole team at the pace of development, partly from the perception that we would never get to everything. And every day, my stress grew as the backlog ballooned. What was the point of diligently managing the backlog when it would be impossible to accomplish it all? Especially when everything a few months in the future would likely be different? So along with the CTO, I made a decision – we’d declare backlog bankruptcy. Every story, issue, bug, and idea that we weren’t planning to release in a near-term sprint, I would delete. Clicking Delete was one of the harder things I’ve done. Over 600 items… gone. But then something interesting happened. There were no repercussions from that decision. And I got a sense of relief after eliminating the cognitive overhead created by the backlog. And after ruthlessly prioritizing and limiting what we added to the backlog, we got the product to market faster. Starting from scratch felt GOOD. The lesson declaring backlog bankruptcy taught me was that if an idea has high enough value for customers, it will come back. It will bubble up to the top. I no longer keep massive lists of all the ideas and things I want to do in the future. Sometimes the simplicity this creates in your product is a positive experience for customers. It also taught me more about the purpose of the product backlog – it’s not a place for every future opportunity. We needed to have a process around what gets added to the backlog. Download the free Backlog Refinement: How to Prioritize What Matters Book➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {}); What Does a Healthy Backlog Look Like? Every organization doing agile software development does it a little bit differently. My approach isn’t for everyone, especially for organizations that need to have more certainty about their product roadmap more than a few months out. For me, I’ve been a part of startups using only some variant of scrum. We plan the stories a few sprints ahead, guided by the epics and themes on the product roadmap. That’s typically enough for any product manager. Ideally, there aren’t hundreds of stories in the backlog. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); When the product backlog is too long, it clouds the vision and creates underlying stress of what’s not getting done. A shorter backlog frees you up to think about what’s most important. It improves creativity. Think in timeframes of perhaps three to six months out. Think about your process for what gets added to the backlog. It’s not for every possible “future” idea that you haven’t necessarily committed to. Yet you still likely want to track ideas and inspiration you’re getting from customer interviews. And you might want to remember who asked you for a particular feature so that you have context. For those situations, I recommend creating a separate “future opportunity” list, so you have a place to add your learnings as you proceed with customer discovery on the idea. After having been involved in launching multiple products over the years it’s clear to me that things you think are super important today aren’t as pressing a few months from now. So by adding every idea to the backlog, you’re doing yourself a disservice. But the stories and epics that you believe will add lots of customer value in the short term go for it. Also, it’s good practice to include bugs, tracking them and peppering them into near term sprints. hbspt.cta.load(3434168, 'a4593ff5-0cd1-4437-86db-eff7703f0d47', {}); Warning Signs Your Backlog is Unhealthy As a product manager, how do you know you’ve entered the dangerous territory with your backlog? Here are some of the things I’ve found to watch out for: Your backlog has become a dumping ground for every random idea from every stakeholder. Sure, it feels good to be able to tell a vital stakeholder you’ve “noted” their opinion, but is the minuscule, incremental cognitive overhead worth it if you do that 100 or 1,000 times? You’re adding ideas that you’d like to implement “someday.” This thinking is long-term, and because everything is guaranteed to change from a product, customer, and competitive standpoint, what’s the point? I suggest deleting anything in your backlog that is older than six months. You’re spending hours every month prioritizing items that aren’t winding up in your short-term sprint backlog. Be thinking every day about what will provide customer value in the short term. Sometimes You Need to Add More Now, to be clear, there are many situations where you might want to add something to the backlog even if it’s not going into a near-term sprint. For example, if your CEO believes a feature has merit, and you want to validate the idea and at the same time let them know you’ve noted it in the product backlog. If you absolutely must keep a long product backlog because it’s necessary from a corporate or process standpoint, try organizing it or grouping it by a theme, such as “near term” and “long term.” That might help a little bit with your sanity. As I mentioned previously, you don’t need to track everything that goes into your product backlog. You can use a separate “opportunity” or idea backlog, such as the Table Layout in ProductPlan. This approach is a great way to capture ideas that you haven’t committed to, and that need further validation. My decision many years ago to declare backlog bankruptcy has yielded so many lessons for me since then. By the way, out of extra caution, before I clicked Delete, I exported my product backlog. And I never went back to look at it. Want to learn how to efficiently funnel backlog items onto the product roadmap?Read Your Guide to Product Roadmaps hbspt.cta.load(3434168, '019ceee1-45ce-493c-8270-b738861f2296', {});

After reading a blog or a book or attending a conference or talk on product management, I’m always excited to try out the new processes and frameworks I’ve learned about. I try to get my team similarly enthused about this endeavor. But when I check in with them in about a week, you can barely tell that anything had changed… mostly because it hadn’t. We tend to fall back into how we were doing things before because that cool new process isn’t meaningful in itself. Without the context for why it’s the most important way to spend our time, it wasn’t worth investing in making a change. So when I tried coming up with my own mindset and mantra for improving product management, I found myself elevating above the flowcharts and execution strategies, looking for something more universal. I wanted to tie together the entire ecosystem and to identify a unifying measuring stick. Something equally applicable to how we prioritize projects as it is to our own careers. Most importantly, I wanted to invest our time in something that will stick and make us all more productive and efficient product teams. Thus came the genesis of IMPACT, where six words can create a lens to reexamine everything a product professional does to ensure it truly is creating an impact and maximizing the opportunity. Meaningful Product Processes with IMPACT Solving Interesting problems that are Meaningful to People, with Actionable plans that are Clear and Testable. That’s what IMPACT’s all about, and if we’re not infusing our processes with IMPACT, then we’re potentially spending our energy on the wrong things. Download IMPACT ➜ hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"}); Interesting By making the problem interesting, we start to build momentum. People need a reason to care, so it’s imperative we tell stories and use our storytelling skills in everything we do. By helping our audience—from sales and marketing to engineering and QA—connect with the customer problem, we will drive better outcomes. We all know that when we focus on value over features, everyone’s happier. The processes with IMPACT that help ensure we’re working on interesting problems include: Product discovery—Helps you better understand the customer problem and interestingly tell that story. Ideation validation—Uncovers more meaning. Market research—Reveals how others tell their stories and perceive the audience. Customer feedback—A door into what’s happening and the trends and evolution in the market. Community involvement—Take any opportunity you can to be where your customers are and get more chances to hear their stories and the challenges they face. Event participation—Talk to people and learn about their lives outside your product for invaluable context. Meaningful Is your solution meaningful to the customer or the business? Remember that excitement about an idea doesn’t always translate to value. The real test is how much they’re willing to pay for it, which truly shows how much they value the solution. Aside from generating revenue, it’s also important to check if the solution aligns with the business’s direction, vision, and values. These processes with IMPACT can help you articulate what’s meaningful to business: Vision Mission—Although it’s often handed down from senior management, it still influences your work. You should be able to articulate how your solution aligns with the vision and mission. Then, prioritize things when necessary to create those connections. Strategy/Strategic Alignment—It should include a definition of value that the product is trying to deliver and what success looks like. Gracefully Saying No—If that really compelling idea doesn’t create meaning, communicate that to teams and customers ASAP, then move on. Roadmapping—Include components of the meaning and value you’re creating, as well as why it’s the right thing to do. People You must figure out the pervasiveness of the problem you’re solving and how many people will care. What will solving this problem unlock in the market? Alongside understanding your research in solving the problem with a specific solution, it’s also essential to know how that investment may accelerate other innovations or solve related problems. This can lead to exponential growth and new opportunities beyond the original scope and scale of the situation. By using as broad a lens as possible, you can also determine if you’re making a big impact for a small number of people or a small impact for a big number of people… both of which are worthy and sound investments, assuming there’s a willingness to pay. These processes can help quantify things: Competitive Analysis—Helps you understand which problems competitors are solving and how they frame them. Not to mention figuring out which ones they’re NOT solving. Market research—Helpful, but determine upfront how much you need to know to be confident to move forward to avoid analysis paralysis. Surveys—Determine who cares about this problem and how frequently it occurs. Jobs To Be Done/Opportunity Tree—Another tool to assess the problem’s pervasiveness and how big a deal it really is. Prioritization—Be sure you’re accounting for the people that will be impacted by value creation. Not catering to the whims of internal stakeholders or finicky edge cases. Segmentation—Use this to define your target market and zoom in on the people who will truly benefit and appreciate the value of your solution. Actionable Coming up with a great idea is pretty easy. Go ask a first grader, and they’ll give you some amazing, innovative ideas… that are completely unfeasible. Your job is to narrow things down to what’s possible, reasonable, and probable. You need to know you can deliver the solution, regardless of how big or important the problem is. These processes can serve as a reality check on what’s truly doable: Squads/Team Composition—More effective teams, benefit the entire company. They must be constructed to get an optimal cross-section of talent and compatible personalities and work styles. Product Development processes—Find time to evaluate feasibility and LOE as early as possible to avoid wasting cycles un impractical pathways. Ideation/Validation—All ideas are welcome, but only those truly actionable given how the solution is framed should be pursued. Dependency Analysis—Larger teams, create more dependencies. Those dependencies increase the odds that the market will pass you by while you sort things out. Clear To build consensus, generate enthusiasm, and win over skeptics, you must be able to articulate the value statement of the solution clearly. This not only will help you secure resources and support for the project, but it also has a downstream impact on sales and marketing, as well as eventually how customers react to the value proposition. Some key processes contribute to making sure the impact of the solution is clear to everyone: Roadmap/Road Show—You want to make sure it’s in front of audiences frequently enough that it’s current, accurate, and remains top of mind. This is especially key when there’s not yet a lot of trust in you or your ideas. It’s also crucial to ensure the roadmap presents the right amount of information for the specific audience. You don’t want to drown them in details or rush through the items they particularly care most about. Alignment—You want to be sure you’re all using the same language, OKRs, prioritization, etc., so you’re all happy with the result. Cross-Functional Collaboration—Evaluate how and when you interact with peers to be sure it’s frequent enough. These interactions should be in settings where they’ll feel heard and can have their concerns addressed. Documentation—People don’t read (except amazing blog posts like this!). Is it accomplishing what you need it to do? Does it match the TLDR summary you included at the top? Testable Humans aren’t very good at knowing what they need, just articulating what they THINK they need. Therefore you must validate that the planned solution is valuable as early as possible. Embrace the sunk cost philosophy early and often. Additionally, don’t be afraid to walk away or initiate a significant course correction at any stage. This is only possible by leveraging processes that put your ideas to the test: Agile Product Development—Agile is about more than replacing waterfall; it’s how you can test, learn, and adjust. With Agile, you can forward efficiently while leaving room for learning moments and making corrections based on those findings. Beta Processes—It’s never too late to learn and change. Set expectations internally and with customers while capturing feedback during beta tests. Thisisn’t just a dress rehearsal but rather a chance to get real-world experience on what you think will work. Iterative Design—Boil things down to the smallest step you can take to deliver value. Then test, learn, and repeat. Usability Studies—You need tools to test and verify. So watching real customers try to use your product is one of the best options there is. For more insights into how you can apply IMPACT to your processes, watch the webinar or download the free e-book today.

We write a lot about the skills that product managers need to be effective. The skills are wide-ranging, from ruthless prioritization, the ability to build consensus with stakeholders, metrics-based decision making, and a host of other business and technical skills. Those tend to be the skills that we and others talk a lot about. But what are the most under-appreciated product management skills? To answer that question, we asked several product managers for their thoughts. Here is what we heard. My Favorite Under-Appreciated Product Management Skill is… I’ll start with one skill I think is under-appreciated: silence. By silence I don’t mean not speaking, but rather, knowing when to listen intently and then speaking wisely. Too often, we believe we’re expected to have all the answers. Silence and listening command respect. Silence works wonders in so many scenarios. When interviewing customers to make sure you truly understand what they think. While working with engineering counterparts or UX colleagues to understand their perspective. When discussing priorities with stakeholders. In these situations, silence (followed by thoughtful responses) shows you’re valuing the opinions and insights of others. Download From Product Manager to Product Leader ➜ hbspt.cta.load(3434168, '67d2717f-2575-4049-9733-48a5e23d53c4', {}); Crowdsourced Picks I solicited input from other product managers on which underrated product management skills they value. I’m sharing their top picks with you. Intuition For Dieter, a product manager, the innate ability to know the right thing to do doesn’t get enough credit. We’ve preached so much about how we should ditch our gut instincts and hunches. We prize data-driven decision making. But we’re sometimes ignoring the value of our own wisdom. “We have hundreds of methods and tools, but sometimes the solutions come from within…” Optimism Product managers must consider the things that might go wrong. We have to set reasonable expectations then mitigate challenges with delivering solutions on time. This caution and prudence are rightly part of the job. But Stef thinks there’s still plenty of room for a rosy outlook. Her top pick for underappreciated skill: “Optimism! This can be better. We can do it. These setbacks aren’t the end of the world.” Multitasking Product managers have so much on their plates. The role requires attention to disparate details. Keeping tabs on KPIs, dealing with a demanding customer, attending standups, updating financial forecasts, and scheduling customer calls might sound like a crazy week for most people. To a product manager, it looks like a Tuesday morning. That’s why product manager Shreya believes multitasking is the most valuable under-appreciated skill for product managers. Product managers exist in an environment full of entirely unrelated demands and deadlines. There’s a lot to do, and sometimes it all seems to need to happen today. Shreya says “The most under-appreciated skill is multitasking. I couldn’t agree more on adaptability and humility. Product Managers need to wear several hats and adapt based on the ‘n’ number of factors and see what the changing user needs are demanding. Then humility helps to understand various possibilities and perspectives.” Problem-solving Products we build solve problems for users. So hopefully, product managers are already in a problem-solving mindset. But sometimes identifying what the problem is in the first place can be tricky. What is the value of solving the wrong problem? That’s why problem-solving ranks at the top of the list for Praseen, a product manager: “For me, I would say the most under-appreciated skill is to ‘figure out and define the problems’ I should be working on. Most of the cases, what you do daily as a PM is undefined, and to add value, one must first learn ‘how to add value.’” Internal stakeholder empathy Empathizing with customers is nothing new in the list of product management skills. Customer-centric organizations put this goal above all others. It (theoretically) drives every decision they make. But for Aniket, there’s a less-discussed form of empathy not getting its due: Empathy with internal stakeholders: “We hear about empathy towards customers, but empathy towards internal stakeholders is equally important, which goes under-appreciated.” Having empathy with the sales team, engineering, and executives is essential. Are product managers as empathetic in these stakeholder engagements as they would be when hearing a customer’s frustrations and wishes? Humility Product managers are subject matter experts. They’ve spent countless hours researching, interviewing, and testing. They know the ins and outs of their products. They’ve crafted compelling value propositions and perfected product positioning. But for Paul, the expertise and confidence generated by that hard work can make you an expert, yet product can always learn more from customers, prospects, and stakeholders. Instead of settling for their current level of knowledge, they should always yearn for more. Paul says “Humility is a critical skill for product managers. Recognizing that what you ‘know’ is only an assumption. Acknowledging that everyone you interact with has something to teach you means you’ll never stop getting better.” Adaptability Product management is not a career for people who want to do the same thing every day. It’s about the furthest you can get from working an assembly line because the demands of the job require the mental nimbleness to switch from one task to the next. These duties span a wide assortment of domains and deliverables. For product manager Carey, rolling with these changes but thriving in that environment is a top unrecognized trait. “The most under-appreciated skill is adaptability: The ability to change, to see change, to re-frame, to re-assess.” Reading the room In a similar vein, product manager Jay also believes a product manager’s ability to change is critical. He particularly values the mental and emotional awareness and dexterity to modify one’s approach based on the specific team you’re working with. “Assess your development team’s maturity and adjust your approach accordingly. With an experienced team: don’t get in their way, ask questions, focus externally. With an inexperienced team: be more assertive and guide the team with best practices you’ve seen work before (assuming you know what you’re doing, of course), check-in frequently, use conservative timelines.” Jay also prizes the capacity for gauging your capabilities for the challenge at hand. “On the flip side, you also need to assess your subject matter expertise and act accordingly. Sometimes you know the customers, market, competitors, etc. Other times, you take over a product where you have far less expertise, and you need to eat some extra slices of humble pie.” hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); Common Threads In reviewing these responses, I found some patterns. There’s a universal emphasis on product managers knowing themselves, being better coworkers, and optimizing their workdays. Most of these were soft skills. I think that’s because product managers depend on others to deliver great products. It’s a collaborative process. Developing and improving the skills that emphasize those aspects of the role is always appreciated. Even if it never shows up on a job description. Want more leadership tips?Read the Career Guide for Product Managers hbspt.cta.load(3434168, '51f4627c-aefd-4981-92a8-41fe12455dbe', {});

Getting change management buy-in is not easy, but we’re only delaying the inescapable when we resist change. Whether it’s driven by economics, technology, politics, or the environment—those massive undercurrents can at best be held at bay before reality sets in. Most organizations are resistant to change by default. Inertia, process, bureaucracy, and governance are often cited as the primary hurdles. But fear and uncertainty also play an often unspoken-yet-prominent role. The bigger the company, the harder it can be to make even the smallest fundamental shifts. Yet, those same large organizations face the most risk by not adapting quickly and intentionally. Smaller, younger firms are by nature more agile, and it’s easier to get change buy-in. But small teams also have less to lose. It’s because larger, older companies have so much more at stake that failing to change can be that much more consequential. For example, my mission in my previous role at a company with over 30,000+ employees was to create a formal change management process or track record to lean on for their CRM system, Salesforce.com, and create a center of excellence around optimizing the firm’s usage of this critical tool. This wasn’t my first time helping an organization improve its Salesforce.com utilization. I’ve done this for multiple firms from a project management/PMO perspective. I’ve also had experience in change management, having spent eight years previously facilitating those. Let’s look at the critical steps that can affect the fate of significant transformations for organizations and successfully change management buy-in. 3 Critical Considerations That Affect Change Management Buy-in 1. Intentional thinking from the start. One fatal flaw many big change initiatives make is letting things “into the wild” before they’re fully baked. However, there might be a follow-on phase to tweak and tailor new tools and processes to the specific impacted groups. Employees won’t always wait until the paint is dry to begin using things. I’ll use Slack as an example. The asynchronous communication tool can be a huge boost for efficiency and collaboration. But when left to their own devices, early adopters can create some bad precedents. In this case, if you don’t create the correct channels and train staff how to use Slack properly, it can get out of control. This can both create bad habits and turn people off to the tool before it’s spun up. Yet, a productivity boon can end up as yet another system people use inconsistently. 2. Anticipating downstream ramifications. Management often initiates changes. A CFO, VP, or a Director thinks there’s a better, cheaper, or faster way to do something. Then they issue an order, and everyone beneath them in the organizational chart deals with the consequences. But managing change by edict is often a recipe for disaster on the ground floor. Executives frequently don’t have much insight into the day-to-day operations of various teams. Thus they can’t begin to recognize the disruption such a shift might cause. The power of working groups is effective. People on the ground are the ones that know what’s going on. Ideally, before a suggested change is even approved, the organization conducts a full forensic analysis of the implications for everyone impacted. That includes employees across the company, as well as strategic partners and even customers. The exercise might uncover potential unintended consequences. Regardless of how big or small it might be, every change requires a proper communication plan. The key is figuring out how you’re going to engage with everyone, drive adoption, detail the benefits, and get everyone on board. It should detail the rationale for the move along with any new or modified processes. If necessary, hold training or QA sessions to ensure the roll-out goes smoothly with minimal turmoil during the transition. 3. Centralized change management. Another key to successful change management is running it all out of a single unit, be it an ad hoc team, a more permanent center of excellence, or a formal PMO. There are many benefits from this kind of organizational structure. First, it breaks down silos in a way that’s often unattainable organically. This unit can both communicate across the organizational matrix and identify redundant efforts. This also puts trained practitioners in charge of structuring and facilitating these activities. Since this is what they do, they have the skills, tools, best practices, and resources to make things as seamless and standardized as possible. They also possess the institutional knowledge and expertise to anticipate friction points in advance thus minimizing potential damage via education and well-documented processes. Most importantly, utilizing a dedicated change management entity gives a holistic view of every major initiative. Regardless of where it began, keep in mind the entire organization and larger ecosystem during execution. Read the Strategic Roadmap Planning Guide ➜ hbspt.cta.load(3434168, '06f68ad8-23a4-4d4e-b15a-e578f0f8adaf', {"region":"na1"}); 4 Steps to Achieve Change Management Buy-in These are the steps for starting things off on the right foot. 1. Survey the landscape. Until you’re on the inside, it’s hard to know who the real players are. Nor do you know where the power centers lie and which baggage and political legacies influence projects. You see which names are being dropped, who people defer to, who made previous critical decisions or threw up roadblocks. At one point, I conducted 40 interviews across various groups to get the land lay but could have done more. Once I’ve identified these stakeholders, then I can understand how to best engage with them. I want to emphasize that it’s imperative to make sure you get things right when evaluating senior management. You need to know their motivations, concerns, and what they value most. Emotional intelligence is such a key factor as a leader. You can talk about industry knowledge and business process. Still, if you don’t have the emotional intelligence of people around you and their drivers, then you can’t figure out how to motivate them in the best way. Additionally, not everyone wants to receive information in the same way, nor do we all process it similarly. I make a point of asking key stakeholders right off the bet how they like to be communicated with, so I can try and meet them where they want to be. 2. Define and articulate a vision. No one’s a fan of change for change’s sake, so the value and purpose of this new role must be crisp, clear, and concise. From the C-suite to the cubicles, everyone should understand why this is important, the steps required, and which benefits the result will bring. Ideally, present tailored messaging for different audiences to connect with their pain points and address their concerns. But to do this, you need to know who you’re dealing with. I use the Insights method. To follow this method, first place stakeholders along a color spectrum, and then based on that designation, you can see what triggers stress along with the best ways to remedy that state. I do this to create the best chances for a successful interaction by acknowledging their feelings and speaking to them constructively. It’s also critical to not immediately dive into the details but rather to establish broader themes that the change will encompass. These themes might seem obvious at times, but a smart and accurate tagline for the initiative can become a helpful mantra and reference point for the project’s life. 3. Get change-buy in with a roadmap. Significant changes have a lot of moving pieces and dependencies. To get change buy-in, a project or program roadmap can help illustrate exactly how everything will happen. Using a purpose-built roadmapping tool is the answer to keeping everything organized and a clear vision to stakeholders. Using LIKE.TG, I capture every possible backlog item to ensure no requests or requirements get lost in the shuffle. In this central repository, we used LIKE.TG to prioritize initiatives. I categorize various things up for consideration before putting them into “buckets” to develop and ship together to create incremental value associated with a particular theme. Then I use a cost and complexity versus impact method for evaluating which items should get to the front of the line, and are happy to slot the low-hanging fruit in the front of the queue to deliver more value to stakeholders faster. With prioritized themes set, I build my roadmap. I use lanes for “containers” of specific items, which allows me to keep the roadmap clean and straightforward. Less is more about the level of detail presented to most audiences, but there’s always the option to drill down and get more refined information on a specific roadmap element. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); 4. It’s all about people. While tools, frameworks, and processes get a lot of attention, at the end of the day, what determines a significant change’s success or failure is how it is embraced and supported by the individual it impacts. The key to change management buy-in is having a clear vision and structure people understand so they see the impact of what you’re trying to do and how it affects them. If you don’t think about how they’re going to go about it, it will never be successful. Without engaging with the people who will use it, that will be your number one failure.

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.

No matter how far into your career you might be, you’re never too old for imposter syndrome to make an appearance. Imposter syndrome is a feeling of inadequacy that persists despite the evident success, according to Harvard Business Review. ‘Imposters’ suffer from chronic self-doubt and a sense of intellectual fraud that override their feelings of success or external proof of their competence. Sound familiar? So, to level the playing field. Even after years into my career as a product leader and founder, every so often, I too suffer from feeling like an imposter. We sometimes need to make decisions with imperfect information. Despite years of experience in this field, it still feels like I am taking risks as I lead LIKE.TG into the unknown. For example, with a recent project, the data wasn’t playing out the way we expected. We had to decide whether to adjust or stand pat, with no clear “right” answer in front of us. As an expert, I should know how to do all this. However, at that moment, I felt like an imposter. However, I’m not — and neither are you. hbspt.cta.load(3434168, '57ff7e42-ccfa-4d9e-b5be-8a0f6ba69363', {}); Why Product Managers are More Susceptible to Imposter Syndrome Product managers (PM) are particularly vulnerable to experiencing imposter syndrome. The nature of our profession is nebulous. There a few reasons why product managers might be more susceptible to the feeling. First, no one gets a degree in “product management.” You don’t train for it. There’s no set path to becoming one. There also isn’t a universal definition of success for product managers. With no pedigree or success validation, it’s natural to feel like an imposter. Colleagues also look to their product managers to have all the answers. Of course, we don’t have them all—nobody does. But we’re expected to know just enough about everything that we can speak intelligently and have an opinion on nearly every subject. It’s important for our role. This creates very high expectations, which plant the seeds of doubt in our minds. Product managers also wield power in their organization, even if it’s not always reflected in the org chart. We have an awesome job to decide what’s in and what’s out. Others have input, but view us as the gatekeeper. Unfortunately, that puts a target for blame if things don’t succeed. This fear of letting people down compounds, so we start to second-guess ourselves. With the weight of the product on our shoulders, we’re the ones to say “no” to various stakeholders. We’ll say no to customer ideas or inform the CEO that their pet project won’t make it onto the roadmap. All while wondering who decided we’re qualified to make that call? hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); How I Overcame Imposter Syndrome (and How You Can Too) There’s no magic bullet, but I have found a few things that helped me get over the hump. 1. Humanize your counterparts Everyone is in the same boat. We’re all human and we all have fears that we have to push through. That means regardless of how much success or failures our peers have had, they’re still putting on their socks one at a time. By humanizing your counterparts, it takes away the fear and intimidation that people are inherently better or more qualified to do your job. 2. Opportunity always comes again Once it’s done, it’s done. Once a decision is made and acted on, then that ship has sailed. If it works out, great! If it doesn’t work out, there will be another chance to make another decision again. At that point, I’ll have learned from this mistake and be even better. There’s always tomorrow. 3. Nobody knows everything As disheartening as it is to realize, I will never have all the answers. Nobody knows everything. We’re all always operating with an incomplete data set and no guarantees. That’s not a defense to solely trust our gut and wing it. However, it does mean you need to move forward and believe that you’ve done enough homework to make an educated decision. Inaction due to uncertainty doesn’t breed innovation. 4. Embrace collaboration Embrace collaboration. The lone wolf product visionary that trusts no one, issues proclamation, and finds success is exceedingly rare. Most successful PMs learn fast that leveraging the knowledge, experience, and instincts of others makes things a lot easier. Not only are you operating with more information, but the decisions you make aren’t yours alone. Moreover, when others are involved in the process, they’re less likely to be resistant to the final decision. 5. Use data to make decisions Metrics matter. You can use data to make decisions and convince others to get on board. This is a valuable tool for PMs. Not everyone is going to trust you. They might have their preconceptions and biases that you’ll be challenged to sway. However, with an argument based on facts instead of feelings, it’s much easier to build consensus, not to mention instilling confidence that you’re on the right path. hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {}); 6. Vulnerability shows you have humility Honesty is the best policy. I prefer to be the person that is open and has good relationships with people versus the one who bulldozes their way through. No one likes a bully or a know-it-all. Don’t be afraid to tell people you’re not positive about something or are still seeking input from others. Others will appreciate if you expose your vulnerability, it shows you have humility. What I’ve Learned from Overcoming Imposter Syndrome as a Product Manager Everyone’s trying to figure it out, just like you. Once you realize and accept this, you can be much more empathetic to others. That forgiveness is contagious, and I’m certain will circle back to you. The only way is to outgrow your doubts. It doesn’t happen overnight. But over time, as you have more successes under your belt and more positive experiences in your rearview, you begin feeling like you belong. Download The Essentialist Product Manager ➜ hbspt.cta.load(3434168, 'be753440-dc4d-40c5-9808-cad744d00a28', {}); It’s hard to do. But, try to stop caring about what other people think. When you’re confident in your abilities, you know you’re doing good work, and are treating people well then it becomes second nature. Now with all that free time you’ve created for yourself, you can do the fun stuff. You don’t need that kind of stress. I’ve met plenty of older, successful people that are still racked with worry. Despite all they’ve accomplished, they can’t be content and convinced of their abilities. To them I say, “Relax, you’ve made it this far, and it wasn’t by accident.” Typically, this industry doesn’t put up with underperformers, so if you’ve made progress in your career, then you’re doing something right. Let your guard down. People can tell when you’re forcing it, so don’t bother putting on airs. You are who you are, and you’ll do a good job or you won’t. Have humility, take the time to figure things out based on the input of others, and have faith that you’ll make the best decisions you can. You can’t lead or even garner the respect of your development team, you have to believe in yourself. Not unreasonably or unwaveringly, but with general faith in your competence and abilities. Without it, no one’s going to have your back or want to follow you into battle. Conclusion Don’t let your insecurities hold you back! If your team didn’t think you could do the job, they wouldn’t work with you. Your requests for help are appreciated and not annoying. Imposter syndrome is real and unhelpful to your career. Moreover, you can beat it. We’ve all been there. When you make mistakes, you’ll learn from them and be better for it.

Magoosh, an online test prep company based in Berkeley, California, calls Net Promoter Score their “reliable referral indicator.” And it is. But that’s not all it is. Although many people think of NPS as a customer success or support metric, product developers in innovative companies, like Magoosh and so many others, are using it to help guide their product roadmaps. What does NPS guide them towards? Aligning product around users’ desired outcomes. “At Magoosh, NPS is one of the most important metrics we track – it helps us determine not only whether students like our customer service and user interface, but also how well our products prepare students for their exams.” – Peter Poer, Director – Product Content How Product Teams are Using NPS to Build Better Products Better Experiences We often see product teams using NPS to track customer happiness (it’s a lean way to get a constant stream of customer sentiment). But, it’s also incredibly useful for helping to prioritize improvements and allocate resources. As Jason Lemkin of SaaStr says – “it is the one metric that keeps SaaS companies honest.” Let’s say your NPS dips. Now what? When NPS alerts you that there is a problem, the qualitative feedback that NPS responders offer can often tell you what the issues are. But, figuring out exactly what went wrong is one thing – finding the best way to solve it for customer happiness is another challenge altogether. Use A/B Testing with NPS This is where Magoosh, a test prep company, brought in A/B testing. They’d identified a falling-off point for their scores after students took the actual GMAT test. Looking into why, they found that passive and detractor students complained that their actual scores were lower than their practice test scores. “Our algorithm was telling students to expect one score, but for some, their official reports were coming back lower – obviously a frustrating experience.” The solution was to fix their score prediction algorithm to be more accurate – but they hesitated: Would it be more frustrating for students to get lower scores on their practice tests, or disappointing scores on the actual tests? Their approach to solving this problem was to use A/B testing to, essentially, optimize for NPS. They deployed the updated algorithm to half of the GMAT students and kept the other half on the previous algorithm. They were able to ask the NPS question and get feedback from currently studying students in real-time, instead of waiting to ask months later after students had taken take their exams and received their results. “Suddenly, NPS had a new use case for us – as a powerful, agile product tool.” Magoosh discovered that the more accurate algorithm had no effect on student satisfaction while studying with Magoosh, which allowed them to roll out the change to all students more quickly. The results: Students from the A/B test who studied with the updated algorithm had their NPS jump 9 points after they completed their exams. Magoosh used NPS data as an agile tool to shape the evolution of their product, prioritize updates, and act as a compass for their product roadmap. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); Effectively Use Qualitative Data for Product Dev The NPS survey asks for qualitative feedback – the “why” behind the number. But there are right ways and wrong ways to use the ‘why’ data you get. And, if not used correctly, you can waste a lot of your product team’s time chasing the wrong leads. Segment by Promoter, Passive, Detractor First, you’ve got to understand where your “why”s are coming from. Promoters? Passives? Detractors? Promoters will tell you what you’re getting right, and maybe, sometimes, what they’d like to see improved. Take their feedback very seriously, because they are your best customers, your target audience, the whole reason you’re sitting in your chair, gainfully employed. Passives and Detractors can be a mixed bag, and here’s why: Some of these Passives and Detractors are not your ideal customers, or target clients. Some of them are just in the wrong place, using the wrong product for their needs. Be cautious about taking their “why”s as directives, you may make your product a worse fit for your Promoters and waste time and money doing so. However, most Passives and Detractors are people who want to love your product. And they graciously contributed their time to telling you what you can do to make their experiences better. Pay attention. Be sure to follow-up with them and thank them all, because they’re doing you a big favor. Segment responses by key user properties Different categories of users have different needs and will experience your company in slightly different ways. You can segment NPS by any property that you have on your users – think about your business drivers. An Enterprise user may have a higher LTV than a Pro plan user. Allocate resources accordingly. Track themes in the feedback Keep score of trends in your feedback, and once you’ve identified a problem experienced by many, A/B test your solution. It is a bit easier to filter and analyze trends with tagging, which gives some structure to qualitative feedback. You can use tags to track common themes related to your customer’s experience of your product or app — such as features, usability, support, pricing, performance. Conduct Additional Research with NPS NPS can help product development teams most when supported with deeper research, and deeper research can be facilitated by NPS segmentation. Hubspot’s product managers, for example, reach out to select NPS survey respondents to investigate further.. In one instance, they found that a mobile app they had created wasn’t getting as many recommendations as they’d hoped, so Hubspot reached out to a subset of users who had a high NPS for the desktop version, but a low score for the app version, to locate the disconnect. Their top tip for reaching out to people is a good one: “Make it clear this request is coming from the product team.” Customers are contacted by a lot of departments – sales, customer service, marketing. But when a call for help comes from the people making the product, it sends a strong message that your company is deeply invested in their success. You’ll get a higher response rate, and very likely, rich feedback. And Don’t Forget to Share Net Promoter Score isn’t just a “customer service” thing, or even a “product development” tool – it’s a tool every team can use to do what they do better. But, sometimes, data stays stuck within the product team, or within customer service. Don’t be afraid to take the lead and close the loop! Pass that data around to other teams. Pass promoters to marketing or sales. You have a wealth of data at your fingertips – don’t forget to share. About the Author Jessica Pfeifer is Co-founder and Chief Customer Officer at Wootric. Jessica has onboarded and advised more than 200 companies on effective use of the Net Promoter System. Prior to co-founding Wootric, Jessica spent six years growing brands at The Clorox Company. She also spent five years in China leading customer experience management initiatives for Aon Hewitt. Jessica holds a BA from Yale University and an MBA from Harvard Business School.

What drives product professionals? They are driven with a hyperfocus on doing things that matter. Product professionals talk to customers and stakeholders to understand what’s important to them. They unpack their pain points to get to the root cause. They know the importance of a prioritization strategy and seek out opportunities to improve upon it. We conduct customer research and stakeholder alignment so we can figure out what matters. Then we identify what we can do in our products that make an impact, be it on the lives of our customers, the growth of the user base, or the bottom line of the business. However, we usually have far more ideas and options than bandwidth and resources. Thus, we realize a real need for prioritization, ranking and sorting, and culling the list. We can then choose a few items worthy of making the product roadmap rise to the top. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); The Downsides of Prioritization Frameworks Because a prioritization strategy is of crucial importance to any product’s success, many different methods exist. Dozens upon dozens of frameworks stand ready for product teams looking for a new way to figure out the best ideas to pursue first, from buy-a-feature to MoSCoW analysis. These frameworks aim to maximize windows of opportunity and optimize product development. It’s a testament to just how tricky, and complex a prioritization strategy can be. Not only do these frameworks have lots of different names and acronyms, but they also require varied inputs. Some rely heavily on customer surveys, while others need a well-structured strategy or clear key performance indicators (KPIs). While these tools often help, there’s an inherent risk to them as well. Product managers may feel forced to ignore critical data points due to the limits of the overall framework. Product managers face limits due to the lack of a solid strategy. Their strategy should align stakeholders on a consensus moving forward. That must be in place well before plugging numbers into a framework. How else can you assess the significance of any item on the business making progress toward its goals? IMPACT sets the stage for better prioritization conversations, moving the team past the “why” and focusing on specific trade-offs and expected outcomes. Watch our webinar on IMPACT: Applying an IMPACT Prioritization Strategy As I’ve covered in many other blog posts, webinars, and our free ebook, IMPACT is a mindset for ensuring you’re doing things that matter. And there’s no domain where that matters more than prioritization. So let’s run through the six elements of IMPACT and see how they relate to this essential aspect of product management: Interesting Not all problems are created equal. Framing and Context provide stakeholders with an idea of how pressing the issue is. Product management must act as a storyteller to engage their colleagues instead of just giving a dry recounting of the facts. Folks get excited and influence how things get ranked. At this stage, the solution must take a backseat to the prevalence and significance of the problem. Meaningful The problems you opt to solve must both move the business forward and provide customer value. You can’t do either without an agreed-upon vision and strategy as well as a quantifiable benefit to the customer. People The focus must remain squarely on the customers, in this case, how many benefits and how significant is the improvement, which creates an apples-to-apples comparison and shifts distractions and edge cases to the parking lot. Actionable Prioritization must consider the realistic chances of solving the problem. Putting something impossible at the top of the queue—despite its possible value—wastes everyone’s time. That requires a little homework with engineering to consider feasibility and level of effort to ensure a balance between resource allocation and weight. Clear It’s tough to consider and adequately rank potential development items without a comprehensive understanding of the problem. Don’t prioritize things until the research is complete and the ideal solution is already in hand. Testable How will you validate that each prioritized item worked once it ships? Without a measurable definition of success, no one knows if it was worth it or if similar projects warrant resource allocation in the future. Did you solve the problem? Is the value clear to end-users and prospects? User feedback confirms those assumptions—or sends you back to the drawing board—so the sooner they chime in, the better. Download IMPACT ➜ hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"}); An IMPACT Prioritization Strategy in Action For an additional lens incorporating IMPACT into a prioritization strategy, you can rank each item being considered based on the six tenets of IMPACT. For each of those six pillars, the team can rate each item on a five-point scale. When evaluating a potential development item for “People,” for example, it might look like this: 1 – This only helps a minimal number of users in our target market. 3 – This allows lots of users with a particular characteristic/within a specific market segment. 5 – Everyone reaps significant benefits, and it expands the pool of potential customers. Each item’s IMPACT is an objective countermeasure to the inertia that plague prioritization. The goal is to make the most of each development cycle, and the work with the most significant IMPACT is the work worth doing first. To learn more about how IMPACT can influence this and other aspects of product management, download the free ebook today!

Product professionals get paid to manage products and services. Delighting customers and creating innovative solutions for their problems dictates our priorities. But this single-minded focus on helping others often leads to a lack of focus on ourselves and our career impact in the product field. And, unlike our products, no one’s getting paid to manage our careers on our behalf. Without intentional and thoughtful strategizing, years and decades can roll by, shifting and stalking our career trajectories while we worry about the success of others. Applying the IMPACT mindset to your career can help keep that career impact trajectory on track by ensuring each move you make gets you closer to where you want to go. From Individual Contributor to Director of Product➜ hbspt.cta.load(3434168, '9110b373-1b93-491b-8f83-5fc4b63b4b89', {"useNewLoader":"true","region":"na1"}); Being a Selfless Generalist is a Good Thing A selfless approach based on customer empathy and satisfying stakeholders is an asset on the job, but less so for ourselves. We suffer from imposter syndrome and deprecate our value because, as generalists, we don’t command the same respect and awe as our more specialized coworkers. But our selfless generalist approach is a superpower in its own right. Seeing the big-picture vision and possessing versatility enables product managers to impact, even when the spotlight falls on others instead. We check our egos at the door because the job demands it, and we don’t want a blindspot to punish the customers we care about. Though it may not grab as many headlines or turn us into “influencers” in our respective industries, it builds the proper habits and work ethic to succeed in our current roles… and our next ones. Unfortunately, this means a scant opportunity to promote ourselves leads to personal “brands” that seldom extend beyond our companies’ walls (physical or virtual). Thus comes fewer opportunities to be “discovered” or headhunted or recruited as we continue operating backstage and behind the scenes. Variety is the Spice of Life and the Bane of Product Management Careers Anyone in product for a few years quickly notices no fixed definition of product management from one company to another. Some view Product as an equal peer to Marketing, Sales, and Engineering, while others tuck it away under a VP of Product Marketing or a CTO. One organization may crown us “CEO of the Product” while another views us as an annoying check on runaway innovation. There appears to be a lack of shared understanding of what Product has to offer and why it’s so necessary. But the net result is seemingly random locations on organization charts, daily duties that differ significantly from one company to another, and product managers hailing from many walks of life. The diversity presents challenges when attempting to: Identify growth opportunities and spot which areas you must improve upon. Translate a written job description into what it would mean for your career aspirations and how it maps to your current experience. Tailor your resume, cover letter, and personal pitch to fit a particular job opportunity. Download Developing a Product Team Checklist ➜ hbspt.cta.load(3434168, 'd8abf101-87a4-49aa-b909-2dcb3743fb8b', {"region":"na1"}); Putting IMPACT to work for your career The IMPACT approach can help you optimize your career impact by assessing yourself in order to improve your career prospects and how you position yourself when you’re actually on the hunt for a new gig. Optimize yourself with IMPACT Whether you’re desperate to change companies, are angling for a promotion, or want to be the best you can be, IMPACT provides a structure for identifying your strengths and weaknesses while identifying areas to work on. Interesting Product managers need an exciting story. How you got to your current role, the career path you took, and where you’d like to go are essential to shaping how others view you. Resumes list the jobs, the degrees, and a few details in bullet points but don’t always recount a compelling story. In a vacuum, your resume or LinkedIn profile might leave people with more questions than answers: Why did you leave Microsoft for some startup that failed? Why did you quit your job at a unicorn and throw in with a medium-sized firm? What made you stay at the same company in the same role for six years? How come you were once a Director, but now you’re a Senior PM? Why did you bounce around between product marketing and product management? To you, those moves all make sense, given the full context of your life and career. But job titles alone don’t do your narrative justice, ergo the need for a story that weaves them together. Connect the dots, find themes and common threads, and spin a tale that leaves others wondering what the next chapter holds in store. Meaningful Product managers do a lot of different things, many of them decidedly necessary. Listing out your responsibilities conveys competence with these tasks and obligations but camouflages your most impactful work. Why you did those things and how you prioritized them is far more relevant. What did those accomplishments mean to you? To your company? To your users and customers? When reviewing your experience, the emphasis must be on how they solved pain points and helped the company reach its overall impact goals. People A product manager’s relationships and interactions with coworkers are fundamental to their success. Those soft skills may not be measurable, but they are essential traits of your current future employer’s values. Are you a good teammate that people enjoy working with? Do you make life easier and better for your colleagues? Are you a great mentor or a devoted protégé? Those skills also come into play when interacting with customers. Can you speak in a language they understand and connect with them where they’re at? Can you engage them in deeper conversations to uncover the root issues and not just the surface-level gripes and wish lists? Talent, intelligence, and creativity aren’t enough for a successful run in Product. You need to be a people person, too. Actionable When listing accomplishments, it’s important to deviate from the laundry-list approach and instead emphasize anecdotes or success stories where you either took action or set the stage for stakeholders to do so. You need to explain beyond merely discussing the completion of a task and what you did with the results. You didn’t just “survey users,” you used that survey data to make recommendations, and one of those recommendations improved a KPI or led to a big deal, which better illustrates the meaningful impact of those actions, not that you just took them. Clear Keep things short and sweet while focusing on real-world examples of how your accomplishments made an impact. Showing off your skills and touting what they’ve done for you in the past are both keys to convincing folks you’re worth adding to their team. Did you bridge gaps and build consensus by creating clarity among stakeholders. Have you inspired the masses with your oratorical prowess? Did you slice and dice the data and create dazzling visuals or unignorable metrics that won people over? Testable The dull, repeatable, everyday elements of your job aren’t the best measures of your competency. You need to get uncomfortable in an unfamiliar situation before knowing if you’re up to the challenge. Push yourself to try new things, learn new skills, and dive into new areas of interest. Measure your faculty with this new material and see if you’ve got the resilience to power through when things get tricky. Watch the full webinar below: Putting IMPACT Into Action On a Job Hunt With your elevator pitch nailed, the next part of advancing your career is assessing new opportunities. Once again, IMPACT can help by weeding out postings that won’t be a great fit while zeroing in on the good ones. Job descriptions aren’t just ads; they’re problem statements you’ve yet to unpack. What problem is this company trying to solve? Where can someone add value and make an impact? Are they mentioning customers and data? Which verbs do they use? Are they super specific in what they’re looking for or searching for an athlete to grow into the position and evolve with it over time? Of course, what they say they want isn’t always what they need (or want), but it is a sneak preview of how they view product management today. It might be wrong and negotiable, but it provides a good glimpse of their current mindset. With this as a starting point—and the remainder of the interviewing process as a series of additional opportunities for further digging—you can better ascertain the expectations for the role, your fit for the opportunity, and whether it will provide you with enough chances to make a true career impact. You want a job where you’re motivated to succeed, not just happy to collect the paycheck. A Position with Purpose The product offers us the opportunities to change lives, fuel businesses, and transform organizations. The problems we solve may be trivial or life-changing, but they all have the chance to impact our product’s users and customers. Finding impactful opportunities throughout our career means more than just a job we enjoy or a product we’re passionate about. It gives our entire lives purpose and adds to the story of our career, adding new chapters with every step we take. To learn more about how IMPACT can help with your career and other dimensions of product management, download the free ebook today. hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"});

Every individual has a unique way they perceive and interact with the world around them. Recent reports claim that diverse organizations outperform their competitors by 35%, according to a recent report by McKinsey Company. The report also concluded that gender-diverse organizations outperform their nearest competitor by 15%. McKinsey Company’s report proves that product managers need to create an equitable user experience for their customers. Throughout life, we bring our preconceptions, biases, fluencies, capabilities to the table. As a consumer, that’s usually not a huge problem. We find ourselves judging our own experiences, purchases, and solutions. If a product doesn’t meet our needs, we can find something more suitable for our needs. Of course, not all individuals have the freedom of choice. When your boss requests that you use the new ERP system, workplace etiquette requires you to follow up on the request. When the bus or subway, or train pulls up to the stop, we can’t request a different model that’s a better fit. We must do our jobs and get to our destinations. So what happens when that ERP system uses terminology employees don’t understand? And what if the bus doesn’t have a lift for our wheelchair? Unfortunately, users may find themselves in a precarious situation due to decisions made by a product team. Software that remains intuitive and self-explanatory to novice users remains the most accessible. Product managers who do not account for these may get left behind by a market inclined to buy a product from a fair organization. What Is an Equitable User Experience? You can’t expect to make everyone happy all of the time. Product managers know this self-evident truth quite well. That’s why we define our target markets and user personas. Product managers understand that building a product that satisfies everyone remains impossible. Chasing after all those edge cases leads to ballooning costs and lengthy delays for increasingly diminishing returns. Why is an equitable user experience important? Our ability to dismiss different cohorts can drive us to whittle down our total addressable market. An effective manager who utilizes a product roadmapping tool to strategize with their product team maintains a viable product. Product managers ensure that the product supports the financial stability of the organization. Moreover, they rule out unlikely use cases and vertical markets that don’t align with our strategy. As product managers, we have to make choices that narrow the usability of our products. These choices don’t end with unusual applications. A product manager’s decision can increase the degree of difficulty for usersProduct teams rarely set out to create a product for a small subsection of the population. Instead, we would like to provide our customers with the best product possible. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); Why should you broaden the scope of your product? Understanding the scope of your product influences the downstream decisions. As product managers, we understand the importance of thinking about who out there could use our product. When we do not broaden our market share, we isolate many subsections of society. We often don’t realize how limiting those decisions might be. When we look around at our peers, our friends, our neighborhoods, and our families, we only see a sliver of the full population. We design for the “average consumer, ”which remains a flawed concept. Product teams need to develop products for a range of physical, cognitive, sensory, cultural, and socioeconomic variances. Furthermore, your product should create a fair user experience. Oftentimes product teams fail to solve use cases or accommodate everyone. A product’s financial viability may also cause issues. As a product manager, you might determine that costs limit your ability to create a full user-friendly experience. Developing a More Equitable and Inclusive Product Experience Brittany Edwards—digital product manager and co-founder of Incorp[​HER]ated—believes product teams must think beyond the types of people they see in the office. Some of this comes with who we choose to hire into our product teams, to begin with. “If you don’t have a diverse organization and you’re not sure about what you don’t know or aren’t ready to acknowledge it, then the research you do is where you’re comfortable,” Edwards said in a recent webinar on Product Management Trends. Companies need to break free of this unintentional-yet-ingrained limited perspective. Product teams must make a concerted effort to venture beyond their comfort zones. “It’s all about identifying who your customer base truly is,” Edwards said, “Really push the boundaries of your definition of your customer.” Product teams set out to understand what their users find difficult within the context of the product experience. That means talking to people, conducting usability sessions, and adopting best practices. If you search for opportunities to improve, things can always get better. Of course, this inclusiveness can only go so far while still being practical. “It’s okay to be somewhat exclusive,” Edwards continued. “But acknowledge that and the risks that are associated with it.” Potential roadblocks towards inclusiveness. With so many avenues to increase inclusivity, there’s no shame in using an ROI as part of your analysis. If you can increase your target market by a few percentage points, you don’t have to worry if it’s fair. Instead, view every effort as a net positive. You need to expand your potential market by doing the right thing. You should work to ensure your “starting point” remains unbiased. Challenging assumptions and remaining thoughtful in the design process. Yet this only happens when there is time, space, and permission given to think about these unconscious defaults. As a product manager, you need to unpack the processes that lead to exclusion in the first place. Accommodations Get Used in Unexpected Ways The American Disabilities Act has been shaping public life since 1990. Federal and state regulations mandate that buildings provide ease of access for those with disabilities. These sets of regulations make life easier for those suffering from a wide range of physical and mental limitations. They’re not the only ones who benefit. Parents with strollers also use those ramps, as well as shoppers with arms full of groceries. ADA-driven changes provide value to everyone who uses them. They’re also an important reminder that product decisions made to accommodate one part of the market can end up benefiting many more people. Some product managers may view the inclusion-driven activity as a costly exercise. Yet, it can enhance the user experience for much broader swaths of customers. Providing an option to increase the text size can attract older users, as well as those who have vision problems. Expand Your Product’s Horizons Your inclusive design can sometimes cause more problems and slow down innovation. For example, your product team may have to add in speech-to-text interfaces or develop a VR system that has accessibility features for individuals with a disability. However, every step taken to make your product more accessible increases its utility for a broader set of users, creating organic growth opportunities for your product. Consumers will continue purchasing from you if they feel that the product provides accessibility, as well as functionality. By innovating the accessibility of your products, you have the opportunity to push your competitors towards producing an equitable product. Over time, inclusive design becomes routine. “What about this?” and “what about that?” become welcome questions during ideation, design, and development. Take the next steps toward creating an equitable user experience by: Hiring more diverse teams Talking to a wider variety of customers and potential users Creating space and time to hear about a broader set of concerns and issues Ensuring usability tests include different ages, races, shapes, sizes, genders, sexualities, geographies, educational levels, income ranges, and physical and cognitive capabilities Asking your teams what else can we do to make things simpler, more accessible, and friendlier to as many constituencies as possible Inclusivity and equity are about more than paying lip service to vocal minorities or being politically correct. There are a billion people with disabilities. The LGBTQ community has $3.6 trillion in buying power. The U.S. population is more than 30% Black and Hispanic. Lastly, it’s simply good business to broaden your target market, and the brands doing so are seeing positive returns on their commitments to this practice. Don’t be caught on the wrong side of history with a product designed to serve only a small array of society rather than a universal equitable user experience.

The secret to product planning starts with “why.” In some cases, product planning focuses on what we’re building, completing, and what’s up next. The rationale for all that activity isn’t simply to cross things off the list or pump out new functionality. It’s about turning a vision into reality. But connecting the dots between the activities of a particular product development team and the overarching corporate vision can be a bit of a stretch for those not steeped in the strategic exercises occurring at the top of the organization. How a particular widget maps back to a vision of “transforming the world of peer-to-peer finance” or “unlocking the potential of idle computing power” or whatever can be a heavy lift. To unlock the secret to product planning, product professionals need to develop a clear product vision. Putting Vision into Context In an ideal world, everyone should understand the organization’s overall vision. It’s beneficial to take a top-down approach. Breaking that vision down into smaller pieces becomes more relevant to different parts of the business. It’s not always easy to map the contents of an individual sprint. However, a high-level strategy for an entire company remains possible. The significance of each element of the strategy increases stakeholder alignment. Alignment creates motivation and enthusiasm amongst the teams. They can now realize how their contributions impact the big picture. This increased fidelity must begin at the planning stages, creating the platform for ongoing alignment and teamwork. At LIKE.TG, each engineering team has a vision. That aligns with the product vision, which in turn aligns with the company vision. Though there is no one secret to product planning, this concept comes close. It enables engineering teams to understand how the world looks different if they’re successful. Planning for Outcomes While Preserving Accountability Each squad understands its purpose and objectives. The squads remain grounded on a shared understanding of what success looks like to them. Boiling down grand sweeping statements and visions to something tangible is key to bridging that gap. Each member should answer the question: “What will our customers be able to do tomorrow that they can’t do today?” This very concrete, specific ideal guides their actions without being too prescriptive. For example, it might be that customers can now automate more of their daily updates. The update doesn’t spell out precisely what that might look like or how it will get built. However, the vision is crystal clear. The product manager can then fill in more details. Consequently, delivering value is more important than a list of features. That value must also be measurable to ensure the team achieves its goal of executing its vision. Alignment around how we know our customers’ lives got better is just as crucial as intending to improve things. That shared definition of success keeps everyone pointed in the same direction. Moreover, it creates a benchmark for ongoing, measurable refinement. Finding the Sweet Spot While strategic thinking and keeping everything in perspective are product managers’ strong suits, that’s not always the forte for everyone in the organization. They may not have the impetus or motivation to do so, and they may also lack the information and context even if they did. Therefore it’s up to product managers to determine the right level of vision required to give everyone enough autonomy to move forward without overwhelming them. This task only becomes more difficult as the scale of the vision expands thanks to growth. Creating a shared vision For example, at LIKE.TG, our vision is to help companies accelerate product outcomes. By presenting a shared vision and securing buy-in, the product calibrates the squad to be on the same page. Presenting roadmaps tailored to the audience in question provides a helpful resource to paint this picture as well. That’s why we keep narrowing things down. We know this team in particular’s contribution to accelerating product outcomes centers on collaboration within the application. We briefly explain how collaboration contributes to the vision, giving product development further insight into the purpose of their work and not just the “what.” Shrinking the view and scope of things isn’t typically how the product discusses vision, but departing from grand narratives and concentrating on specifics is what the implementation teams need to succeed. Like with IMPACT, it conveys what’s meaningful about the work, giving the team a better picture of how their individual and team efforts plug into the larger strategic objectives and customer experience. It turns abstract platitudes into concrete action plans and tasks. Download Strategic Project Alignment in an Agile World ➜ hbspt.cta.load(3434168, 'bfb5032e-5746-4c05-9f2a-54b36ba0e871', {"useNewLoader":"true","region":"na1"}); Planning for the Future Without Becoming a Feature Factory Company missions rarely change. Visions for the business typically extend five or ten years into the future. And strategies tend to cover the next year or two. Things get more specific the closer they are to the present. But while missions and visions are vague, strategies and roadmaps tend to get more detailed out of necessity. Things can’t remain fuzzy once it’s time to build stuff, and that granularity helps teams plan accordingly and deliver functionality that adds customer value. However, one shouldn’t confuse increased specificity with rigidity. The secret to product planning is to remain vision-driven and customer-centric. Product teams should stay flexible at every stage of the product planning process. Our product vision gets more precise as we continually learn more about our customers, their needs, and the overall market dynamics. That’s where a roadmap based on themes versus specific features comes in. We’re all aligned about what areas we’re focusing on and our goals for each effort, but there’s still plenty of wiggle room on the details right up until implementation kicks off. Maintaining Excitement and Energy. Building products is still a job, and work remains an obligation versus a choice for most. However, imbuing the team with a sense of purpose can elevate the team above the daily grind and get them pumped up for what they can achieve. By continuing to build what customers need and not just the promises in an outdated vision, strategy, or roadmap, we keep that joy of delighting customers close to the surface. We know we’re prioritizing what matters and spending our cycles on enhancements to the product experience that genuinely make a positive difference. And we won’t just build things because months or years ago, we happened to say we would. The process only works well with the suitable structures in place. A foundation built on increasingly relevant visions grounds the work in its purpose. Visual roadmaps tie each project, task, and sprint back to each level. This transparency builds trust and alignment while leaving room for flexibility as situations change and conditions evolve. It doesn’t happen overnight, and each stakeholder might warm up and embrace this approach on their timeline. By creating a solid understanding of the process and delivering a relevant vision for each team member, the team has established a product plan everyone can get behind. The secret to product planning will continuously evolve. hbspt.cta.load(3434168, '3be75db1-0d50-46dd-b222-ce0aa84f6b08', {"useNewLoader":"true","region":"na1"});