Reframing Backlogs and Roadmaps for Good

Heavy backlogs and onerous roadmaps have long been a weight that product managers have had to bear. Ask any product manager what they do with their time, and many will tell you about the hours they spend managing one or both of these artifacts. Problem is, there’s no inherent value in the backlog or the roadmap. They are just tools that may or may not be helping you get where you need to be as a product manager, which is, ideally, understanding the problems your customers face, and discovering ways to solve those problems in a way that’s beneficial to your business. 

Backlogs and roadmaps are filled with traps and tensions. If done badly, they hold back good product teams and cloud judgement. I’ve seen product people spend more time shuffling things around their backlog or beautifying their product roadmap than talking to customers or diving into the problems they could be solving.

I can see why there’s often a reaction to fully ditch roadmaps and backlogs. This is the stance that the folks at Basecamp take, and Marty Cagan as well. But these approaches leave something to be desired, too. It leaves a hole where a reframed roadmap and backlog approach would help.

The ShapeUp methodology from Basecamp argues for no product roadmap. This is because a roadmap comes with expectations and we live in a world of uncertainty. Instead, it suggests that you have a ‘portfolio of options’, with no promises, no list of things that will be done. I think ‘portfolio of options’ is a fine name for this, and the approach is sound.

ProdPad’s lean roadmaping format aligns with this. Like the ShapeUp method, a lean roadmap isn’t a list of things to do, or promises being made. It’s what you would call a ‘prototype for your strategy’.

Reframing product roadmaps

When you first conjure up an idea for a new feature or interface, you don’t run straight to dev with a finished design. You start with a prototype. Perhaps even just some scribbles on a napkin or sheet of paper that you show to a customer or a teammate for feedback. You get feedback that your scribbled interface could be flipped like this or like that, or perhaps it needs some copy there. You throw out the piece of paper and start again, making a slightly better iteration of the same interface, based on the feedback you got. The value wasn’t in the paper, after all… the value was in the conversation that having the paper prototype enabled. 

Likewise, your roadmap itself isn’t of value, and you should expect it to be thrown out and iterated upon. The value is in the conversations you can have around it, once you use it to outline your assumptions.

A roadmap is a place where you jot down your assumptions about business problems, challenges, and opportunities. It is a starting point for a conversation with others in your team. Sharing your roadmap with a colleagues is a great way to stay aligned. They might have a very different idea about the product’s direction the product was going in. If this is the case then it’s very good you had that conversation now and not months later. 

By collectively sharing assumptions about the strategic steps your product will take, and checking those with your team and customers, you’re able to create a more robust version of your strategy…. just as iterating many times on a paper prototype and getting lots of feedback will land you with a better design over time.

Prioritizing at the problem level is powerful. Having a lean roadmap means you can identify problems long before they disrupt your business, and helps you wield your company’s resources and time to your advantage. 

Your roadmap shouldn’t try to be a detailed plan capturing every last movement. It should be scrappy and flexible, and linked to outcomes you want to see and experiments you might try, and be ready to be bashed apart as you learn more about the space you’re in. 

The value isn’t in the product roadmap itself. The value is in the roadmapping.

The danger in saying ‘No Roadmap’ is that I’ve seen teams take this literally, and actually operate without a roadmap of any sort. No way of laying out their options or checking their assumptions. No valuable conversations around whether they agree on the direction of the business. This leads to teams getting led by the noise in their backlog, prioritizing whatever seems easy, convenient or important at the time, but never actually taking a step back to prioritize at the problem level as you would on a roadmap.

Reframing the roadmap is a power move, and it benefits the product manager. When we first launched our lean roadmap, we weren’t sure if we could or should still call it a ‘roadmap’. After all, it didn’t look like any of the roadmaps we’d ever seen before. 

However, we stuck with it, and we realised something interesting: product people loved it because it was called a roadmap. A legitimate online tool allowed them to build a ‘roadmap’ that, for the first time, didn’t hold them back from focusing on the important parts of their product management job. They’re still doing a ‘roadmap’, like their boss had asked them to, it was just reframed into something more useful. They weren’t forced into an uncomfortable situation where they had to make the case for giving a hard NO to a roadmap. 

Years on, the lean Now/Next/Later format of the roadmap is so ubiquitous it’s generally accepted by bosses as a legitimate roadmap format with no qualms.

Reframing product backlogs

We’ve done something similar with backlogs. This article started because of Jason Fried’s ‘NO backlogs’ comment on Twitter, and again, I get where he’s coming from, but we take a different approach. 

Most backlogs suck. When you think of a backlog, you think of a vertigo inducing pile of tickets that’ll never get finished, most of which aren’t even good ideas, living under a bridge in Jira. 

Where ShapeUp says NO backlogs, we reframe it: Split your backlog

Jira, for example, isn’t an inherently bad tool. It’s just used for the wrong things. It’s been leaned upon to hold our every wish and story for the product, and it becomes this black hole where innovation goes to die. There’s a reason why every product manager I know hates Jira. But Jira’s actually fine if it’s used for what it’s meant for: managing a list of development tasks to be tackled. It’s a development project task tracker. Everything in Jira should be approved, and ready to go, and have enough detail that any developer can pick up a ticket and start working on it. Nothing should be in Jira if it’s not a task to be done. This is your development backlog

Your developers can decide for themselves how they work through this. Scrum. Kanban. Scrumban. Whatever. Ideally, short iterations so they don’t disappear on you for months on end, but otherwise, they can be pretty self-led in this space.

What about everything else? All the ideas, bets, experiments, etc. that haven’t been prioritized or spec’d. We call this the product backlog or idea backlog. Marty Cagan coined the phrase opportunity backlog. This is a space for understanding all of the opportunities, potential solutions, and their connection to the problems that the business faces. And that’s a really key point. The point of this backlog isn’t to prioritize at the individual idea level. There is no stack ranking or weighted score algorithm in the world that will tell you what order you should build that list of things you’ve collectively thought up. One of the biggest mistakes that we see happen is trying to treat the product backlog like a simple list that can be prioritized. 

Instead, the roadmap is used to prioritize at the problem level. Ideas are surfaced to connect those problems as ways they might solve each.

The ShapeUp way suggests that if your ‘bet’ or idea doesn’t make it into the development cycle it’s up to the person who suggested it to hold on to it and present it again if it’s worth it in the future. This is where they’re no backlog concept comes from, but it’s not ‘no backlog’. It’s just a bunch of other people’s backlogs instead. It assumes that individual have a way to keep tabs on bets they want to bring back to the table. Therefore, managing this personal backlog of ideas efficiently. They are removing the responsibility of the team to manage the backlog and putting it on the individual. This will come with mixed results as some people will be able to organize better than others. Everyone will have their own system for how they keep tabs on the bets/ideas they have for the business. 

This format of bringing pitches to the table also gives undue power to the loudest in the room. The concept of a meeting at a table where people pitch their bets and the strongest pitch wins, lends itself to HiPPOs running the show. As they say in the ShapeUp book, “the betting table gives the C-suite a “hands on the wheel” feeling” – which might be magic in the right company with a certain make-up of leaders, but could easily lead to hard times in many others. After all, many product teams already struggle with wrestling control over product from well-meaning but often clueless c-suite and founders. The betting table runs the risk of excluding those who might feel shy or unempowered to speak up for their ideas versus their colleagues in a somewhat stressful environment.

The ProdPad way is to have a collaborative, helpful backlog that’s transparent to the team. Why is this so powerful?

Anyone in the team can add to the backlog, and see what else is in the backlog. They can also see the backlog drivers. What are the top priority problems and objectives? Which ideas are most important to customers right now? Where have previous ideas ended up, and what makes for a successful idea? 

This helps people in the team understand where ideas come from, and very importantly, where their ideas end up. It helps them build trust in the product management process, which was previously a black hole. They can see how and why certain ideas make it through to production and others don’t. It helps to demystify the product management process, and allows the team to create and share a process by which problems are prioritised and ideas are selected to match.

This is not your old school backlog where things go to die. Combined with the fact that it’s collaborative and transparent by nature, the ProdPad backlog also has a ton of helpers built in to help the product team decipher what’s in the backlog, and quickly pinpoint great opportunities that will solve the right problems.

Automatic matching of customer problems to potential solutions

ProdPad's DotBot is here to help

ProdPad’s unique DotBot automatically spots ideas that might solve customer problems, or customer problems that might be related to ideas, and flags them up so the product team can join the dots. It’ll also catch your duplicates and help you link and merge similar ideas so your backlog never gets too hairy.

