Category: Roadmap Management

Posted on

Missed Details That Can Cause Huge Product Reputation Ramifications

Product managers are all about prioritization. The items that deliver the most value to a product’s reputation, help the product achieve its goals and improve KPIs are the ones that we continually slot at the front of the queue.

It’s our job to skip over the features that only apply to a couple of customers. To ignore shiny objects and stick to what really matters. In practice, that means focusing on big things that create meaningful, measurable impacts.

But that doesn’t mean we still shouldn’t sweat the small stuff. There are plenty of seemingly minor or insignificant aspects of the overall product experience that are often ignored. But these aspects play an outsized role in successful product adoption and customer satisfaction.

While none of these by themselves will likely add up to a massive shift in growth or profitability, they do add up. When we can reduce friction, we give customers one more opportunity for delight and one less chance to get frustrated.

Download My Product Manager's Guide to Prioritization ➜

4 Common Areas to Uncover Potential Problems for Product Reputation

It doesn’t take a genius to spot opportunities to make a little change with a big impact. It would help if you were on the lookout for them by taking the perspective of your users.

Customer-facing teams are an excellent resource for both identifying these items and gauging how frequently they occur. Ensure your customer research includes room for this type of feedback along with bigger picture areas to understand your product’s reputation.

Here are four aspects of the product experience to keep on your radar.

1. Onboarding

Your product may be awesome, but if customers can’t figure it out, you’re liable to see many of them abandon ship quickly. A thoughtful, dedicated onboarding process can shrink the time it takes from a customer-first dipping their toes in the water to diving all the way in.

It’s important to consider the entire onboarding process as part of the product experience. Especially since onboarding is about people as it is about software, it’s not just the friendly pop-ups and helps documentation.

Consider how your customers learn about, experiment with, and ultimately find value in your product. There will undoubtedly be improvements and adjustments as you map out and evaluate the customer’s onboarding experience. Adjustments both in the product itself and with the processes and actions the rest of the team takes.

Smoothing out bumps in the road and simplifying key tasks that lead to greater engagement is the goa. This can be as seemingly minuscule as making it easier to issue credentials or better in-app prompts for newbies. But just as important are the training sessions, how-to videos, and messaging that customers (should) receive.

2. Accounting

Whether it’s an in-app transaction, an enterprise sale, or an e-commerce purchase, the product team will likely chalk that up as a victory and another tick on a KPI. But after a sale, there’s a whole other string of events that need to occur effortlessly for your customers.

Anything that makes it tougher to pay, get a receipt, track an order, or receive merchandise is a strike against your customer’s satisfaction with the experience. Keep in mind for B2B products that the person using your product often isn’t involved in those steps. No matter how good your product is, you must remember how critical the customer experience is.

3. Usability

Most people acclimate to annoyances to receive the benefits of an experience. It’s why people are willing to stand in lengthy lines at theme parks or keep phone chargers in every room of the house.

But a shorter line and a longer battery life will increase the customer’s enjoyment and decrease their frustrations. That’s why all those little torturous moments in an otherwise delightful user experience can do so much damage.

A customer-centric organization doesn’t settle for workarounds and “good enough.” While those compromises might have been necessary for the sake of speed, they should be dealt with as quickly as possible. Do this to create a solid experience that doesn’t have any particularly jarring or irritating moments.

Improvements can be anything from a more intuitive UI to speedier processing to easily customizable settings. Anything that simplifies the path from Point A to Point B or alleviates any confusion is fair game.

Download the Customer-Centricity Checklist ➜

4. Dead ends and bailouts

The final source for spying frequent frustration points is by using your product analytics to see when users give up and quit. Is there a particular step in a transaction where you see a huge fall-off? Are users consistently using one feature of your product before they stop using it at all?

Improving the odds of customer success is a critical opportunity in enhancing the customer experience. You might have to combine it with surveys, emails, or interviews. But if there’s a pattern of when users throw in the towel, it’s worth further investigation. These trouble spots can often be easily remedied with small changes and improvements that have a massive knock-on effect.

