Roadmap Management – Product Management Confabulation

March 25, 2022

Product Roadmap Best Practice – 6 things to avoid!

Best practices for product roadmaps is one of our favorite topics here at ProdPad. (This comes as a surprise to no one. We’ve built a whole software around it!)

Yet sometimes the best way to understand something is to look at what it’s not. So, on the other side of the coin, what are the worst roadmap practices that you should avoid?

Here are 6 of the most common faux pas that smart, well-intentioned product managers and larger product teams tend to make with their roadmaps.

1. Putting a timeline on the product roadmap

Focusing your roadmap around dates is a bad move. Often called a “timeline roadmap,” this method often results in planning way too far in advance. Your team commits to deadlines and loses the flexibility to iterate, change, and adapt. Of course, you must be able to adapt to situations – be that world events, market shifts, anything.

Does a timeline equal product roadmap best practice?

Bottom line: Planning too far ahead is a waste of energy and traps you into building things that might not be the top priority. Dates belong on release plans. Learn about the difference between roadmaps and release plans.

2. Too customer-driven

Absorbing customer feedback is a hallmark of good product management. But there is a limit. Being too driven by customer demands will turn your roadmap into a series of feature requests, and therefore a list of solutions that you’re going to build (see #4 and #5). As a product team, you become too reactive. Building small iterations or tinkering with features based on how customers wish they would work will eat up much of your time.

The other point to consider is who you’re reacting to. You might consider yourself customer-driven, but actually you’re listening to whoever speaks up the most. The squeakiest wheels are commandeering your product strategy and prioritizing your product roadmap.

Bottom line: It’s very easy to be driven by a small handful of vocal customers, and that’s the danger of being too customer-driven with roadmap and product planning.

If you’re doing that, you’re giving up the chance to take a step back and ask: What big problems could we be solving for the wider market, which our customers aren’t necessarily asking for now, but would solve their problems too and allow us to grow faster?”

Your customers don’t always know what they need, and they certainly don’t know the best strategic choice for your company.

3. Too data-driven

Yes, it is possible to be too data-driven, especially when it comes to excessive A/B testing. You’re trying to over optimize.

In my (perhaps controversial) opinion, A/B testing is just an expensive way to disagree. When you opt for an A/B test to give you an answer, that means you don’t have a real conviction either way. Both options would probably be okay. So instead of choosing one and learning from it, you build it twice. That’s twice the resources and money.

More often than not, you don’t end up with a statistically significant enough outcome to validate that option A is better than option B, or vice versa. To reach a reliable outcome, you either need a lot of users or a long time of testing. Neither of these really apply to small startups, when you’re just building traction or needing to move quickly. On the other hand, huge multinational corporations can afford to move slowly, and their small A/B tweaks can actually add up to $1 billion in annual revenue.

Bottom line: All these little tests seem like good work, but they’re not bringing you results. You’re optimizing to no effect. Instead, you should take a step back and look at the larger problem. And of course, aim to make data-informed decisions when possible.

4. Prioritizing at the idea level

Poor prioritization is a downfall of many product teams, no matter how great your research, ideas, or backlog grooming. Like some of the other faux pas in this list, focusing on ideas (or features or solutions to build) means you’ll likely miss big opportunities and the real value you could be providing to your users. When you center your own ideas and then prioritize them, you’re basically taking an assumption and multiplying it by another assumption!

I also don’t recommend RICE or other weighted-scoring algorithms for this reason. Learn why these methods are problematic and which prioritization model could be best for your team.

Bottom line: Don’t focus on your ideas, focus on the problems that need to be solved. When you prioritize at the problem level, you’re moving the boulders before you move the pebbles. Once the big things are positioned correctly and fit together well, then the smaller stuff can fall into place and get taken care of in due time.

5. The roadmap is a list of features

Let’s face it: a lot of product people think of their work as a way to keep the development team busy. As if development is waiting for work to do, and the product team is just filling the pipeline. But actually, PMs need to work with the wider team, think holistically about what else could be done, and generate experiments to solve larger problems.

By taking a step away from features and functions, you can think about product strategy from all angles. Does a new feature need to be built, or does the product need new positioning? Could we package or price the service differently, use different marketing copy on the homepage?

Bottom line: Product can work with the rest of the company – and also with the development team! – to work through challenges that don’t necessarily involve features.

6. Keep the product roadmap hidden

All too often, product teams make a roadmap and then keep it to themselves. There’s a misconception that it’s internal only, or that you must have one roadmap only. In fact, you can spin out multiple versions and share them accordingly!

The internal version contains all the minute details. This is so internal stakeholders can see not just the problems and why they need solving, but also how you’re going about solving them and what the outcomes were.

The executive version can leave out the nitty-gritty stuff, because executives don’t care or just shouldn’t hear about it. (That creates more questions and takes too long to explain!) Create a high-level version, perhaps showing multiple roadmaps in one space.

The customer version can simply show which problems you want to solve. It’s not a list of promises. Remember, you’ve removed the dates! Instead, the roadmap is a place to validate that you’re working on the right things – and customer feedback is excellent for this validation. If certain parts of the roadmap don’t resonate with customers, then you can probably deduce that it’s not important right now.

Bottom line: Share different versions of the roadmap with different stakeholders. Transparency and communication will make your life easier, and will also build trust and satisfaction among the team and your users.

The post Product Roadmap Best Practice – 6 things to avoid! appeared first on ProdPad | Product Management Software.

February 9, 2022

Your First Roadmap Shouldn’t be Perfect!

Getting started with a roadmap is daunting. I know this because I coach people through it all the time.

They are often faced with this mental roadblock of wanting to craft this perfect, complete roadmap that articulates their strategy perfectly and struggle to take the first steps towards creating anything at all. We’ve all been there!

It’s why I often include a caveat when I’m showing people through our demo and Sandbox environments of ProdPad. The roadmaps are too good. After all, these are demo environments, and we’ve been iterating on these for months and years.

Your first roadmap shouldn’t look like this:

Instead, I’d be proud if your first roadmap looked something like this:

Why? Because a roadmap is a prototype for your product strategy.

As simple as you can articulate and test. And in the case of a product strategy, that’s usually outlining some key problem areas or opportunities you think are noteworthy, and laying them out in the order you think they should be tackled.

That’s your first roadmap.

Is that what you’re going to go DO and build now? Oh hell, no! That would be incredibly presumptuous. On par with taking your back-of-napkin sketch of an untested idea and ordering a developer to go build it.

That first roadmap is a starting point for learning. Now that you’ve laid out your assumptions, you’ve got a handy way to check them with other stakeholders and see what holds water or not.

And your first roadmap is going to be imperfect. Your stakeholders are going to pick holes in it. Product managers need to have thick skin for exactly this reason. You’re not here to be right. You’re here to facilitate the discussions to get us all to better.

Over time, and over the course of lots of useful and enlightening discussions, you’ll start to unpick what the real problems and opportunities are, and what order your team can tackle them in to be most likely to achieve your objectives and reach your ultimate vision. Over time, your roadmap will be iterated on, and move from the hot mess you started with, to a cohesive strategic plan.

It’ll become more granular and useful to a wider range of stakeholders. It’ll be more robust, as it’s sense-checked with more and more eyes and brains from around the organization. It’ll look more like the roadmaps we showed you in your ProdPad demo when you first got on board.

It’ll never be 100% perfect though. That’s a bit of control that we’ve all just got to let go of. After all, we don’t have perfect information, so we can’t craft a perfect plan.

The right format for your roadmap!

The Now/Next/Later format of the roadmap has that sense of imperfect information built right in: You’ve got higher granularity of information about things right in front of you, and less for things further and further out on the horizon.

Your roadmap is meant to have this flexibility built-in so that as you learn, you adapt. Your roadmap flexes and is updated based on new information, and so what was considered the best roadmap for the information of the time is set aside to make way for a constantly iterated version of that roadmap, always showing the best version for the information at hand.

So always remember: Your first roadmap is not going to be perfect. Far from it! Embrace the fluidity of the imperfect assumptions, nowhere near set in stone.

Your final roadmap won’t be perfect either. It’ll just be the best representation of what you know at the time, which should be informed by all the insights and inputs you have access to as a well-connected product manager.

Let go of perfect. Get roadmapping instead.

The post Your First Roadmap Shouldn’t be Perfect! appeared first on ProdPad | Product Management Software.

January 13, 2022

How to Clean up a Big Messy Product Backlog

At some point in your career, you will have struggled with a messy product backlog. It can be one of the biggest problems that product managers face – maybe it’s currently the bane of your life!

Clean up a Big Messy Product Backlog and bring order out the chaos — Bringing order out of the chaos of a messy product backlog

At ProdPad we’ve seen and coached hundreds of companies through the process of cleaning up a messy product backlog. And our experience is that product managers are usually confronted with not only the problem of a huge backlog of things that could be done, they also have the problem of finding a way to prioritize and order what should be done.

We also find that most companies have a development board like Trello or Jira containing columns or sections for things to do, things that are being done, and the things that the development team says have been done. But the board typically ignores what happens after things are said to have been completed. What’s more, the to-do list becomes huge and full of bad ideas, because every tweet, customer comment, email, whatever, is dumped there. Product managers end up with that big messy backlog we’re always hearing about, half bugs and dev tickets and half ideas and specs.

Take the example of ProdPad client Tillo, a reward and gifting management platform. In this podcast, Tillo’s Chief Product Officer Eddie Sawyers runs through how he uses ProdPad to organize his product backlog. When he joined Tillo, all ideas and feedback were in disparate places – emails, Slack, spreadsheets, whiteboards, post-its, JIRA – there was no centralized place to visualize the company’s plans. Eddie has found that moving to ProdPad has allowed him to clean up the product backlog and given him a central place to see the company’s plans.

So how do you do it?

Gather the information

Before you can sort the backlog out, you need to bring it all together into a single list. The chances are that you have lists all over the place of things you could do. Get everything in one place in a CSV format (Excel, we love you!) and you’ll be well on the way to getting organized.

Top tip – don’t bother worrying about the things that are already being done – you can leave them in your dev tool, unless you think they should be stopped. If that’s the case, you should speak up!

Get organized

Before you can really make progress, it’s best to separate the list into the following

Things that definitely are approved and waiting for devs (no need for product manager intervention)
Customer feedback
Ideas that are definitely not ready for dev and need to be approved/specced
Anything you don’t quite understand

Anything in list 1 belongs in your development tool and should be triaged as you go so that you can constantly pay back technical debt. List 2, customer feedback, is a great way to validate your solution ideas, so you need to separate that from list 3 (solution ideas). If you’re not sure whether something is feedback or an idea, don’t worry – it can be both, and should be in both lists.

For list 3 (solution ideas), scan the list and do a preliminary triage. Update or delete records as needed, perhaps even add a column and use it to tag or categorize right on the spot.

We’re often asked, “what is the difference between feedback and ideas?”. In essence, ideas represent something you will do, make, change, remove or ideally test. They need to be spec’d out and defined in a way that the development team can understand and work on. Feedback is what was originally said by your customer. It usually is in their own words and represents evidence of the importance of the idea. We love to see a single idea linked to multiple pieces of feedback, with high levels of feedback identifying a greater need in the market. By separating feedback from ideas, you build a picture of the biggest demand from your customer base.

For list 4, you might want to run a brainstorming session or workshop with key team members, so you can decide what to do with those few items that don’t make sense. They should ideally belong in one of the other lists, but they can be worked out later if they’re not urgent.

Get it all in one place

The next step is to import your ideas and feedback into ProdPad! A shameless plug of course, but ProdPad was built to solve this exact problem. By using a tool which is designed to help you manage your backlog, you are able to manage the data in a way that lends itself to good prioritization practices and better outcomes.

One great benefit of this process is that you can go back and close off any old unstarted development tickets in Jira, Azure DevOps, Trello or whatever you use. Your development team will love you for it. If you want to make sure you have full traceability back to the original source, include the URL of the original ticket in your import so it’s easy to find later.

Make your product backlog actionable

You now have a product management database full of feedback and ideas. There’s no avoiding the fact that clean-up is required, but ProdPad will help you with this.

ProdPad’s smart AI helper, DotBot, will help you spot links and duplicates in your product backlog. As you use triage mode to work your way through your ideas, DotBot will appear if it spots potential links or duplication between ideas, or identifies that you have customer feedback supporting an idea. Make the relevant links as you go to do the cleanup without the grunt work.

Using the inline editing options on your feedback and ideas lists also helps – you can quickly scan each item and update the relevant information as you review. Sometimes this is easier in small groups – can you assign groups of ideas to others based on numerical order, product or area of interest? Bulk editing could be your friend here too – just select one or more items and add tags, personas or other information in one fell swoop.

It’s a good idea to do your backlog clean-up in batches, tackling (say) 10-20 ideas per day. It doesn’t sound like a lot, but you’ll quickly get to the point where you have reviewed all the ideas in your backlog and have the information you need to make good decisions at your fingertips.

Top tip – Use the unsorted/backlog tabs to differentiate between the items you’ve reviewed/updated and the ones you still have to do.

Create your Product Roadmap

Now we get to the fun part! Instead of a messy backlog, you have a structured product backlog full of ideas to consider, supported, and based upon a list of customer feedback. The next step is to create your product roadmap.

This isn’t an overnight process, but you can start simply and create a roadmap outline which starts conversations about what to do next. Up to now, we’ve been working “bottom up” – we’ve looked at what we’re being asked for by our customers, and maybe the colleagues around us. It’s time to think “top down” to help us make decisions about what to tackle first.

Think about the big picture first – vision, objectives, and problems to solve. Read our blog on working top down and bottom up to get a roadmap that meets the needs of your customers and your organization. You’ll soon see the fruits of your labor and feel that the big clean up operation was totally worthwhile.

The post How to Clean up a Big Messy Product Backlog appeared first on ProdPad | Product Management Software.

January 5, 2022

New Year, New Product Roadmap – Embrace Roadmap Bankruptcy

As we enter a new year and a new planning cycle, many product people find themselves in a knot about what to include in their product roadmap.

One of the biggest challenges is figuring out how to fit in all the things that weren’t done from last year, AND all the things that have made it to the wishlist for this year. Roadmaps come with a lot of baggage.

Product roadmap bankruptcy

There’s a concept I call Roadmap Bankruptcy, and it’s actually really freeing. If you’ve got a crap roadmap, just go push it all to the side tomorrow and start with fresh eyes. Throw out your old roadmap and start again.

Only when you’ve gone through the process of recreating and checking your assumptions with colleagues about what should be on there, should you go back and compare to your old roadmap.

You might find that there’s a bunch of stuff that didn’t get back on there. Features that seemed important last year, but when stacked against the problems and opportunities you’ve faced this year, they just don’t make as big a difference as you once thought. That’s okay and healthy! It’s a sign that you and your team are learning and adapting based on what you’re seeing in the market and with your customers’ needs.

Anything that didn’t get added back in represents a whole bunch of unnecessary work that you just avoided for you and your team. There’s nothing more lean than that!

You’ll also probably find that new initiatives will find their way into your product roadmap this year—things that weren’t even mentioned in a previous roadmap. This is healthy too. Oftentimes, the act of putting aside your attachments to previous plans—ie. Last year’s roadmap—means you can think more freely and openly about what you should really be working on.

Try this out today:

A risk-free way to rethink your roadmap and check if you’re on the right path.

Step 1: Starting afresh

Save your existing roadmap somewhere safe. You’ll refer back to this later, but you probably won’t return to that particular roadmap again. You’re starting afresh

Step 2: Start a free trial

Start a ProdPad trial, and head on over to the Roadmap builder page for your product. It gives you lots of space to work through the initiatives and related product work ahead.

Step 3: Create initiatives

In the Candidates column, create initiatives to represent each problem or opportunity that lays ahead for your business. These aren’t generally feature-related, but a level above—more like the problem that needs to be solved. We’ll add potential solutions and feature-level details later on, but it’s important to start with problems.

Our product experts sometimes find it helpful to phrase these initiatives like questions, rather than like statements.

Step 4: Prioritize these problems into Now, Next, and Later

Don’t feel like you have to get this perfect on your first stab. Your aim here is to lay out the steps you think the product should take in order to progress towards the objectives and vision that have been outlined.

Think of this process more like prototyping rather than ‘pixel-perfect’ designing your plan. Your goal is to lay out your assumptions of what problems exist and which order you could tackle them to maximize your success, and then use your roadmap to share those assumptions with others so they can be checked and adjusted.

The more open and flexible your roadmap is at this point in time, the more robust of a strategy you’ll ultimately come up with.

Step 5: Roadmap solutions

Map out potential ideas or experiments that could solve each problem. Once you have a good idea of the overarching steps in the strategy (the set of problems to be solved, and the order you’ll tackle them), you can start seeing how you might break it down into concrete product experiments and iterations that’ll make the impact you’re aiming for.

In general, you want to identify at least 3-5 different experiments (we call them ‘Ideas’ in ProdPad) that could be run to try to solve each problem identified on the roadmap. This way, you’re not ‘falling in love with your idea’, a warning shared by Teresa Torres when she talks about her Opportunity Solution Tree (which works really well in conjunction with the ProdPad format of Now/Next/Later!)

Step 6: Compare with your old roadmap

Compare your new Now/Next/Later roadmap with the one you left off within Step 1. What new problems did you identify that you’d missed off with your previous version? If these are, in fact, important problems, then this roadmapping exercise has been well worth it! Anything that helps identify problems that might have been unrecognized or uncommunicated is time well spent.

What was left off the new roadmap? Now that they didn’t fit the mold for your new year’s plans, are they really that important? If you forgot something that was truly important, then it’s a good time to reassess this new roadmap and figure out where these sit in the bigger picture. More important or less important than the other things you and your team identified?

You will almost certainly find that some things are left off the roadmap, and frankly, don’t need to be added back on. By taking this step back, you’ve been able to put your fresh eyes on things and see a new path to meeting your goals.

Step 7 and beyond…

Continue sharing and iterating on this new roadmap as you learn more and more each day this year.

The post New Year, New Product Roadmap – Embrace Roadmap Bankruptcy appeared first on ProdPad | Product Management Software.

September 8, 2021

Fix your prioritization problems with a lean roadmap

Have you ever thought about how the implicit assumptions you make in a timeline roadmap could impede your prioritization of the real problems that need to be solved?

Before I started to use a lean roadmap format, I found that every month, like clockwork, I would push forward items on the roadmap and rearrange the order. Here was a roadmap that should be showing what order and when we would deliver things – except it changed constantly.

The reason my roadmaps changed so much was that we would release something, gather feedback and then realize that our assumptions were wrong. Those same assumptions underpinned our prioritization and consequently the Gantt roadmap. The constant change made a nonsense of our timeline roadmap.

As my experience shows, if product roadmaps are to work and be useful to organisations they need to embrace uncertainty and assume change.

The trouble with timeline roadmaps

Timeline roadmaps, or Gantt charts, assume that you know what you need to do first, second, and so on, from a list of features that you want to build. But in reality, product managers usually have a backlog of features and no real sense of the order to build them.

What’s more, the prioritization algorithms and frameworks that allow product managers to give order to their backlog – RICE, Weighted Scoring and the like – all share the fundamental assumption that there is an absolute order of delivery (or importance) between the different features.

The assumption is necessary to ensure that timeline/Gantt roadmaps are usable. They need an order of features to build that doesn’t change with time. Timeline roadmaps only work with the assumption that priorities are absolute and don’t change over time.

But priorities change. They change with markets, as products evolve, and as users evolve. The dynamics of user needs, desires and market forces mean that there cannot be an unchanging order for building features.

A timeline roadmap/Gantt chart isn’t really a roadmap, just a list of features that need to be built.

Embrace uncertainty with a lean roadmap

A lean roadmap embraces uncertainty and assumes that things will change. It’s not about features, rather problems that you can solve.

With a lean roadmap you still have to choose the order of which problems to tackle and when. You can use frameworks like RICE or Weighted Scoring with a lean roadmap, but neither are ideal. This is because both assume an absolute order, whereas you are prioritizing relative to the other, strategic, problems.

It’s better to prioritize by looking at how the problems support the product and company strategy through achieving the objectives. Then you can look at how that works with the market and product feedback about the problems. Have a look at this post, Putting it all Together – Creating a Lean Objective-Based Product Roadmap for more detail.

Summary

The style of roadmap you use determines your approach to prioritization, but you should beware the fundamental flaw of assuming that an unvarying, absolute order exists with a timeline roadmap. In reality most product managers inherently recognize this in all the tweaking and eventual manual re-ordering of priorities that they do. Ultimately, you can’t really fix that fundamental flaw by tweaking. Lean roadmap and native prioritization approaches are better suited to the reality of product management.

The post Fix your prioritization problems with a lean roadmap appeared first on ProdPad | Product Management Software.

August 5, 2021

Examples of Product Backlogs and How to Manage Them

Product backlogs come in all shapes and sizes, many of them very, very long. So how can a product manager (PM) organize and structure all these ideas so the right ones always make it to the top? That takes a combination of technology and teamwork.

In this post, we’ll cover a few product backlog examples from a few different angles and how these formats can help you prioritize ideas.

Product backlogs

First off, I’d like to make clear that these suggestions are around the product backlog, which is separate from the development backlog. I touch on development backlogs a bit more below. (I also have some choice words for weighted scoring algorithms!)

The job of a product manager or product owner is to look at all the things that the team could do, and ultimately decide what the team should do. This means time spent discovering, validating, and invalidating different hypotheses and solutions that are listed as tickets in a backlog.

The backlog is only as valuable as the conversations it enables. These collaborative conversations around your roadmap are essential to building the best version of your product! Product managers, product owners, developers, and people from other functional teams should all be able to read, question, discuss, and understand where the product is headed and why.

That said, here are some ways your team can structure all of the tickets, ideas, and possibilities so that discussions and backlog grooming are smoother and more efficient.

Ways to view a product backlog

List

This format is as straightforward as it sounds. Everything you could possibly do is listed here. In a way, it’s the heart of a product backlog, a valuable collection of feedback, ideas, and discovery.

But, although each ticket is likely tagged, categorized, and color-coded, this long list might not be the best format for actually managing and prioritizing ideas. It’s great as a repository and reference point, but it’s not much of a tool for conversation or decision making.

Priority Chart

This approach literally charts ideas according to effort and impact, providing a super clear overview of quick wins, worthwhile investments, and no-go ideas. Each ticket is represented as a dot on the chart. The effort required to make it happen is measured on the X axis, its impact on the business is measured on the Y axis.

As a result, each quadrant represents a category of solutions: low effort-high impact (the easiest decisions), high effort-high impact, low effort-low impact, and the section you likely won’t touch — high effort-low impact.

In ProdPad you can filter this even further according to customer demand, team popularity, or how thoroughly the product spec has been written.

Priority chart - a different way to view a product backlog

Workflow

Here you can view your backlog through the whole product management workflow, from acknowledging brand new ideas to QA testing fully developed features. Each ticket appears at whatever stage of development it currently sits.

The great perk of this format is that it provides full visibility into the product development process, especially to people on other teams. They can see the status of certain features of fixes and learn about what else is in the pipeline.

Internal transparency is a key part of most company cultures, and ProdPad’s workflow view helps create it across teams.

Roadmap

You can also look at your long list of ideas through the lens of your product roadmap. Don’t look at the backlog as a whole. It’s too much information which, taken all together at once, doesn’t really tell you anything about what you should do next.

Instead, think back to your roadmap and the problems you’re trying to solve. Problem A will have corresponding ideas for solutions in the backlog, as will Problems B and C. So if your team prioritizes at the problem level, then that organizes the backlog according to ideas A, then ideas B and C. It becomes clear what your options are and why you might try them. In ProdPad, this view is simply called “Your roadmap,” and it’s one of my favorite approaches.

Quick note on development backlogs

The structure or style of the backlog will always follow the development method of the team.

For example, a Kanban backlog will cater to a pull flow. The most important tickets will be at the top of the list, and developers pick from the top as they have the capacity. The team typically has three buckets of items in development: doing, testing, done. Each bucket has a limited number of items according to how many developers are actually on the team.

Scrum backlogs cater to a push flow. The tickets are scoped, selected, and prioritized according to what can fit within a one, two, or three-week sprint — however the team structures its dev cycles. A definitive number of tickets are approved for this sprint, and they’ll move through development as a batch.

How not to manage a product backlog

The #1 piece of advice I have on what not to do is unfortunately a widespread practice in the product management world: using weighted score algorithms. I’m talking about RICE and ICE and other acronyms that are used to prioritize backlogs automatically.

Weighted scoring algorithms just aren’t as helpful as we want them to be. In my experience, here are the outcomes of using them:

The product manager ignores the algorithm. The system will suggest a certain top 5 items, but the PM immediately starts on item 7 because they intuitively know that #7 solves a real problem for the business.
The product manager ignores their own intuition. Never a good idea. Now they’ll likely spend time working on what’s actually the wrong thing.
The product manager tweaks the algorithm to match their intuition. The algorithm becomes increasingly complex without telling them anything new. What a waste of time!

Plus, relying on technology to tell us what technology to build misses a very crucial element I’ve already mentioned a few times here (and many other places on this blog): conversation. Collecting feedback and collaborating on potential solutions should be on-going throughout the development process, not just when we create a ticket or write a user story.

At the end of the day, no matter how you structure or view your backlog, remember that it is a living, dynamic record of your team’s creativity and your product strategy. The backlog doesn’t dictate what you will do; rather it’s a tool for decision making and direction taking.

The post Examples of Product Backlogs and How to Manage Them appeared first on ProdPad | Product Management Software.

February 11, 2021

If You’re Hitting All the Dates on Your Roadmap, You’re Doing It Wrong

Imagine a product team out for dinner and drinks. They’re celebrating a big win. The product manager, development team, product owner, maybe even a couple of company executives are there. They must have achieved something significant, right? A revenue milestone? Important roadmap deadlines? Reaching a target number of customers? A positive product review in a major industry publication?

What if I told you the team is celebrating the fact that they released the new version of their product a day before the internal deadline on their roadmap? That might be cause for celebration. But maybe not. Pushing out a new feature or product—even if you do it on time—is only one way to measure team success. And it isn’t the best way, not by a long-shot.

Before this hypothetical product team starts raising their glasses and making toasts, they might want to wait for the answer to a far more important question. Will our customers be enthusiastic about this new product release?

Themes—Not Dates—Are the Stars of Your Roadmap

A product roadmap conveys the strategic direction and goals of your product. I like to think of a roadmap as a brief, clear story of how and why a product will impact the market.

That’s why you want to arrange your roadmaps into themes—those big-picture goals your team sets out to achieve. You want your team to focus first on product strategy, not deadlines. When stakeholders view the roadmap, you want them to easily grasp the story behind your planned work in the coming months. For a B2B software maker, those themes might look like these:

Enable a self-serving buying experience online
Create a free trial download
Develop a scaled-down product at a lower price to attract single-license users

That tells a story. It depicts a company that’s thinking strategically. The themes on this roadmap show the product team is trying to find new ways to reach customers, doing business with them more convenient, and reposition their product to find new markets.

But what if, instead of themes and strategies, the most prominent elements of your roadmap were dates and timeframes? Imagine if what stood out on your roadmap were these:

Complete in Q2 2021
Release March 17
Push live by the end of January

Where’s the story behind this roadmap? Where’s the vision, strategic thinking? What is this company even building? Your product roadmap should be a strategic guide, not a calendar.

The deadlines won’t matter in the long run.

To put this another way, let’s say Microsoft adds a feature to its Teams collaboration app. Unfortunately, the new tool falls flat with users.

Now imagine that the product team launched this new feature by the internal deadline they set for themselves. In a year, is anyone in the company going to say, “Well, that Teams widget was a disappointment, but at least our product team released it on time”?

Yes, Dates Are Important to Product Success

At this point, you might be wondering if I put much value at all on dates and deadlines. Absolutely. Product managers always have limited resources—including time.

You’ll need dates and deadlines for several strategic reasons, including:

Helping your team weigh which items it can work on over a given timeframe
Giving your developers a sense of how to structure and schedule their work
Keeping your team on pace with relevant events, such as tradeshows or holidays
Gauging your effectiveness at driving products forward according to plan

So Why Shouldn’t We Hit All Roadmap Deadlines?

If you can achieve everything you want strategically for your product and still meet every deadline on your roadmap, you might be ready to think bigger. Empowered product management teams are constantly adjusting course to meet their customers’ evolving needs and the market.

A product roadmap should be somewhat aspirational. Its themes should include at least some stretch goals that may not be clearly defined and require creativity and lateral thinking. Creating a roadmap with space for learning and insights means you will be ready to take advantage of new opportunities. It also means you can regularly question if your original roadmap delivers the most value to your customer.

This is why I’m skeptical about any team’s ability to set those big strategic goals for their product but still get all of their projects done on time.

And if you have to choose between these two competing goals—aiming big with your product or hitting all of your roadmap deadlines—I’d highly recommend you choose to aim big.

A Deadline Culture Has Nasty Side Effects

Becoming date-focused on your product roadmap is dangerous not only because it can take your team’s attention away from the strategy they should be focusing on. The risks are much greater than that.

Here are some of the negative side effects of prioritizing roadmap deadlines over themes:

1. Focusing on deadlines assumes you have nothing to learn.

When planning your roadmap, you have a good idea of the problems you are looking to solve, whether framed as jobs to be done, business objectives, or even features. You likely have some hypotheses about how you will solve them and even the technical challenges, but you should be prepared to learn along the way. Reserve space for additional validation and discovery, and be open to learning that you need to make some changes. You may find the problem isn’t worth solving or that it’s no longer the highest priority due to market trends. Alternatively, you may find that to solve it well, and you need to do much more than you planned. If you are focused only on meeting the deadline, you are not delivering the best solution possible.

2. You might set deadlines later than necessary to make sure you hit them.

In a company culture that treats deadlines as its prized metric, product managers will undoubtedly be tempted to set their roadmap deadlines out as far as possible. What better way to ensure “success,” as the company defines it?

But when you take this approach, you also under-use your developers, product owners, project managers, and other team members. You might not be allowing your team to function at top capacity and do all the great work they’re capable of.

3. You might aim too low because you’re afraid of upsetting stakeholders.

A date-obsessed product team also runs the risk of playing it safe, under-promising, to hit their deadlines. This often happens in organizations whose executives focus on deadlines over other success metrics.

But your senior leadership’s obsession with roadmap deadlines can’t be your excuse to limit your strategic goals or vision. As a product manager, it is your responsibility to show your executive stakeholders that you have big goals for your product. You’ll need to persuade them that achieving those goals will be more important than whether you hit your roadmap’s deadlines.

4. You might prioritize work, not for its strategic value but because it seems easiest to complete on time.

And what an innovative and impactful product that will be!

Failure can be a powerful teacher. If you set aggressive deadlines for a project and miss it, that can still yield some successes. For example, it can help you discover important details about your team’s capacity and pacing and any shortcomings of your processes.

But even more important, building a culture that allows for a degree of failure—such as missed deadlines—also encourages more innovation and risk-taking. Both are keys to building products that make a positive impact on your market.

How to Deal with Roadmap Deadlines

Having said all of this, I do believe deadlines can play a useful role in your product roadmap. After all, I’ve overseen the development of the date-based milestone feature on ProductPlan’s roadmap app.

But you need to make sure your team treats roadmap deadlines with the proper amount of weight. Your team shouldn’t ignore the deadlines on your roadmap, nor should they think their success rests on meeting those dates.

Here are a few steps I’d recommend:

Build a team culture that emphasizes product quality first (even above deadlines).
Set a success rate for hitting deadlines that you’ll be happy with. It should be a high percentage but below 100%.
When your team fails to hit a roadmap deadline, please don’t treat it as a reason to reprimand your coworkers or to hang your head in shame. Instead, learn from those misses.

As a Product Manager, Your Real Goal Isn’t on Any Calendar

As you drive your products’ development and continuous improvement, you’ll want to hit your deadlines whenever you can. That’s one way to measure how effective you are in your product management role.

But it’s not the end in and of itself. The goal behind any product management effort—releasing a new feature, for example—is to benefit both your customers and your company.

Remember: Your primary role as a product manager is to solve real problems for your market. It’s not to deliver those solutions on June 11.

Want More Helpful Roadmapping Advice?

The post If You’re Hitting All the Dates on Your Roadmap, You’re Doing It Wrong appeared first on .

January 26, 2021

The Roadmap Revolution: A Chance to Hit “Reset”

It’s that time of year where I’m both overwhelmed and excited to work on my roadmap. Maybe it’s the feeling of a fresh start and an empty calendar. Perhaps it’s all those social media resolutions to eat better or work out more or learn a new skill. Or maybe it just has enough time off from work to form some new perspectives. Whatever the reason, there’s no questioning that January is the official home of the “Roadmap Revolution.”

Why the Roadmap Revolution?

During this time of promise and possibility, we allow ourselves to begin anew, mix things up a bit, and try something different. Revolution is a chance for a fresh start. The old way doesn’t have to be the only way going forward.

You can change the things you want to change. You’re empowered to make things as awesome as you want them to be.

When it comes to your roadmap, it’s an opportunity to clear your “mental cache” and reemphasize what’s important. We can take a step back from the daily grind, recenter, and focus on what will move the organization toward its most important goals and objectives.

This reexamination is difficult when you’re in the throws of business as usual. Our roadmaps get loaded down with baggage over time. Then inertia sets in, and we stop questioning why things are on there because they’ve become the status quo. We don’t have the time or mental bandwidth to ask ourselves if the “why” is still valid or if there’s a critical missing piece we’ve overlooked.

But the start of the new year is our chance to hit reset, take a deep breath, and resurvey the landscape. At ProductPlan. write and share resources on roadmaps all the time on our blog and in our Learning Center. Part of the landscape resurvey we see is roadmap readership grows by 68% in January. The Roadmap Revolution bug is making everyone hungry for learning and improvement in the new year.

Tweet This:
“Roadmap readership grows by 68% in the month of January. The Roadmap Revolution bug is making everyone hungry for learning in the new year. ”

While it’s likely not time to scrap everything and start from scratch, there’s no better opportunity for a seismic shakeup.

Some Data that Shows You’re Primed for Change

The roadmap revolution doesn’t happen in a vacuum—you’re still going to need stakeholder alignment and executive buy-in for your new master plan. But there is more openness to change and optimism about the future during the early part of the calendar year.

In January 2020, there was a flurry of activity in ProductPlan’s roadmap platform. We found that our customers shared roadmaps 39% more often than they did the other 11 months in the year. They also make changes to legends 57% more frequently. Bar dates were edited an extra 23%.

If your company happens to use January as the start of its new fiscal year, other changes will create a more open environment. Not to mention there’s still time to influence budget and lobby for more tools for your product stack.

What Your Roadmap Revolution Might Entail

Everyone’s experience may vary when it comes to their own roadmap revolution. Outdated, misaligned, or unfocused items will be dependent on one’s individual situation.

Take a lingering look in the rearview.

New years are about what lies ahead. But it is important to start with an examination of what’s already happened. Think back on the past year and break down how you and your product roadmap got to its current state.

Were there technical breakthroughs or blockers that shifted the course? Did a competitor’s actions cause a scramble to react? Was an overbearing client or juicy prospect throwing its weight around and disrupting plans?

While your organization’s reactions to these events may or may not have been appropriate, they inevitably sideline other initiatives. What deserves a second look? And knowing what you know now, are they still the right items to prioritize?

Beyond these disruptive forces, what did you learn last year? Whether it’s data-driven insights sifted from analytics or a deeper insight into what makes the management team members tick. What do you know today that twelve months ago was a mystery?

Adjusting your style.

In addition to these external factors, we’ve hopefully applied some introspection to ourselves as well. We all have areas we can improve upon. Those can even surface in our product roadmaps through subtle nuances or deliberate decisions to steer product strategy.

Switch things up to a Kanban view, so they focus less on “when” and more on “why,” if stakeholders are too obsessed with dates and deadlines.
Ditch the specifics and move to a theme-based roadmap emphasizing overarching objectives over specific deliverables if your roadmap looks more like a feature factory than a strategic plan.
Try adding color-coding and a legend to provide additional context if the motivation behind roadmap items isn’t clear.
Employ swimlanes if you’re trying to help stakeholders visualize how work maps to various implementation teams or parts of the product.
Add a key milestone or two if you can’t completely ignore dates but don’t want them to dominate the roadmap conversation,
If you want to show how the whole master scheme comes together and break down some silos, use a portfolio view to show all your products’ high-level roadmaps on a single screen.

Employing any (or all) of these visual elements can add entirely new dimensions to the roadmap experience. Do this to communicate much more information and explanation from the same page.

Revisit your story.

Product leaders are storytellers, and product roadmaps are key to the tales we spin. But is the story we shared last year the same one we want to spread in the year to come?

Over time, the setting evolves, characters change, and our goals and objectives may shift. Now is the time to ensure the roadmap reflects the story we want to be telling, not the one we gradually slipped into.

Resetting the roadmap to ensure it focuses on outcomes versus features is a critical step in this process. Assess whether the themes are still appropriate and match the latest thinking, or if it’s time for new ones to emerge and phase out older ones.

If your roadmap doesn’t help you tell the story you want to tell, make that change. Convert features into value statements, and don’t treat it like a parking lot. Hold every item up and make sure its “why” is still valid.

Planting the Seeds for the Roadmap Revolution

Roadmap revolutions don’t happen overnight, and the best-laid plans begin months before the true shakeups take shape. Starting in November, I connect with engineering and implementation teams for some reality checks.

North Star

I layout where we want to be two years out as a North Star of sorts and work backward. What must happen this year so that vision can happen in Year Two. This drives what our 12-month roadmap for the coming year must contain for the longer-term vision to have a fighting chance while ideally giving current customers some true added value in the interim.

Backlogs

This also sets the stage for the hardest part of roadmapping… cutting out the clutter. Our backlogs and parking lots are full of great ideas, but we can’t do them all. So, if they’re not helping us set the stage for our ultimate goals, cull them from consideration.

That’s not always easy. You’re disappointing internal stakeholders and customers. You’re taking ownership of sunk costs and broken promises. But this is the hard work of progress and evolution and the only way to excel in the areas the organization prizes most.

Don’t forget to position your own team for this new outlook. You don’t want to dump a new roadmap on them and tell them to “make it happen.”

Squad Recalibration

Set aside time right before or after the New Year’s break for a little squad recalibration to ensure everyone knows the new plan and is happy with their role in it. It’s an excellent time to shift roles and responsibilities if appropriate, which can also be energizing for team members to embark on this journey’s latest leg.

You want to create momentum and get people talking about the most important things in the right way. Reconnecting the product’s daily activities and nuances to the business and overall objectives create renewed motivation and clarity regarding adding value. But don’t assume they’ve parsed it all perfectly; make sure they’ve connected the dots in their own minds for optimal results.

The Roadmap Revolution is Real

You might be thinking this is all just an excuse to reiterate how pivotal roadmaps are to the product management process. Still, people really do spend more time roadmapping in January than at any other time of the year. We see spikes in product trials, usage data, and web site searches, indicating this is a genuine phenomenon.

Best of all, this process can be inclusive and engaging for stakeholders across the organization. While you’re tweaking the product’s plans, your sales team is going through its own reevaluation. Ask them if their target account list has changed or if they’re shooting for a new vertical this year.

It’s also a great time for customer service and account management check-in to see what trends they noticed over the course of the previous year and which product capabilities users are asking about lately. Likewise, aligning with marketing regarding their messaging to the market and major activities.

Touching base with key customers themselves can also pay dividends. They’re going through their own revolutions and resolutions as they set their own goals and outlooks for the coming 12 months, and their shifting priorities may influence which value propositions your own product should emphasize.

The post The Roadmap Revolution: A Chance to Hit “Reset” appeared first on .

December 16, 2020

How to Run a Collaborative Roadmapping Exercise with Your Team

You’re a product manager, and you need to run a collaborative roadmapping exercise with various teams across your company. Not sure where to start? We’ll walk you through the process, step by step.

What is a Collaborative Roadmapping Exercise?

A collaborative roadmapping exercise is an ideation meeting. People from different departments brainstorm, share insights, and work together to determine what direction to take the company’s product next.

As the leader of this exercise, you bring together all appropriate stakeholders for an open discussion about your product’s strategic priorities.

The result of this meeting might be a set of ideas that support your existing roadmap strategy. Some ideas might come out of this exercise that persuades the group to make fundamental changes to the roadmap and take the product in a new direction.

Organizing a Collaborative Roadmapping Meeting: A 10-Step Process

Because we’re living in the COVID era, let’s assume you’ll need to virtually run this meeting. The good news is, with a team collaboration platform such as Microsoft Teams, you can easily create an entirely digital environment built around your collaborative roadmap exercise. This environment can help you with every stage of the exercise: before, during, and after. Here’s how.

Before the Meeting

Step 1: Invite the right people.

In the next section, we’ll discuss which departments and teams you’ll want to be represented in your meeting. For now, the key is to set up a dedicated collaboration platform for this group. We’ll assume you’re using Microsoft Teams. You can create a “Collaborative Roadmapping Team” or “Roadmap Ideation Team.” When you’ve completed your attendee list, send them an invite to a Microsoft Teams video meeting.

Step 2: Ask invitees to prepare strategic insights and ideas.

Include in your invitation a request that all participants come to the meeting with any strategic insights, particularly what they’ve gleaned about your market, product, or personas. Also, ask them to bring any ideas they have for the product.

Roadmapping Basics | Common Roadmap Communication Challenges — Learn about some common challenges communicating product roadmaps. Our panel of expert product managers from ProductCamp SoCal share their experiences.

During the Meeting

Step 3: Review the existing product roadmap.

During this ideation meeting, you will use your current roadmap as the centerpiece to kick off the discussion. As the product manager, it will be your job to open the meeting by walking the team through your existing roadmap and strategic goals.

Step 4: Summarize the relevant market conditions.

After you’ve reviewed the roadmap, you’ll want to talk your attendees through the state of your market. Has a crucial competitor been acquired? Is your target industry undergoing an economic surge or falling on difficult times? What has changed in your market, and how could those changes affect your product?

Step 5: Open the meeting up to brainstorming and ideation.

You’ve reviewed the current situation: your roadmap, your goals and plan for the product, and your market’s conditions. It’s time to open up the meeting for discussion. Here you are looking for attendees to share their unique perspectives based on their market interactions. Ideally, those insights will spark conversation, debate, and new ideas.

Step 6: Weigh competing ideas and vote on priorities.

You’ve reviewed the current situation: your roadmap, your goals and plan for the product, and your market’s conditions. It’s time to open up the meeting for discussion. Look for attendees to share their insights based on their market interactions. Ideally, those insights will spark conversation, debate, and new ideas.

Pro tip: You can measure the strategic value and costs of competing ideas using several prioritization frameworks. Weighted scoring and opportunity scoring are just two of the many proven approaches. We have an entire book filled with them:

Step 7: Assign action-items for pursuing any new ideas.

Let’s say you’ve settled on a few potential new strategic priorities for your product. Maybe your team has voted to try opening a new market or going after a new user persona. Your next steps will involve research, resource planning, and other logistical work. Now it’s time to assign those tasks to the right people. Here’s what this might look like:

Let’s say your company is a software maker for the healthcare industry. Your current flagship product is a billing and time-management app that addresses the unique needs of medical practices. Today, your crucial client base is the small doctor’s private practice.

During your ideation meeting, the team brainstorms a new idea: Make a few strategic changes to the app, and you can market it to small dental practices. After voting on several other suggestions, the group decides this is the most viable idea. At the end of this meeting, you and your team assign action items to the relevant people:

Action item: Determine the Total Addressable Market (TAM) of small dental practices.

Action item: Conduct a competitive analysis. (Which companies are already solving this problem? Can we do it better?)

Action item: Develop user and buyer personas for your product at these dental practices.

Action item: Do an assessment of resources, capacity, timeline, budget, etc.

After the Meeting

Step 8: Send out a recording of the video meeting.

You discussed a lot of big-picture insights and ideas in your collaborative roadmapping exercise. It will be valuable for all attendees to have a digital recording of the meeting. Fortunately, if you were using Microsoft Teams, you were able to record the entire video conference. Now you can send it out to everyone through the “Roadmap Ideation Team” channel you created on the Teams platform.

Step 9: Conduct and share all relevant research with the team.

Set up a dedicated digital environment for this ideation group. BeBecausecasuse you can now all share whatever research and additional insights the team generates based on the action items they took from the meeting. Here’s where you’ll want to upload your research on the Total Addressable Market for the new adjacent market, for example. You’ll also want to share the user or buyer persona you’ve drafted based on the post-meeting research you’ve done.

Step 10: Update your roadmap accordingly and share it with the team.

Finally, we’ll assume your team’s research led to a new strategic direction for your product. You will want to update your existing product roadmap to reflect this change and then send the entire team’s updated roadmap. If you’re using Microsoft Teams and the ProductPlan roadmap app, you can easily share these roadmap updates through your Teams platform—using the ProductPlan-Teams integration.

Note: In this hypothetical, we’re assuming you’ve earned the okay from your executive staff to move forward with whatever changes in the direction your team agrees on after your ideation session. But that executive-approval step requires a lot of strategy and planning as well. If you’d like help, read this blog written by ProductPlan co-founder Jim Semick:

Who Should Attend Your Collaborative Roadmapping Exercise Meeting?

This meeting should include representatives of departments across your company who have one thing in common. They should all have direct interaction with your market, your customers, and your prospective customers. That will include teams such as:

Sales

You’ll want both sales leaders and reps in your ideation session. These are the people hearing the requests, concerns, and needs from your user and buyer personas every day. They also hear objections, which means they know where your existing product falls short and might need retooling.

Pre-sales (or sales engineers)

These are the experts who help your sales team with the technical aspects of the sale. They regularly sit with prospects and customers, discussing the technical needs, goals, and frustrations of these companies. Their input will be valuable in your collaborative roadmapping exercise.

Customer success

This is another team of front-line professionals in your company who have direct contact with your customers regularly. They have a sense of the common challenges or shortcomings with your products. They might also have other insights they don’t even realize are valuable. For example, maybe your CS team fields many questions from a user persona your sales team didn’t know was actually using your product.

Professional services

This is the group of implementation experts, training specialists, and other post-sales professionals who work with new customers to roll out your product for them. They’ll have a unique set of insights and maybe some useful ideas about strategically improving your product.

What Are You Trying to Get Out of Your Meeting?

Above all, collaborative roadmapping exercises should be outcome-driven. You don’t hold these meetings just for fun. Before you schedule one of these sessions, you need a clear idea of what you want the meeting to accomplish.

If we had to boil down the goal of a collaborative roadmapping exercise into a single objective, it’s this. You’re trying to answer the question: What’s the next thing we should be doing strategically with this product?

Want More Helpful Roadmapping Advice?

The post How to Run a Collaborative Roadmapping Exercise with Your Team appeared first on .

December 16, 2020

How to Run a Collaborative Roadmapping Exercise with Your Team

What is a Collaborative Roadmapping Exercise?

As the leader of this exercise, you bring together all appropriate stakeholders for an open discussion about your product’s strategic priorities.

Organizing a Collaborative Roadmapping Meeting: A 10-Step Process

Before the Meeting

Step 1: Invite the right people.

Step 2: Ask invitees to prepare strategic insights and ideas.

During the Meeting

Step 3: Review the existing product roadmap.

Step 4: Summarize the relevant market conditions.

Step 5: Open the meeting up to brainstorming and ideation.

Step 6: Weigh competing ideas and vote on priorities.

Step 7: Assign action-items for pursuing any new ideas.

Action item: Determine the Total Addressable Market (TAM) of small dental practices.

Action item: Conduct a competitive analysis. (Which companies are already solving this problem? Can we do it better?)

Action item: Develop user and buyer personas for your product at these dental practices.

Action item: Do an assessment of resources, capacity, timeline, budget, etc.

After the Meeting

Step 8: Send out a recording of the video meeting.

Step 9: Conduct and share all relevant research with the team.

Step 10: Update your roadmap accordingly and share it with the team.

Who Should Attend Your Collaborative Roadmapping Exercise Meeting?

Sales

Pre-sales (or sales engineers)

Customer success

Professional services

What Are You Trying to Get Out of Your Meeting?

Want More Helpful Roadmapping Advice?

The post How to Run a Collaborative Roadmapping Exercise with Your Team appeared first on .