See customer feedback connected to ideas in the ProdPad Sandbox.

Spot and track opportunities with the priority chart and workflow views

The prioritization chart in ProdPad
The Kanban workflow in ProdPad

See the idea chart view and the idea workflow view in the ProdPad Sandbox.

Prioritize at the problem level, linked to OKRs on the roadmap

You won’t find weighted scoring algorithms or stack ranking in ProdPad. Why? Because they don’t work and they are doing your backlog a disservice. It is a source of knowledge to draw from when the time comes to solve problems. And it’s at the roadmap level that you outline and prioritize those problems. Roadmap initiatives in ProdPad are connected to Objectives and specific trackable Key Results, and are connected to the ideas (or what I like to think of as experiments) you’ll try in order to to solve each problem. 

The idea pipeline on ProdPad's product roadmap feature

See a roadmap card with ideas pipeline in the ProdPad Sandbox.

All in all, the ProdPad way works really nicely with the approach that ShapeUp presents. Both come from the same place of rejecting heavy, onerous backlogs and roadmaps in exchange for something new. The key differences come down to semantics and how each approach positions the alternative. 

As shown by this happy ProdPad customer, ProdPad can play a key role in helping your team take advantage of the best of the ShapeUp approach: 

The post Reframing Backlogs and Roadmaps for Good appeared first on ProdPad | Product Management Software.

Reframing Backlogs and Roadmaps for Good

Heavy backlogs and onerous roadmaps have long been a weight that product managers have had to bear. Ask any product manager what they do with their time, and many will tell you about the hours they spend managing one or both of these artifacts. Problem is, there’s no inherent value in the backlog or the roadmap. They are just tools that may or may not be helping you get where you need to be as a product manager, which is, ideally, understanding the problems your customers face, and discovering ways to solve those problems in a way that’s beneficial to your business.

Backlogs and roadmaps are filled with traps and tensions. If done badly, they hold back good product teams and cloud judgement. I’ve seen product people spend more time shuffling things around their backlog or beautifying their product roadmap than talking to customers or diving into the problems they could be solving.

I can see why there’s often a reaction to fully ditch roadmaps and backlogs. This is the stance that the folks at Basecamp take, and Marty Cagan as well. But these approaches leave something to be desired, too. It leaves a hole where a reframed roadmap and backlog approach would help.

The ShapeUp methodology from Basecamp argues for no product roadmap. This is because a roadmap comes with expectations and we live in a world of uncertainty. Instead, it suggests that you have a ‘portfolio of options’, with no promises, no list of things that will be done. I think ‘portfolio of options’ is a fine name for this, and the approach is sound.

ProdPad’s lean roadmaping format aligns with this. Like the ShapeUp method, a lean roadmap isn’t a list of things to do, or promises being made. It’s what you would call a ‘prototype for your strategy’.

Reframing product roadmaps

When you first conjure up an idea for a new feature or interface, you don’t run straight to dev with a finished design. You start with a prototype. Perhaps even just some scribbles on a napkin or sheet of paper that you show to a customer or a teammate for feedback. You get feedback that your scribbled interface could be flipped like this or like that, or perhaps it needs some copy there. You throw out the piece of paper and start again, making a slightly better iteration of the same interface, based on the feedback you got. The value wasn’t in the paper, after all… the value was in the conversation that having the paper prototype enabled. 

Likewise, your roadmap itself isn’t of value, and you should expect it to be thrown out and iterated upon. The value is in the conversations you can have around it, once you use it to outline your assumptions.

A roadmap is a place where you jot down your assumptions about business problems, challenges, and opportunities. It is a starting point for a conversation with others in your team. Sharing your roadmap with a colleagues is a great way to stay aligned. They might have a very different idea about the product’s direction the product was going in. If this is the case then it’s very good you had that conversation now and not months later. 

By collectively sharing assumptions about the strategic steps your product will take, and checking those with your team and customers, you’re able to create a more robust version of your strategy…. just as iterating many times on a paper prototype and getting lots of feedback will land you with a better design over time.

Prioritizing at the problem level is powerful. Having a lean roadmap means you can identify problems long before they disrupt your business, and helps you wield your company’s resources and time to your advantage. 

Your roadmap shouldn’t try to be a detailed plan capturing every last movement. It should be scrappy and flexible, and linked to outcomes you want to see and experiments you might try, and be ready to be bashed apart as you learn more about the space you’re in. 

The value isn’t in the product roadmap itself. The value is in the roadmapping.

The danger in saying ‘No Roadmap’ is that I’ve seen teams take this literally, and actually operate without a roadmap of any sort. No way of laying out their options or checking their assumptions. No valuable conversations around whether they agree on the direction of the business. This leads to teams getting led by the noise in their backlog, prioritizing whatever seems easy, convenient or important at the time, but never actually taking a step back to prioritize at the problem level as you would on a roadmap.

Reframing the roadmap is a power move, and it benefits the product manager. When we first launched our lean roadmap, we weren’t sure if we could or should still call it a ‘roadmap’. After all, it didn’t look like any of the roadmaps we’d ever seen before. 

However, we stuck with it, and we realised something interesting: product people loved it because it was called a roadmap. A legitimate online tool allowed them to build a ‘roadmap’ that, for the first time, didn’t hold them back from focusing on the important parts of their product management job. They’re still doing a ‘roadmap’, like their boss had asked them to, it was just reframed into something more useful. They weren’t forced into an uncomfortable situation where they had to make the case for giving a hard NO to a roadmap. 

Years on, the lean Now/Next/Later format of the roadmap is so ubiquitous it’s generally accepted by bosses as a legitimate roadmap format with no qualms.

Reframing product backlogs

We’ve done something similar with backlogs. This article started because of Jason Fried’s ‘NO backlogs’ comment on Twitter, and again, I get where he’s coming from, but we take a different approach. 

Most backlogs suck. When you think of a backlog, you think of a vertigo inducing pile of tickets that’ll never get finished, most of which aren’t even good ideas, living under a bridge in Jira. 

Where ShapeUp says NO backlogs, we reframe it: Split your backlog

Jira, for example, isn’t an inherently bad tool. It’s just used for the wrong things. It’s been leaned upon to hold our every wish and story for the product, and it becomes this black hole where innovation goes to die. There’s a reason why every product manager I know hates Jira. But Jira’s actually fine if it’s used for what it’s meant for: managing a list of development tasks to be tackled. It’s a development project task tracker. Everything in Jira should be approved, and ready to go, and have enough detail that any developer can pick up a ticket and start working on it. Nothing should be in Jira if it’s not a task to be done. This is your development backlog

Your developers can decide for themselves how they work through this. Scrum. Kanban. Scrumban. Whatever. Ideally, short iterations so they don’t disappear on you for months on end, but otherwise, they can be pretty self-led in this space.

What about everything else? All the ideas, bets, experiments, etc. that haven’t been prioritized or spec’d. We call this the product backlog or idea backlog. Marty Cagan coined the phrase opportunity backlog. This is a space for understanding all of the opportunities, potential solutions, and their connection to the problems that the business faces. And that’s a really key point. The point of this backlog isn’t to prioritize at the individual idea level. There is no stack ranking or weighted score algorithm in the world that will tell you what order you should build that list of things you’ve collectively thought up. One of the biggest mistakes that we see happen is trying to treat the product backlog like a simple list that can be prioritized. 

Instead, the roadmap is used to prioritize at the problem level. Ideas are surfaced to connect those problems as ways they might solve each.

The ShapeUp way suggests that if your ‘bet’ or idea doesn’t make it into the development cycle it’s up to the person who suggested it to hold on to it and present it again if it’s worth it in the future. This is where they’re no backlog concept comes from, but it’s not ‘no backlog’. It’s just a bunch of other people’s backlogs instead. It assumes that individual have a way to keep tabs on bets they want to bring back to the table. Therefore, managing this personal backlog of ideas efficiently. They are removing the responsibility of the team to manage the backlog and putting it on the individual. This will come with mixed results as some people will be able to organize better than others. Everyone will have their own system for how they keep tabs on the bets/ideas they have for the business. 