Download Product Success Metrics ➜

Enhance Your Product Reputation

Enhancing the customer experience is the best way to improve the reputation of your product. But how do you go about including these improvements?

How you structure your product roadmap can make a big difference, particularly whether there’s the bandwidth for these incremental improvements. There are a few dependable strategies to ensure the low-hanging fruit gets addressed. Strategies that ensure the spotlight stays on more significant items.

4 Ways to Carve Out Space for the Little Things

Identifying areas for improvement is one thing, but squeezing them into your product roadmap can be much harder. When you’re normally applying a ruthless prioritization philosophy, there’s scant space for seemingly trivial tweaks.

1. Organize your roadmap using themes

Theme-based roadmaps shun listing out specific features for broader goals and objectives. You can then slip in some smaller changes underneath the corresponding umbrella theme.

For example, if there’s a “Checkout” theme in which you identified opportunities to expedite billing by automating invoice creation or saving credit card numbers for future purchases, those can slot for that initiative.

If there’s enough work to warrant it, you can create a theme or OKR around user experience. One that’s chock full of minor changes that will create a net positive effect.

Watch our expert panel discuss how product managers can use themes and a north star metric.

 

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

2. Build a “small stuff” sprint into your cadence

As your product experience grows more complex and the userbase more diverse, there will always be little issues cropping up. Issues that could address with a little bit of development work. If these keep piling up and can’t seem to address during normal operations, work with your engineering team to schedule an occasional “small stuff” sprint every three or four or five sprints.

The work can be limited to these smaller tweaks, along with bug fixes and work required to minimize technical debt. Once these become routine, your wish list will shrink over time. Then the whole product will get the regular maintenance it likely needs.

3. Include a non-technical swimlane in your roadmap

Many minor details don’t require coding or manufacturing. They lie completely at the feet of other parts of the business. Don’t be afraid to hold them accountable by including their initiatives to improve the customer experience on your roadmap.

This will increase visibility, create more urgency, and ensure these tasks follow a consistent process and get the oversight they need. And, once stakeholders get used to it, they’ll wonder why there wasn’t one there all along!

4. Use the Kano model

Keeping your minor improvements visible is a major step in actually getting them done. If you use a Kano-style roadmap, those small-but-important to-do items won’t languish in a backlog or parking lot.

Every time the team looks at the roadmap, they’ll see it as a reminder. During those rare moments when a developer or engineering team has a spare cycle, they’ll be able to easily grab one and fit it in as they wait for the rest of the release to wrap up.

These “extras” might only take a few hours or days, but their impact can be a major gamechanger for the users they affected.

 


Takeaways

Seemingly minor or insignificant aspects of the overall product experience play a huge role in a product’s reputation; by using a roadmap and including small wins into your strategy, you can see the product’s ultimate success.

Download Product Roadmaps: Planning Your Strategy➜

The post Missed Details That Can Cause Huge Product Reputation Ramifications appeared first on .

Posted on

Missed Details That Can Cause Huge Product Reputation Ramifications

Product managers are all about prioritization. The items that deliver the most value to a product’s reputation, help the product achieve its goals and improve KPIs are the ones that we continually slot at the front of the queue.

It’s our job to skip over the features that only apply to a couple of customers. To ignore shiny objects and stick to what really matters. In practice, that means focusing on big things that create meaningful, measurable impacts.

But that doesn’t mean we still shouldn’t sweat the small stuff. There are plenty of seemingly minor or insignificant aspects of the overall product experience that are often ignored. But these aspects play an outsized role in successful product adoption and customer satisfaction.

While none of these by themselves will likely add up to a massive shift in growth or profitability, they do add up. When we can reduce friction, we give customers one more opportunity for delight and one less chance to get frustrated.

Download My Product Manager's Guide to Prioritization ➜

4 Common Areas to Uncover Potential Problems for Product Reputation

It doesn’t take a genius to spot opportunities to make a little change with a big impact. It would help if you were on the lookout for them by taking the perspective of your users.