This format of bringing pitches to the table also gives undue power to the loudest in the room. The concept of a meeting at a table where people pitch their bets and the strongest pitch wins, lends itself to HiPPOs running the show. As they say in the ShapeUp book, “the betting table gives the C-suite a “hands on the wheel” feeling” – which might be magic in the right company with a certain make-up of leaders, but could easily lead to hard times in many others. After all, many product teams already struggle with wrestling control over product from well-meaning but often clueless c-suite and founders. The betting table runs the risk of excluding those who might feel shy or unempowered to speak up for their ideas versus their colleagues in a somewhat stressful environment.

The ProdPad way is to have a collaborative, helpful backlog that’s transparent to the team. Why is this so powerful?

Anyone in the team can add to the backlog, and see what else is in the backlog. They can also see the backlog drivers. What are the top priority problems and objectives? Which ideas are most important to customers right now? Where have previous ideas ended up, and what makes for a successful idea? 

This helps people in the team understand where ideas come from, and very importantly, where their ideas end up. It helps them build trust in the product management process, which was previously a black hole. They can see how and why certain ideas make it through to production and others don’t. It helps to demystify the product management process, and allows the team to create and share a process by which problems are prioritised and ideas are selected to match.

This is not your old school backlog where things go to die. Combined with the fact that it’s collaborative and transparent by nature, the ProdPad backlog also has a ton of helpers built in to help the product team decipher what’s in the backlog, and quickly pinpoint great opportunities that will solve the right problems.

Automatic matching of customer problems to potential solutions

ProdPad's DotBot is here to help

ProdPad’s unique DotBot automatically spots ideas that might solve customer problems, or customer problems that might be related to ideas, and flags them up so the product team can join the dots. It’ll also catch your duplicates and help you link and merge similar ideas so your backlog never gets too hairy.

See customer feedback connected to ideas in the ProdPad Sandbox.

Spot and track opportunities with the priority chart and workflow views

The prioritization chart in ProdPad
The Kanban workflow in ProdPad

See the idea chart view and the idea workflow view in the ProdPad Sandbox.

Prioritize at the problem level, linked to OKRs on the roadmap

You won’t find weighted scoring algorithms or stack ranking in ProdPad. Why? Because they don’t work and they are doing your backlog a disservice. It is a source of knowledge to draw from when the time comes to solve problems. And it’s at the roadmap level that you outline and prioritize those problems. Roadmap initiatives in ProdPad are connected to Objectives and specific trackable Key Results, and are connected to the ideas (or what I like to think of as experiments) you’ll try in order to to solve each problem. 

The idea pipeline on ProdPad's product roadmap feature

See a roadmap card with ideas pipeline in the ProdPad Sandbox.

All in all, the ProdPad way works really nicely with the approach that ShapeUp presents. Both come from the same place of rejecting heavy, onerous backlogs and roadmaps in exchange for something new. The key differences come down to semantics and how each approach positions the alternative. 

As shown by this happy ProdPad customer, ProdPad can play a key role in helping your team take advantage of the best of the ShapeUp approach: 

The post Reframing Backlogs and Roadmaps for Good appeared first on ProdPad | Product Management Software.

Aligning Your Roadmap Themes to the Customer Journey

Much has been written over the last few years on the idea of the featureless roadmap, which challenges product teams to present their plans grounded more in strategic vision – or by themes – rather than a laundry list of specific features. ProductPlan alone has several articles on the subject that demonstrate the many virtues of this outcome-focused approach. It’s becoming more and more widely adopted by Product Management organizations across the globe.

One of the critical considerations in developing your theme framework is to ask what drives the need for this theme? There is a genuine risk that a well-meaning product manager might simply group and categorize the existing feature list as a means for determining the theme. However, the real goal of the themed roadmap is to let the desired outcomes define the features. So how do you zero in on the most meaningful outcomes from which to center your roadmap themes around?

How to Decide on Roadmap Themes that Produce Meaningful Outcomes

I’ve seen several different approaches, including themes that align with high-level business goals (acquisition, growth, customer satisfaction, etc.) or more granular focus areas like the example in Jim Semick’s article of increasing satisfaction within a user persona group. There are pros and cons to each of these approaches. For example, the business goals approach is static over time, so the themes themselves stay consistent and maintain a pulse on the longer view. But the themes in and of themselves are a bit uninspiring and don’t do much to communicate customer value. In the more granular approach, the focus is more laser-sharp and centered on a specific customer outcome. However, this approach runs the risk of myopia and losing sight of new emergent opportunities that might outweigh the theme’s value.

A compelling theme should be centered on the exchange of value between the business and the customer, and the above examples are hyper-focused on one or the other.

Download Feature-less Roadmaps: Unlock Your Product's Strategic Potential➜

One way to achieve this balance is to organize your roadmap themes by each phase of the customer journey. This customer journey approach provides a widely universal framework for both business and customer outcomes and promotes a constant, bird-eye perspective on the end-to-end customer experience.

The Customer Journey Framework

The customer journey chronicles every customer interaction and touchpoint with your business—from becoming aware that you exist to making a purchase decision, using, and then eventually renewing with your product or service. The journey is depicted in different phases, which are relatively universal (but might be customized by a business that has done the work to map their customers’ journey). Those phases include Become Aware, Evaluate and Buy, Set Up, Happily Use, Get Support, Add Services, and Renew.

The Benefits of Defining Product Themes by Customer Journey Phases

Breaking down the customer’s end-to-end journey is a highly effective framework that enables an outside-in perspective and customer empathy as a means to drive value that is reciprocal to both customer and the business:

product themes customer journey

Journey maps, then, are highly applicable to the goal of defining product roadmap themes since successful customer outcomes are at the heart of each phase. Besides the apparent value exchange, the customer journey is a universal perspective that transcends organizational silos. Each phase of the journey has pretty clear stakeholders, for example, generating awareness is usually assigned to the marketing team, and the customer success department usually owns the support experience. Focusing your themes on phases of the customer journey enables stronger partnerships between the product team and other functional groups because their goals become less disparate from the product strategy. It changes the conversation from other departments vying for a slot on the product roadmap to one that is much more strategic. Both groups can become collaboratively responsible for goal setting within the shared theme.

Another benefit of the journey-based roadmap themes is that it inherently promotes customer empathy. Everyone in the company who looks at your product roadmap can evaluate it, not from just a customer perspective, but a timeline-based customer perspective. The customer journey enables individuals and teams to consider the context of their work within the customer’s end-to-end experience. Leading with this genuine care, curiosity, and perspective of the customer can have profound cultural effects on a business. Customer-centered cultures foster a bottom-up drive for innovation based on the desire to solve customer problems creatively.

Problems are fluid, and markets are changing rapidly, so the work of a product manager to effectively prioritize work is a constant challenge effectively. Choosing the right theme altitude is critical to keeping eyes and ears open for emerging opportunities outside of the current focus areas. I like using customer journey phases as themes because, while customer needs may fluctuate, their journey stages are static. Maintaining consistency and continuity in themes provides a clearly defined lens from which to scan the customers, trends, and competition.

Customer Journey Roadmap Themes in Practice

Let’s look at some tangible examples of how each theme may be planned and presented from the perspective of a fictitious e-commerce platform company.

Phase 1: Become aware

Prospects know our product exists, and it has a positive reputation.

Generating awareness includes all of the things your marketing department is doing to reach new prospective customers. In this example, the product and marketing teams establish a mission to grow the reputation of the business by addressing issues raised by contributors to software review sites and focusing on a specific feature and usability gaps common among the less-favorable reviews.

CUSTOMER KPI: Reach

BUSINESS KPI: Reach as a % of Total Addressable Market (TAM)

STAKEHOLDER PARTNER: Marketing

Phase 2: Evaluate & buy

Make it easy for prospects to choose and purchase our product.

Reducing friction between a prospect and their willingness to buy is a key concern for sales and product management teams. Having a theme dedicated to this experience drives constant focus in this crucial area, like in this example, where the goal is to reduce sales objections by adding the top payment options prospects are demanding.

CUSTOMER KPI: Time to deal close

BUSINESS KPI: Maps to sales booking goals

STAKEHOLDER PARTNER: Sales

Phase 3: Set-up

New customers can take immediate advantage of our product.

Product onboarding encompasses all the activities a customer or user engages in to configure, learn, and start using a product. In this example, the teams at our e-commerce platform are working on ways to do just that by introducing two new, self-guided onboarding flows within the product.

CUSTOMER KPI: Time to the first use of the critical feature

BUSINESS KPI: Time to goal monthly recurring revenue (MRR)

STAKEHOLDER PARTNER: Customer Success and/or Onboarding Teams

Phase 4: Happily use

Customers get so much value from using the product, and they love it!

Naturally, the phase focused on product use is how much of mainstream product management is currently categorizing their work. Given the above examples, one can begin to ascertain the benefits of instead capturing work in terms of the different outcomes defined by the customer journey. Keeping the outcome of this theme narrowly focused on adding value makes it an excellent space for prioritizing feature requests of current customers, usability improvements, addressing technical debt, and, as in this example, improving product engagement of a specific feature set.

CUSTOMER KPI: Transactional Net Promoter Score (tNPS), System Usability Score (SUS)

BUSINESS KPI: Critical engagement metrics

STAKEHOLDER PARTNER: Product Development (Product, UX, & Engineering)

Phase 5: Get support

Customers rarely need help, but when problems arise, they are quickly solved.

The support phase is focused on making support resources easily accessible, improving resolution speed, building out various support channels, and reducing the need for support in the first place. The product team can have a significant impact on this outcome by doing this, like implementing an in-product support experience or, as in the example below, dedicating focus to address the top product case drivers.

CUSTOMER KPI: Transactional Net Promoter Score (tNPS), Time to case resolution

BUSINESS KPI: Tracking against operational cost efficiencies

STAKEHOLDER PARTNER: Customer Support

Phase 6: Add services

Customers are compelled to upgrade and subscribe to value-add services.

The heart of the add services phase is in upgrades, upselling, and the purchase of additional products and services, all tied to a business’s growth initiatives. This theme can capture things like improving the discoverability of value-add services, adding features to be repackaged as a new subscription tier, or, as in this example, building out new features or services that customers would be willing to pay extra for.

CUSTOMER KPI: Reach/Conversion

BUSINESS KPI: Average Revenue per Unit (ARPU)

STAKEHOLDER PARTNER: Customer Success and/or Sales

Phase 7: Renew

Customers remain loyal advocates of our product and business.

The renew phase looks at every opportunity to keep customers happy coming back to your product or service. Almost all SaaS businesses are looking at churn, and addressing those reasons is perhaps the most apparent epic under this theme. But, similar to some of the other themes, there may be opportunities to reduce effort by integrating account management experiences within the product, such as this example that would introduce a renewal flow and add the ability for SaaS customers to pay their invoice online (instead of sending a check).

CUSTOMER KPI: Net Promoter Score, Customer Satisfaction (CSAT) scores

BUSINESS KPI: Churn

STAKEHOLDER PARTNER: Customer Success

Considerations for Journey-Focused Roadmap Themes

A highlighted benefit of having high-level themes that align with phases of the customer journey is that the themes are universally applicable across every department of the business. Sharing goals across business functions create a substantial competitive advantage for consistently delivering high-value, end-to-end experiences. There are, however, some aspects of this approach to be mindful of, which include:

  • Avoid creating silos by phase. People and tactics may be focused on a specific phase. However, Product and Design need to maintain their awareness of their work’s context within the end-to-end journey.
  • Phases require prioritization. While I advocate for having the same consistent themes, I don’t believe that work needs always to be happening equally within each. Certain phases will have a greater need than others. It’s up to the product team to appropriately allocate focus where the greatest needs are.
  • Phases often have embedded journeys of their own. This is especially true for the Add Services phase, where there is a complete cycle of awareness to renew to consider.

Keeping customer outcomes at the heart of your roadmap, effectively mapping them to business outcomes, and sharing those outcomes across your organization is an excellent recipe for driving innovation and building reciprocal value between your customers and your business. The phases of the customer journey already have this value exchange baked-in. They can be a highly effective lens through which to view and prioritize the opportunities on your product roadmap.

Read the Strategic Roadmap Planning Guide

The post Aligning Your Roadmap Themes to the Customer Journey appeared first on .

6 Tips to Creating Roadmap Accountability with Your Team

As a Customer Success Manager at ProductPlan for the past two years, I’ve worked with hundreds of our customers on establishing their roadmapping processes. Throughout my time with ProductPlan, one of the most common roadblocks I see inhibiting a successful roadmap process is a lack of accountability on roadmap editors.

6 Ways to Create Roadmap Accountability with Your Team

So, you’ve invested in a standardizable roadmapping tool for your team. That’s a great first start, but how do you ensure that they actually update their roadmaps? As you build out your roadmapping process with your team, the tips below will ensure roadmap accountability.

1. Establish a Champion of the process

An essential part of creating accountability is establishing one or more persons as responsible for the outcome. This person can be an executive sponsor or a champion of the process appointed by the team. The champion must set expectations, goals, and guidelines for success with the Roadmapping Process.

Setting expectations early on in the process is essential. However, without a champion to hold the team accountable, they will be ineffective. The champion can also continuously evaluate whether they’re meeting the goals of the roadmapping process. If so, then champions have fodder to provide the team with ongoing motivation. Whereas if the team is not meeting goals, having a champion to shepherd a change in the process is key.

Build Your First Visual Product Roadmap ➜

With ProductPlan, the champion of the account typically has admin rights to the account. It gives the user the ability to see each team member’s last activity as well as a list of roadmaps created by each member of the team. It’s an efficient way to verify editors are meeting expectations and following guidelines. The team’s champion also plays a critical role as the liaison between the software and the team.

ProductPlan account admin champion

As a Customer Success Manager, I’ve worked with several teams that lacked a clear and established champion of the tool. These are the most common outcomes I see in response: users don’t end up using the tool in the first place, or they start using it but without direction and not following best practices—which causes frustration and ultimately leads to non-use, as well. More often than not, these accounts end up reverting to whatever the inefficient process was they were trying to move away from and end up back at square one.

2. Start with your “Why?”

Realistically, not many people like being told to do something blindly. An essential step for getting any team invested in the roadmapping process is communicating the why behind it. Start at a high level; why does your team need to implement a new process? What challenges are you looking to solve for the team? Then move towards the specifics, why did you choose the tool you’re asking the team to use? If your team evaluated multiple tools, it could be valuable to share the criteria your team was looking for and how the tool you selected stacked up. Switching to a new tool or implementing a new process is always going to require some manual effort, understanding the why behind it is essential to motivate users to put in that effort.

Understanding a team’s “why” is also critical for me to help, well, manage a Customer’s success. Every team has different goals they are trying to achieve with their Roadmapping process. Establishing those goals at the beginning of the process gives the team something to work towards and gives both you and your Customer Success Manager something to measure against. If I don’t know what your idea of success is, how can I help you get there, and if your team doesn’t have an idea of what success looks like, how do they know that the work they’re putting in is worth it?

3. Team-wide roadmap sharing

One of the most important ways to ensure roadmapping success is to keep the process collaborative. One easy way to do this is to encourage users to share their roadmaps right away. Often a user’s gut reaction is to keep the product roadmap hidden until the final draft. While this might work for a static PowerPoint slide, a live roadmap will never be finalized. Roadmaps are continually evolving, sharing your roadmap from the start will give your audience context to its development. Knowing that your roadmap might be viewed at any time will help foster an environment where Editors update their roadmap on an ongoing basis rather than only before a big presentation.

The importance of sharing roadmaps early on clicked with me while working with a group that was entirely new for roadmapping. I scheduled a call with all of the Editors of this group a few weeks after their first training to make sure there weren’t any lingering questions and hear how the roadmapping process was progressing. When we got on the call, my questions were met with an awkward silence because, as it turns out, no one had touched their roadmaps since our last call. When I asked why the users admitted they didn’t know when they were supposed to have their roadmaps ready, so they didn’t work on them.

By sharing your roadmap at the beginning, there’s no concept of a roadmap deadline, so updates stay an ongoing habit.

Luckily ProductPlan and most roadmap software include a team-wide sharing functionality that grants roadmap access to your entire team as quickly as one click. As an easy way to ensure roadmaps are being shared throughout the roadmapping process, encourage users to share new roadmaps with the team upon creation.

sharing product roadmap

4. Implement a cadence for roadmap presentation

Setting up a recurring roadmap meeting or designating time in a pre-standing meeting for roadmap updates can be an effective way to give users a sense of urgency to update their roadmaps. In an ideal state, roadmap editors are regularly updating as work items progress or change. Unfortunately, though, this is not always the case. Devoting a recurring time to the roadmap presentation will create a baseline cadence for updating.

Some of the larger companies I work with establish bi-weekly roadmap forums where the team can get together and go over their roadmaps, talk about what’s working and what isn’t, and discuss updates to the process. One champion mentioned to me that this was the key to establishing standardization in their roadmapping process because it allowed them to quickly identify users who weren’t following the guidelines as they presented their roadmaps.