Customer-facing teams are an excellent resource for both identifying these items and gauging how frequently they occur. Ensure your customer research includes room for this type of feedback along with bigger picture areas to understand your product’s reputation.

Here are four aspects of the product experience to keep on your radar.

1. Onboarding

Your product may be awesome, but if customers can’t figure it out, you’re liable to see many of them abandon ship quickly. A thoughtful, dedicated onboarding process can shrink the time it takes from a customer-first dipping their toes in the water to diving all the way in.

It’s important to consider the entire onboarding process as part of the product experience. Especially since onboarding is about people as it is about software, it’s not just the friendly pop-ups and helps documentation.

Consider how your customers learn about, experiment with, and ultimately find value in your product. There will undoubtedly be improvements and adjustments as you map out and evaluate the customer’s onboarding experience. Adjustments both in the product itself and with the processes and actions the rest of the team takes.

Smoothing out bumps in the road and simplifying key tasks that lead to greater engagement is the goa. This can be as seemingly minuscule as making it easier to issue credentials or better in-app prompts for newbies. But just as important are the training sessions, how-to videos, and messaging that customers (should) receive.

2. Accounting

Whether it’s an in-app transaction, an enterprise sale, or an e-commerce purchase, the product team will likely chalk that up as a victory and another tick on a KPI. But after a sale, there’s a whole other string of events that need to occur effortlessly for your customers.

Anything that makes it tougher to pay, get a receipt, track an order, or receive merchandise is a strike against your customer’s satisfaction with the experience. Keep in mind for B2B products that the person using your product often isn’t involved in those steps. No matter how good your product is, you must remember how critical the customer experience is.

3. Usability

Most people acclimate to annoyances to receive the benefits of an experience. It’s why people are willing to stand in lengthy lines at theme parks or keep phone chargers in every room of the house.

But a shorter line and a longer battery life will increase the customer’s enjoyment and decrease their frustrations. That’s why all those little torturous moments in an otherwise delightful user experience can do so much damage.

A customer-centric organization doesn’t settle for workarounds and “good enough.” While those compromises might have been necessary for the sake of speed, they should be dealt with as quickly as possible. Do this to create a solid experience that doesn’t have any particularly jarring or irritating moments.

Improvements can be anything from a more intuitive UI to speedier processing to easily customizable settings. Anything that simplifies the path from Point A to Point B or alleviates any confusion is fair game.

Download the Customer-Centricity Checklist ➜

4. Dead ends and bailouts

The final source for spying frequent frustration points is by using your product analytics to see when users give up and quit. Is there a particular step in a transaction where you see a huge fall-off? Are users consistently using one feature of your product before they stop using it at all?

Improving the odds of customer success is a critical opportunity in enhancing the customer experience. You might have to combine it with surveys, emails, or interviews. But if there’s a pattern of when users throw in the towel, it’s worth further investigation. These trouble spots can often be easily remedied with small changes and improvements that have a massive knock-on effect.

Download Product Success Metrics ➜

Enhance Your Product Reputation

Enhancing the customer experience is the best way to improve the reputation of your product. But how do you go about including these improvements?

How you structure your product roadmap can make a big difference, particularly whether there’s the bandwidth for these incremental improvements. There are a few dependable strategies to ensure the low-hanging fruit gets addressed. Strategies that ensure the spotlight stays on more significant items.

4 Ways to Carve Out Space for the Little Things

Identifying areas for improvement is one thing, but squeezing them into your product roadmap can be much harder. When you’re normally applying a ruthless prioritization philosophy, there’s scant space for seemingly trivial tweaks.

1. Organize your roadmap using themes

Theme-based roadmaps shun listing out specific features for broader goals and objectives. You can then slip in some smaller changes underneath the corresponding umbrella theme.

For example, if there’s a “Checkout” theme in which you identified opportunities to expedite billing by automating invoice creation or saving credit card numbers for future purchases, those can slot for that initiative.