A built-in presentation mode makes pulling your roadmap up during a meeting easy. We recommend sharing your roadmap live during these meetings so that it remains interactive. With a live roadmap, you can present in differing granularity levels, dig deeper into any items you want more detail on, and adapt as necessary.

roadmap presentation mode

5. Utilize integrations

Keeping editors motivated to update their roadmaps is an easy way to keep editors by making the process as simple as possible. One of the most valuable ways the roadmapping process can be simplified is through the use of integrations. Nobody wants to be doing redundant work, the goal of Roadmap integrations is to make getting information that has already been created elsewhere into your roadmap with ease as well as keep it updated with no manual effort. The more places a user has to update information, the more opportunities arise for something to fall out of date. Why not only worry about updating information once and have that carry over to your roadmap?

For example, ProductPlan integrates with several Project Management Softwares: Jira, Trello, Azure DevOps, and more. Use these integrations to import items directly into your roadmap, making it possible to build an entire roadmap within minutes. Syncing your roadmap automates the process of keeping your roadmap updated. It removes the burden of tedious updates from your editors, leaving them time to focus on the big picture of the roadmap. Integrating your roadmap simplifies the process for editors, but it also helps to establish your roadmap as a source of truth by creating less opportunity for error.

jira dates

6. Regular account reviews with your Customer Success Manager

Okay, I might be a bit biased on this one, but hear me out. It’s your Customer Success Manager liaison’s job to help your team establish and maintain a successful roadmapping process. The best way we can help your team maintain success is through account reviews. These are a way for us to touch base with the champions and perform a pulse check on the account. We’ll ask the team leads to gather feedback from both editors and roadmap viewers; this will tell us where the process is working and also help identify any areas for improvement.

We’ll also take an in-depth look at the team’s usage with the champions. We’ll uncover what features to utilize or not and any patterns in team use. Together we’ll analyze the overall account health and compare the current process to the goals. While reviewing guidelines set at the beginning of on boarding, we’ll see where they are being met or falling short. It helps us develop the next steps for training, but it will also equip the champion with concrete usage metrics that they can bring back to the team to foster accountability.

Takeaways

Getting your users to adopt a new roadmapping process isn’t as simple as buying a shiny new tool. However, with the proper structures in place, getting your team to update their Roadmaps doesn’t have to be like pulling teeth. Best of all, with ProductPlan, you don’t have to do it alone because that’s what I’m here for.

Ready to build your own roadmap? Get started with a free trial.

The post 6 Tips to Creating Roadmap Accountability with Your Team appeared first on .

The Birth of the Modern Roadmap

As a new decade starts, I want to reflect on the advent and growth of something truly important in our industry: the lean roadmap for product managers.

This is the story of how it was invented in a cafe in south London.

Years ago, when I started as a junior product manager, I fell into the role by accident, like many others did. With little training or guidance, I learnt a lot by doing or Googling.

One of the first things I came across was the concept of the roadmap. All of the examples online were of timeline roadmaps – essentially Gantt charts. This felt pretty intuitive to me, having had a little bit of training in project management. After all, who doesn’t like the sense of control that a Gantt chart gives you?

Creating a roadmap

I set off on creating my own roadmaps – at first, on paper and whiteboards; soon, digitised in various incarnations: PowerPoint, Excel, and even Microsoft Project played a part in my early misguided product management efforts. 

I didn’t realise my efforts were misguided; my bosses certainly didn’t give me any guidance otherwise. As a matter of fact, they essentially gave me a pat on the head for my colourful, visual timelines of the upcoming product plans, and sent me on my way to go deliver. I don’t think they knew any better either.

Many of you reading along probably know what happened next (as product managers): Deadlines whooshed passed and timelines slipped. Turns out that delivery is hard, especially when you’re hanging your assumptions on made up estimates! 

At that stage in my career I didn’t feel comfortable speaking up as a product manager. So I course corrected by adding more buffer and covering for the slipped work. Don’t tell me you haven’t done this too – we all have :see-no-evil:

The net result: The added buffer meant that delivery timelines slowly stretched out. We all know that work expands to fill the time given to it. So, scope would creep and work would slow down just enough to cause further slipping. I’d have to add more buffer or have to explain to my bosses again about why we weren’t delivering on time. It was an insidious, vicious cycle.

And I was sure I was the only product manager who was so bad at her job that she couldn’t deliver a roadmap. I mean, wasn’t everyone else simply making roadmaps, building the features, launching like a boss, and killing it out there?

That’s what it felt like in 2009, and no one was talking about failure in a real way yet.

What changed?

In early 2010, I met Simon Cast, a fellow product manager, at a light-hearted social charity event in London. It was a rarity to run into another product person in those days. We relished the chance to chat and share some stories of our experiences. 

I pointed out that there was a lack of places for product people to meet. Which led me to suggest that we work together on running the first ProductCamp in Europe. We went on to run ProductCamp London along with some other product people, just a few months later. This was how we connected with Martin Eriksson. He was just formulating the idea of ProductTank at that time, and we went on to co-found Mind the Product together.

In the meantime, I’d been harbouring an idea for software to help me streamline my job as a product manager. This included the roadmapping aspect and the even more tedious spec-writing aspect. I’d even gone so far as mocking up some prototypes and giving the software some names. 

Embarrassingly, I’d gone with Spec-ify for the spec-writing tool and Map-ify for the roadmapping tool.

ProdPad prototypes
The initial ProdPad prototypes
Very early stages of ProdPad’s lean roadmap

Simon gave me feedback and advice on the software concept. He helped shape it into a single tool that did both idea backlog management and roadmap management. He brought his skillset in back-end development, combined with my experience with front-end (though my abilities with JQuery are and remain dubious!), and we began building a first version of what was to become ProdPad! 

Simon and I both held roles heading product at different startups in London, and we built ProdPad in our spare time and on our own laptops. We used it to help us do our jobs more effectively.

We had a lot to learn, as this was still a timeline roadmap.

Early version of ProdPad’s roadmap feature.
Early version of ProdPad’s roadmap feature

It wasn’t until we started taking our slightly-more-market-ready version of ProdPad out to the product people we knew in our circles that we spotted our fundamental error.

You see, we still thought that we were the only product people who weren’t delivering on roadmaps. However, when we released an early version of ProdPad, our eyes opened when we got early feedback: About a month in, our most popular request was to be able to shift multiple items on the roadmap at the same time. 

Had we simply listened to our customers at face value, we might have enhanced the functionality of the roadmap with a multi-select drag-and-drop function so that they could do just that.

But instead, we asked a bunch of why’s

When we got to the bottom of it, it became clear that no one was delivering on the roadmap. The request to move and manipulate multiple items on the roadmap at the same time came from the desire to adjust around slipping timelines and missed deadlines. 

So we asked ourselves: If no one is delivering to a timeline roadmap, what’s the point of the roadmap for a product manager?

I’ll admit that we held on to the timeline format for a few extra months longer than we should have. Sunk cost fallacy, you see. We’d invested a lot of our time building this thing, an all-singing, all-dancing JQuery behemoth that allowed you to add features to a timeline roadmap, stretch and shrink them to the appropriate dates, and drag them into swimlanes. It was incredibly hard to admit that we had been doing our product management jobs wrong for years, and that we’d built a useless, misguided tool, and wasted months of work in the process, even as the customer feedback stacked up.

But the feedback was in, and the timeline had to go.

We got together at a cafe that was about halfway between our homes, in south London. Wandsworth, to be precise. (This was long before we had an actual office, after all!) It was nearing the end of 2012. 

We talked about what a roadmap was and what it wasn’t.

A roadmap is a communication tool. It’s strategic. It aims to keep the team aligned and informed about the steps that are needed to reach the product vision. The roadmap needs to show some concept of upcoming initiatives. It should show how it’s connected to the problems the team is meant to solve, the objectives they are meant to hit. 

A roadmap isn’t a list of features and bugs and work in progress down to the day and week and month. That’s a release planner. 

Simon turned over his napkin, and sketched out three columns:
Current | Near term | Future

He talked me through a concept of time horizons, and three ‘buckets’ with initiatives that could group together ideas, features, or experiments. His concept was underpinned by the idea that initiatives in the Current column were more certain, while the ones in the Future were less certain and more fuzzy in scope.