If there’s enough work to warrant it, you can create a theme or OKR around user experience. One that’s chock full of minor changes that will create a net positive effect.

Watch our expert panel discuss how product managers can use themes and a north star metric.

 

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

2. Build a “small stuff” sprint into your cadence

As your product experience grows more complex and the userbase more diverse, there will always be little issues cropping up. Issues that could address with a little bit of development work. If these keep piling up and can’t seem to address during normal operations, work with your engineering team to schedule an occasional “small stuff” sprint every three or four or five sprints.

The work can be limited to these smaller tweaks, along with bug fixes and work required to minimize technical debt. Once these become routine, your wish list will shrink over time. Then the whole product will get the regular maintenance it likely needs.

3. Include a non-technical swimlane in your roadmap

Many minor details don’t require coding or manufacturing. They lie completely at the feet of other parts of the business. Don’t be afraid to hold them accountable by including their initiatives to improve the customer experience on your roadmap.

This will increase visibility, create more urgency, and ensure these tasks follow a consistent process and get the oversight they need. And, once stakeholders get used to it, they’ll wonder why there wasn’t one there all along!

4. Use the Kano model

Keeping your minor improvements visible is a major step in actually getting them done. If you use a Kano-style roadmap, those small-but-important to-do items won’t languish in a backlog or parking lot.

Every time the team looks at the roadmap, they’ll see it as a reminder. During those rare moments when a developer or engineering team has a spare cycle, they’ll be able to easily grab one and fit it in as they wait for the rest of the release to wrap up.

These “extras” might only take a few hours or days, but their impact can be a major gamechanger for the users they affected.

 


Takeaways

Seemingly minor or insignificant aspects of the overall product experience play a huge role in a product’s reputation; by using a roadmap and including small wins into your strategy, you can see the product’s ultimate success.

Download Product Roadmaps: Planning Your Strategy➜

The post Missed Details That Can Cause Huge Product Reputation Ramifications appeared first on .

Posted on

5 Key Skills of Outstanding eCommerce Product Managers

Marketplaces like Amazon and eBay have built such outstanding online shopping experiences that consumers now take these experiences for granted. Creating a world-class eCommerce platform takes tremendous effort, teamwork, and strategic planning. For forward-thinking online retailers, this means hiring an eCommerce product manager.

What Is An eCommerce Product Manager’s Product?

Although the job description can vary from company to company and across industries, product managers all share at least a couple of common responsibilities. They drive the development of their company’s products. They own ultimate responsibility for the market success of those products.

For a company that makes high-end kitchen appliances, this role is relatively straightforward. The product manager will be responsible for the product strategy and development of the company’s kitchen appliances.

But in the case of an eCommerce company, the product manager’s role is less clear. Let’s say a retailer sets up an online store for musicians to buy instruments. This store includes noise-reducing headphones, recording equipment, etc. What is that eCommerce site’s product offering? What are they selling?

On the surface, the answer is obvious: Products for musicians. But that’s only partly accurate. Yes, an eCommerce platform is an online resource that helps shoppers and buys find a variety of products. But the company is also selling the market a different type of product: a high-quality online shopping experience. That experience is what an eCommerce product manager is responsible for overseeing.

Here are some of the most important skills you’ll need to succeed in this role.

List of 5 skills for an outstanding e-commerce product manager | ProductPlan

5 Skills for an Outstanding eCommerce Product Manager

1. Fluency in eCommerce tech.

The overall user experience of an eCommerce website or app consists of many technological components. Here’s just a few examples:

  • The shopping cart, ordering, and payment-system applications
  • Code is written to dynamically create a custom experience based on user, device, previous visits, etc.
  • An inventory management system that syncs the site with current inventory details
  • APIs that connect the site with the company’s shipping partners
  • The site’s overall health and performance: speed, bandwidth, uptime, etc.

The eCommerce product manager has to make sure all of these details are in place, performing according to plan, and working together. If something goes wrong, the product manager needs to be able to grasp the underlying technical problem—to know how to get it fixed quickly.