Early sketches of timeline-less roadmaps, using time horizons and ‘certainty’ as axes.
Early sketches of timeline-less roadmaps, using time horizons and ‘certainty’ as axes.
An early wireframe of the Now/Next/Later format of the roadmap
An early wireframe of the Now/Next/Later format of the roadmap

Simon and I both liked the freedom that this format gave, while still delivering on all the points that a roadmap needed to have, to still ‘be’ a roadmap.

We passed the napkin back and forth and made some notes and agreed on a simplified version. I would knock it together with simple front-end code, so Simon could hook it up on the back-end. 

We shuffled the timeline roadmap code to the side. This was an experiment after all, and we had no idea if it would work.

One piece that we didn’t talk about was whether we would still call it a roadmap. We didn’t think about it at first, until we saw the result live on the page – a three-column time-horizon roadmap, meekly standing where a timeline roadmap once stood. We debated renaming it, but didn’t know where to begin. After all, our website said we had roadmap software, and it did technically meet the criteria. Our new roadmap format was just… different.

Somewhere along the line, the napkin was lost. I wish I’d framed it now.

via GIPHY

We launched with no fanfare, as you do when you have no paying customers and a simple MVP bootstrapped product that you built from your bedroom. But our early testers took note.

And they actually liked it! 

A timeline-free roadmap for product managers
ProdPad’s first Now/Next/Later roadmap

What we discovered in our next rounds of feedback was that the format allowed product people to communicate the bigger picture. After all, most companies don’t know how big they’ll be in a year’s time, let alone how fast they’ll be able to deliver! 

Our first version was very MVP. It was simply some boxes you could add to one of three columns pragmatically named ‘Current’, ‘Near Term’, and ‘Future’. Frankly, you could have done it in Trello. The basic format that grew into a much richer form of lean roadmapping.

It was right to keep the name ‘Roadmap’ for this new format, even if it didn’t look like the other roadmaps. From feedback, we realised that we were implicitly giving product people permission to step away from the timeline roadmap format. After all, they were giving their team and their bosses a roadmap. It said so, right there at the top of the page, on a real dotcom SaaS product, so it must be legitimate! 

By subverting the format and terminology we changed the way that roadmapping was done. Which we appreciated some time later. It’s a roadmap. But it’s not a usual format roadmap.

We still had a long way to go to find out if our way was any better. We had a lot of listening and learning and iteration ahead of us. 

The Modern Roadmap Evolves

The basic scaffolding of the new roadmap format worked. New testers gave us positive feedback about the time horizon concept regularly. We set out to figure out what we needed, as the functionality of the roadmap was severely lacking.

Since then, over the years, the roadmap has evolved.

  • You can link initiatives to ideas in your backlog, so you can see what experiments your team might run in order to tackle each problem on the roadmap
  • We made these ideas sortable, and then made the workflow stage visible so you could see if it was in discovery or in Jira or wherever else
  • We created colorful labels, so you could associate initiatives with objectives. Later, we gave these labels text fields, and later still, we allowed you to link an initiative to multiple objectives
  • A set of filters lets you carve up your roadmap into specific views suitable for the job at hand
  • We created options to publish and export your roadmap, so you could create versions for your exec team, your sales team, or anyone in between in a flash
  • We introduced the concept of product lines and a portfolio view of your roadmap, allowing ProdPad to scale for use in much larger enterprises

These and many more iterations have allowed us to evolve and improve the roadmap in line with today’s best practices. We’ve learned a lot, and continue to learn as the discipline of product management grows and develops. As we move into a new decade, we’re excited to see what comes next! We do not rush to follow the crowd. Through measured, and considered steps forward, we build the right solution, even if it’s not what is expected.

What’s in a name?

Along with evolving the roadmap functionality itself, we’ve seen a lot of change over the decade in how we talk about this new form of roadmapping.

We didn’t know what to call it when we first launched the new roadmap. We just kept the name as is, simply calling it the Roadmap. Internally, we were calling it the ‘time horizon roadmap’, and in conversations with potential customers we would talk about our ‘dateless roadmap’, but none of these ever had a ring to them.

Later on, as the concept caught on, we started hearing about other terms that rang true to our purpose. In 2013, Bruce McCarthy started talking about the idea of using themes on the roadmap. He launched that term into popular consensus: through conversations he had with Jared Spool, an MTPcon talk and an article. Problem-focused roadmaps had been simmering under the surface for some time. We all knew there was something inherently wrong with the feature-based roadmap. We were lacking the tools and techniques and vocabulary to do something better.

Theme-based roadmapping was a popular term for a while. We watched it evolve into various other names, including Problem Roadmap, Objective Roadmap, Outcome Roadmap, or as we like to call it, as it derives so heavily from the Lean principles of ongoing learning, the Lean Roadmap. Bruce went on to write the very popular and timely book Product Roadmaps Relaunched, with several other product luminaries. I wrote the foreword, which was an honour. Even more thrilling was seeing the ProdPad Now/Next/Later format roadmap touted useful in a full page spread case study. It’s smack in the middle of the book!

ProdPad's  Now/Next/Later is featured in the Roadmap Relaunched book for product managers
ProdPad’s Now/Next/Later is featured in the Roadmap Relaunched book

It’s been a long journey of discovery. But we’re on the right path, and we’re building the tool that actively helps product people do their job better. I can’t wait to see what we learn in the next decade!

Are you a Product Manager? If you have any burning questions or want to talk all-things-product, then get in touch. Or, give ProdPad a try by signing up to a free trial.

The post The Birth of the Modern Roadmap appeared first on ProdPad | Product Management Software.

Changing the Way Product Managers Speak to Stakeholders

Changing the way we talk to stakeholders and executives can make a world of difference, both for them and for us as product managers. We can’t expect them to simply understand the way we work, we need to bring them into the product process and open the door to our world. With this comes teaching them our lingo, and rearranging their view on what product is and how it works.

Below are a few terms to kick-start and change the way we frame things to others:

Feature Roadmap = Product Roadmap 

When will it be done? Do you have a timeline for this?

Due dates and timelines should never be promised – as product people we all know this. And yet, it seems to be the one question we always get. 

The first step to changing this conversation is to make sure everyone has access to the product roadmap. Hiding it as a Hootsuite dashboard is a huge mistake.

Reframe the conversation from “time” to “strategy.” At first it may seem daunting and that no one will accept this, but it’s actually pretty simple. 

Think about it this way:

Imagine that you’re going on a road trip, and you tell someone you will get from point A to point B in three days with no further context. They will expect you to fulfil what you’ve said.

Now imagine you prepare them for possible changes, and give them the whole context of the road trip, such as pit-stops and side roads. Your road trip buddy will now be more forgiving with time changes.

It’s the same with presenting a product roadmap without timelines. You’re presenting the whole strategy, not just the time constraints you’ve boxed yourself into. Once you remove the tunnel vision and explain the entirety of what is happening, better conversations will be had. 

Second, make sure no one refers to it as a ‘feature roadmap’, and start calling it what it is. It’s a roadmap for your product. It is not a timeline, it is not a gantt chart, it is not a list of features. A product roadmap is a document that allow product managers to explain what they’re working on and why. 

If you need a little help on building a product roadmap everyone understands, start here.

Outcomes > Outputs

A product roadmap focuses on outcomes – what, why, for whom. What are the goals that your product team are aiming for? What problems are the product managers trying to solve?

Outputs come after you have gone through the product validation process – after the idea has been reviewed, validated and spec’d out. That’s when you pass this on to development and focus on the output. 

And this is where the release plan comes into play. This is an entirely different document that focuses on how fast something will get done, after you have defined what the possible outcome is. Also, be sure you’re not referring to your release plan as a release roadmap or a technology roadmap. A product roadmap and a release plan are two documents that support each other in the whole product development cycle, but they’re not the same document, and terms should be kept clear.

ProdPad Dots representing the roadmap and release plan, coming together
Roadmap and release plan

Feature Backlog = Opportunity Backlog

A feature encompasses an area of your product. It simply states that your product does something, but doesn’t focus on what the benefit is. So let’s change the conversation around that first.

Once your entire team understands the benefits your product gives your customers, you can start talking about opportunities or ways you can improve those benefits. These opportunities, or ideas as we call them in ProdPad, make up your opportunity backlog.

What problems can you solve? What value would these provide if solved?

Once your team starts talking about problems to be solved in the opportunity backlog, it becomes less about ripping off the competition, and more about how you can provide value to customers. At the end of the day, you’re not building a product to compete with others, but to provide value to your target market.

Feature Request = Customer Feedback

A request implies something will be done. Will you do every single item that comes through? If you did, you’d just be a feature factory!

Change the language to customer feedback. This implies that it is coming in as an observation from your customer, rather than a request you must fulfil. Product managers shouldn’t focus on feedback being positive or negative, but rather as input for areas you can improve in your product. 

This will also give you a leg up on how your team responds and handles the feedback that comes in. If your team isn’t currently focusing on something that’s requested, they can share your product roadmap (wink wink) to talk about current priorities, and how these will benefit (wink wink) the customer. Thank the customer for their feedback, link it to your opportunity backlog, and as time goes by, understand the impact of that feedback for the problems you aim to solve. Do I have to wink again? I’m sure you guys get it by now.

The post Changing the Way Product Managers Speak to Stakeholders appeared first on ProdPad | Product Management Software.

The one where Janna Bastow went in hard on Twitter

Earlier this week, Janna Bastow, Co-founder and CEO at ProdPad, took to Twitter and published her very own self-proclaimed TED Talk, on why timeline roadmaps suck.

And the product management world loved it.

Janna Bastow kicks off her Twitter thread on Monday, September 2nd.
Janna Bastow kicked off her Twitter thread on Monday this week

What did Janna’s 19-tweet thread include?

The tweet thread began with an expert explanation on why timeline roadmaps set product managers up to fail. She then continued with a step-by-step guide on why ‘product people of the world’ should ditch these types of roadmaps. And to conclude, Janna revealed why everyone should be using lean product roadmaps instead.

Oozing with product-passion, a wealth of experience, and a few carefully chosen emojis – Janna’s tweets went viral. Above all, this resulted in some great conversations and discussions on product management.

Janna hadn’t planned the Twitter thread. However, she was prompted to do so after trying out a new eco-friendly search engine:

“I was testing Ecosia, a search engine that plants trees with its ad revenue, as opposed to lining Google’s pockets. I checked the search results for ‘product roadmap,’ as I wanted to see if Ecosia showed the same thing Google does. Oh yes, same problem – timelines everywhere. However, it spurred me on to revive a talk I gave on why lean product roadmaps are the way forward.” Janna Bastow, ProdPad.

Let’s learn about lean roadmapping

Here’s why product managers need to be embracing a lean, outcome focused roadmap in order to become better product people. Please get in touch, or book a ProdPad demo if you’re looking to discuss your own product strategy. 

Janna will be putting together a Q&A – which will answer the most popular questions from this Twitter thread. Watch this space.

The post The one where Janna Bastow went in hard on Twitter appeared first on ProdPad | Product Management Software.

Feature Friday: Empower your Team with Product Ownership

Having multiple initiatives going at the same time can be overwhelming for any team. Multiply this across several products, and it can be easy to lose focus quickly. To avoid this, you can introduce some product ownership to your team.

Assigning a Product Manager to a card means one person will take ownership of leading the product. This will enable the rest of your team to keep the focus on the work at hand.

To increase transparency, we have introduced Product Managers and Roadmap Card Owners. These new assignments let the company know who is accountable for moving things along and who to ask questions to.

Product Managers add a level of selective functionality access within the application. You can assign the Product Manager status to any admin or editor within the app. Therefore, the user will have exclusive access to make changes to the product and roadmap, deciding how and when the Roadmap is edited and managed.

Roadmap Card Owners allow you to highlight who is responsible for a particular initiative within the team. By having this level of visibility on who’s leading an initiative, it can enable you to work better as a team and move things forward quicker!

Ownership within products adds a level granularity without overwhelming the roadmap and the work getting done.

How to assign a Product Owner

Assigning a Product Manager

When creating a new product, on the attributes panel you will be asked to select Product Managers. A list of existing admins and editors will be available.

The attributes panel with multiple product managers.

Once assigned, the users will appear as part of the product and within the Product Canvas.

Assigning a Roadmap Card Owner

To add owners to a roadmap card, click on the card to prompt the slide out.
Under the owner icon, select the users leading the initiative.

Selected and non-selected users from a drop down on the card.

Once the user is selected and the attributes saved, you will find the selected user’s profile picture at the bottom left corner of the card.

Selected user's profile in a circle at the bottom left corner of the card.

Voila! Now your team knows who will be leading the charge and who will be needed to get on with things to take your product forward.

The post Feature Friday: Empower your Team with Product Ownership appeared first on ProdPad | Product Management Software.

Feature Friday: How to Communicate Blockers by Showing Dependencies

As the ProdPad team have learned more about the challenges faced by product teams, we’ve heard about the need to represent dependencies in ProdPad.

Logistical dependencies (where work on one initiative could be blocked by delays with a separate initiative) are useful to see on the roadmap when planning out your strategy, making sure that the outcomes you expect to achieve are feasible.

This is particularly important when working with a high volume of product roadmaps (maybe where your product roadmap is split by delivery team), as dependencies like this could be spread across multiple roadmaps.

dependencies

Here’s how to show dependencies on your ProdPad roadmap:

Find the blocker card, prompt the slideout and grab the card’s URL

Image 2019-01-23 at 7.51.21 am.png

Add the URL to the relevant blocked card, with a note to say what’s blocking it. For a little extra flair, use some emojis!

Image 2019-01-23 at 7.53.48 am.png

Add a “blocked” tag and use the filters to make sure you have the visibility needed.

When communicating strategy to your leadership team; you can now easily show which initiatives are dependent on each other; and clearly present all the relevant information needed to move forward. Risks? What risks? You’ve got a hold on this now.

Specialis Revelio! ✨

The post Feature Friday: How to Communicate Blockers by Showing Dependencies appeared first on ProdPad | Product Management Software.

Getting the most out of ProdPad + JiraOn Demand Webinar and Full Q&A

Creating a great product management process is easy to achieve if you split your strategy and execution between ProdPad and Jira.

We recently hosted a webinar with our CEO Janna Bastow and Customer Engagement Manager Andrea Saez.

They covered everything you need to know to get ProdPad and Jira working together perfectly:

  • How to split the backlog between strategy and execution
  • How ProdPad and Jira work together within your organisation
  • Learn how to validate product features with customer feedback
  • The importance of visualisation – the power of the priority chart
  • Creating an agile product roadmap

If you’re already using Jira as your backlog tool you might be wondering why you need ProdPad too. The thing is, it isn’t a case of one replacing the other, it’s about creating a slick process where your development team and your product team can work without slowing the other down.

Nailing your product management process is key to being a great product manager, and during the webinar we got asked some awesome questions. We’ve got the full transcript below, let’s dive in:

Q: Why wouldn’t the product backlog be prioritized?

If you think of your entire product backlog, that could be a thousand things to do. That’s why we like the idea of splitting the product backlog from the development backlog. You could spend a lot of time and effort trying to figure out if something sits at number 752 or 753 at the level of granularity Jira asks for and it just doesn’t really make that much sense.

Now what does make sense is to surface things to the top of that list and prioritize those. It makes sense to have the next 20 or 50 items prioritized and specced and ready to go. It doesn’t make sense to put the same amount of effort into ticket number 300 as ticket number 3.

If you are pushing ideas over to Jira, when they are fully specced and ready to go, they are then prioritized and you have a very granular view of what is going on. In the same way on your actual product roadmap, you have the completed column where you can set granular priorities and log results.

But what you are not trying to do and what a lot of tools attempt to make you do with your backlog, is straight away assigning a priority for everything – no matter the stage. That tends to be a waste of time.

You should see your product backlog as a list of opportunities where there can be lots of ways to prioritize and break them up.

It could be:

  • How many customers have asked for something
  • What revenue potential it has
  • Whether it solves a particular problem

When you are actually prioritizing that development backlog, tools like Jira are amazing for that level of granularity the development team need! For high level priorities that’s where you would use your product roadmap.

Q: I absolutely want to get into the product driven roadmap and use “current/near/future”. But, right now, we’re more sales driven and have contractual obligations due by certain dates. Is there a roadmap view that will help communicate that?

Such a good question and it’s one that a lot of people struggle with because you have this sort of tension between teams.

Firstly your sales and support teams and other folks in your team need to understand what things are coming up so they can support the launch successfully. However the development team and the product team can really struggle to come up with accurate delivery dates without adding lots and lots of buffer time.

The more buffer they add the slower things tend to go, which means your company is not operating in a lean way. So there are a couple of ways where you can give that structure to help people understand what is happening.

1. When the sales & marketing teams – need time to prepare for a launch. We recommend separating the soft launch from the hard launch.