We’ve written here at the ProductPlan blog that a product manager doesn’t need to be technical, even to manage technical products like software. But there are exceptions to this rule.

We’re not suggesting that to succeed as an eCommerce product manager you’ll need to learn to code. ECommerce is such a competitive industry. Customer tolerance is so low for problems during their online shopping experience. Due to this, a product manager will need thorough technical knowledge to be effective in this role.

2. An excellent sense of timing.

Prateep Krishnan, Director of Product Management at Xpanse Inc., provided ProductPlan with this must-have skill for eCommerce product managers.

As Prateep explained to us, eCommerce is a date- and event-driven industry. Product managers need to keep this in mind as they build their product roadmaps and release plans. The last thing an eCommerce company that sells floral arrangements wants is to discover is that a new feature they just released is bringing the site down… on Mother’s Day.

“You have to carefully plan, execute, and deliver your major features at least one quarter before [holidays and key events],” he said.  “You also have to watch your usage metrics (conversion, session recording, dropouts, etc.) like a hawk and be on the lookout for any unexplained deviation in the weeks leading to those shopping days.”

One of our key takeaways from Prateep’s great insight was that eCommerce product managers will need to develop a strong sense of how long their team’s development cycles take. As well as how much lead time to factor in for various types of coding tasks. This will allow them to work backward in their strategic plans. In addition to building in enough time and resources for key releases ahead of those big shopping days and weeks each year.

When they develop their strategic roadmaps, eCommerce product managers will want to highlight the relevant major shopping dates—Valentine’s Day, Cyber Monday, the Holiday Season—prominently on those roadmaps.

3. World-class prioritization skills.

ECommerce product management involves a lot of juggling. You will always have more tasks, ideas, and requests on your backlog than the resources to complete them. When you add in Prateep’s point about having to devote additional focus to key shopping days and events, you can see where your time and resources will be even more limited at certain times throughout the year.

This means you will need to become highly skilled at prioritizing tasks, projects, and strategic goals. You will need to be able to conduct an objective, clinical assessment of competing user stories or enhancements for your eCommerce platform and make strategically sound, data-supported decisions on which items to work on first.

One best practice is to use a weighted scoring approach. Create a common set of criteria to evaluate all possible stories, features, bug fixes, etc., and then prioritize the development of the ones that score the highest.

For example, you might create several criteria to represent potential benefits—boosts revenue, increases customer loyalty. Then estimate a score for each of these categories to each competing item. Then you’ll do the same with potential risks: effort level, operational costs, etc.

Score every item on your potential to-do list against all of these criteria. You’ll tally up the totals to determine the projects most strategically advantageous to work on next for your eCommerce site.

Sign-up for the guide to prioritization ➜

As for those user stories, features, and enhancements that didn’t make it to the top of your priority list right now—but that your team believes are worth implementing? They’ll go on the backlog. You can add them to your sprint planning when your team frees up the time and resources, or when they’ve risen to the top of your strategic priority list.

4. Data-analysis wizardry.

According to 2019 research reported by eTailInsights, there are more than 7 million online retailers in the world and 1.8 million in the US alone. As an eCommerce product manager, you should always assume that you’ll have a lot of competition from other online retailers. Regardless of what type of product your company is selling.

The field is so competitive. Which places downward pressure on every online retailer’s prices. One of the few ways you’ll have to differentiate your eCommerce platform from others is the quality of your customer experience. That means you need to be testing, gathering, and analyzing data, and continuously applying your learnings to improve your site.

Here a few of the types of data you’ll want to be monitoring and using to improve your platform’s experience:

  • Visitor bounce rates
  • Average time on page
  • Average user visits per day, week, month, etc.
  • System health and performance levels
  • Traffic patterns and trends by days of the week and various times of day
  • How price changes affect campaign response rates, site visits, sales, etc.
  • SEO keyword ROI
  • ROI from email marketing and social media campaigns
  • Average purchase amount per session
  • Average purchase amount per user over a given period (say, each month)
  • Your Net Promoter Score (NPS), customer reviews, and other user-generated feedback