So many companies attempt to say “we are going to launch this on Thursday” behind the scenes they are coding and scraping the last bits and pieces on the Wednesday afternoon or the Thursday morning. Meanwhile marketing is waiting to send the press release out the next day which isn’t a great idea.

By doing a soft launch, or dark launch to a subset of your customers, you’ve then got a much easier roll out. Not only are you taking the pressure off the development team who are trying to rush something out the door, you’re also giving your marketing team enough lead time to fully support the release. This soft/dark lunch buffer is so helpful especially if something does go wrong (as it often does).

2. If you have contractual obligations, you’ve got customers that have paid you to hit a certain project by a certain date.

Often you’ll find certain companies are operating completely this way. This is not a product driven way it’s more of an agency sort of model where you’re building particular products to deliver on specific dates.

If company is modelling that way you do need to add that buffer time and you do need a project plan to show why and how you are going to hit those particular dates. Unfortunately that’s more of a project plan problem than it is a product problem.

Where we find the problem lies is companies that have a blended approach, where they are delivering things that are hitting most of their customers or users, but occasionally have things that specific due dates and deadlines.

For example most of the companies that we speak to these days has a card on the roadmap that reads GDPR, a particular compliance thing that most companies in the world are having to deal with right now. This is something that has a hard delivery date.

In cases like that you can actually put a date on your roadmap and tell people “We are going to have this completed and out by May 25th”. That doesn’t mean the next card or the card after that needs a date on it.

People tend to assume that once you’ve put one date down you have to commit to dates on all upcoming projects. But the more assumptions you are extrapolating to add all these dates to your roadmap will make it more likely you are building the wrong thing or wasting time on things that shouldn’t be on your roadmap.

If you have contractual items they can have a date which can be articulated to the wider team but don’t feel the pressure of doing that on every roadmap card. The more long term dates you the slower you company is going to be able to operate, move and iterate on new/better opportunities.

This is a long and complicated answer but one that we have a lot, if you are having problems with dates on your roadmap please do send us an email at hello@prodpad.com to request a 1-on-1 roadmap clinic!

Q: How do I consolidate my existing Jira backlog with ProdPad?

Chances are you don’t have a lovely green field, brand new product, you have an existing backlog full of all these messy things, don’t worry we hear you. We’ve worked with 100’s of other companies in this situation.

What you can do is export tickets from Jira that aren’t ready to go, approved, or yet to be prioritized in your development backlog. Then import that into ProdPad and turn them into ideas.

That way you can work on those ideas in ProdPad, make sure they have all the user stories, context, know that they are being built for the right reasons.Then push them over to Jira for them to continue on into the development flow.

Often we do meet people who have to clean up their Jira backlog, we’ve got articles and tips on how to do this, which you can find here in our help center and how to set up an integration here.

Q: Can the field and workflow mappings be modified after they’ve been set up?

Absolutely, feel free to customize your workflow. The integration owner will be able to take care of this!

Q: Can I have the idea as an Epic with a workflow that matches workflow in ProdPad, so if I move the epic through the flow it updates on both?

Workflows are 100% customizable, so you can map them to what’s in Jira. We usually recommend keeping the same language so that all teams understand what you mean when something is ‘in progress’ or ‘in development.’

Q: What if I push User Stories without pushing the whole Idea?

Ideas can be broken down into individual user stories, those ideas and user stories can either work in tandem or independently.

So you can take a whole idea and put it on the roadmap and track the progress there or you can take individual user stories and put them on the roadmap or send to development.

They have different use cases, it might be that you’ve got an idea that is being delivered by two different teams. You might have a set of 5 user stories attached to an idea for team one and another 5 for team 2 in a different integration.

The other use case is you might have part of the idea being done now as a V1 and the other part planned to be done sometime in the future. In that case the later user stories could be attached to an idea on the future column of your roadmap to be sent over to Jira at a different time.

What you can do is when you have an idea you have the choice to push the idea to Jira or the entire idea with the user stories or the individual user stories.

If you push an idea whether or not it has user stories attached, it will create the epic in Jira. If you then push that idea again with the user stories attached it won’t create a new epic but simply add the user stories to the original epic.

That’s the use case for the team that need to send over a high level ticket first and then bring in the more granular detail with the user stories later. Often there are times where there are new details or features that were missed at the beginning and need to be synced with the epic later on.

Q: How do you do high-level estimates of ideas/stories before they get pushed to dev in Jira? Why is there no estimate of effort at the story level?

Yes you can do high level estimates before they get pushed. In ProdPad we have what we call the impact and effort score, here are three different scales, one that is from 0-100, another is a simple 1-10 and the third is t-shirt sizing (small through to extra large.)

What we recommend for these is not your detailed development estimates but more of that product manager gut feel. When someone comes to you with an idea you instantly get that gut feel for if it is going to be really difficult so you set it to a high effort score. If you think it will be simple and straightforward you can set it to a lower scoring.

It’s not meant to be an exact science but it does give you this nice relative sizing of effort.

One thing that is good to remember when setting these effort scores in ProdPad you are thinking about not just how many days or dollars this is going to take to get through development but how much effort this is going to take for the entire company to pull this off.

Something that might be straightforward to develop might be straight forward but might have implications for the legal team or the sales team or the support team to make successful. Whereas other things might be straightforward for the business but much more difficult for development.

So keep in mind the entire effort when you are setting the impact and effort, that way when it is pushed to Jira that’s where it is pushed down into more detailed development specs.

For that I recommend using tools like Planning Poker which is a great tool for exercises you can do with your team to get estimates on things. This is a great way for you to get everyone on the same page with how to create estimates on a story point.

At the end of the day any estimates that are made for development should be made for setting internal milestones and goals not for setting external due dates and deadlines, because we all know how complex and nonlinear development can be!

Any reflection of how many points existed for a story might not reflect back on original estimates once they have been built and understood and delivered by the development team.

Q: What is the minimum version of Jira that this integration supports?

Officially 7.2.x, but the API still works with v5 and v6 and we’ve had no complaints from customers who use these older versions.

Q: How do you get an existing Jira epic or story linked to an idea/story in ProdPad?

If you have existing tickets in Jira, you can export and remove them from Jira and import them back into ProdPad.

When you push them back into Jira it will create a new ticket but will have the new information or whatever has been updated within ProdPad now attached to that ticket.

That allows you to track it through from conception through to the delivery side.

If you’ve got something that is in Jira that is partly through being delivered and it doesn’t yet exist in ProdPad we don’t have a way to retrospectively connect those ones but you can create a link manually between the two by creating a link in both Jira and ProdPad so you can keep an eye on the progress there.

But over the course of the next few sprints everything in Jira should be coming from ProdPad using the automatic syncing.

Q: Does the Jira ticket ref show up in ProdPad so you know exactly what ticket was created after you push?

Yes! References are added on both ends so you know the originating idea as well as the ticket created in Jira

Q: How do I see which Ideas and which User Stories have already been pushed to Jira?

The workflow view will indicate where those ideas are. It will look like this:

Q: Do changes in Jira, sync back to ProdPad?

The status of the ticket syncs back into ProdPad using the mapping, but we don’t do syncing of the fields themselves and there is a really good reason for that.

When you push something over to Jira that ticket might take on a different form as it is being moved through, the developers might break it down into more detail or add more technical notes.

We don’t want to have their notes accidentally overwriting the data on ProdPad that supplies the context of the idea likewise we don’t want to re-sync from prodpad and overwrite the developers work.

This comes down to data conflict management, it’s hard enough to manage conflicts if you’ve got two people typing in the same page in the same tool, let alone when you’ve got a five minute delay between tools. We don’t want to put your data at risk.

What tends to happen that when you push something over to Jira, they have the original context of the idea in ProdPad if they need to look back at from the link provided on the ticket in Jira. Then the would be free to work on that ticket in Jira and ad more information as they move the ticket through the development workflow.

Q: Can you update ideas in ProdPad that are already epics in Jira, or should ideas be absolutely ready to dev when pushed?

Try to have as much information filled out before passing it over. Think of ProdPad as the source of truth, so it should be spec’d out before being pushed to Jira!


Missed the webinar? Watch it now.

If there are any other subjects you’re interesting in learning about please do let us know via comments, emails or tweets and we will be sure to add it to our webinar calendar!

The post Getting the most out of ProdPad + Jira</br>On Demand Webinar and Full Q&A appeared first on ProdPad | Product Management Software.