This list could go on. But here’s the takeaway: You’ll want to be conducting A/B tests on many aspects of your eCommerce platform’s functionality and user experience, carefully studying your visitors’ behavior, and analyzing all of this data regularly.

To make your site more compelling and profitable, you’ll need to dig into the numbers to learn what’s working and what needs work.

Download Product Success Metrics ➜

5. Outstanding communication skills.

We’ve pointed out many times on this blog that every product manager needs to be a great communicator. There are several reasons for this. For example, product managers have to communicate their roadmap strategy to stakeholders, an important step in the process that can require both persuasiveness and finesse.

Also, because their work involves coordinating with many different teams across the company—engineering, sales, marketing, support, the executive staff—product managers need to know “developer-speak” and the unique languages of each department.

Finally, product managers need to be able to say no to requests on a regular basis—but without jeopardizing important relationships with colleagues and customers.

These realities all hold true for eCommerce product managers as well. But for this industry in particular, there is another reason that communication matters so much.

Takeaways

Unlike many products, an eCommerce platform is a living, frequently changing experience. Products change. Prices change. The layout and presentation of inventory changes. In fact, an eCommerce site or mobile app can create a different and unique experience every time a user visits its pages. In other words, an eCommerce website itself is a conversation.

One of the many strategic responsibilities of a product manager in this industry is to understand what each visitor to the eCommerce platform is “asking.” How the platform can “answer” in a way that is as concise, personalized, and compelling as possible for that user.

To put this another way, when you visit an eCommerce site that compels you to buy—indeed, makes you feel good about the purchase—you can be confident that behind that site is a great eCommerce product manager.

Read the Product Manager's Guide to Prioritization

The post 5 Key Skills of Outstanding eCommerce Product Managers appeared first on .

Posted on

What Is the Best Way to Communicate Roadmap Status to Your Team?

This question popped up on one of the product management forums I am part of. What I really love about this is the team wants to share their product roadmap – that’s a great first step.

Sharing your roadmap can only lead to better communication, both internally and externally. Above all, it keeps your team aligned and working towards the same goals and outcomes, so instead of working against each other you’re actually working with each other. 

Now there is no wrong or right way when it comes to sharing the product roadmap – the important thing really is that you’re doing it.

At ProdPad we use ProdPad (duh!) and everyone has access to view the product roadmap. The great thing is every user has the ability to set their own views, so whether one is looking to get a really high-level view or a breakdown of the ideas involved, the flexibility is there for each user to set that visibility for themselves.

Communicating your roadmap
There are different views available in our roadmap publishing feature

Sharing your product roadmap with customers

Additionally, we also share our roadmap externally with our customers. This is important for two reasons:

  1. It helps our customers understand what we’re working on and why
  2. It helps our team have conversations with our customers about what we’re working on and why

But wait… there’s more

It’s not enough to just make your roadmap visible internally, the next step is to actually talk about it. Our Senior Product Manager, Kirsty, has roadmap catch ups with our customer-facing team every couple of months so they are up to date with how things are moving forward. This isn’t a release or sprint catch up, it’s a strategic chat more than anything, and helps our customer-facing teams plan their own roadmaps around similar strategic initiatives. 

Now remember, your product roadmap is about communicating what you’re working on, why, for whom – and above all, how these problems you’re looking to solve are actually going to make an impact for both customers and business. With that in mind, we also have quarterly reviews of how our objectives and key results are doing, so that everyone can be kept up to date about what the impact of the work we are doing is. This is the chance for everyone to focus on those outcomes, and as a team understand our own success.

How do you share your product roadmap? Leave us a comment below and let us know 👇

The post What Is the Best Way to Communicate Roadmap Status to Your Team? appeared first on ProdPad | Product Management Software.

Posted on

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.

Posted on

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.

Posted on

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 .

Posted 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 .

Posted 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.

Posted on

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.