Here at the ProductPlan blog, we’re always looking for great ideas we can share with you. Which means we read a lot more than we write. One of our favorite sources of great ideas—for products, for businesses, for leadership, you name it—is the blog of design consulting firm IDEO. (Respect!)
You’ll find all sorts of gems on that site, so we highly recommend you visit it regularly (after you bookmark the ProductPlan blog, of course). But to give you an idea of the thought-provoking, creativity-unleashing insights you’ll find there, here’s a brief list of our favorite takeaways from our favorite recent IDEO posts.
This post uses the 2016 presidential election to make the point that most of us tend to notice primarily (if not only) those things that reinforce our existing belief system or worldview. As IDEO explains it, this is our “filter bubble.”
At ProductPlan, we’ve warned in previous posts about building a narrative—because once you have one in place, you’re likely to discount and possibly even completely fail to see anything that contradicts that narrative. This is why judges and lawyers warn juries not to develop an opinion as to guilt or innocence until the trial is over; if they make a determination prematurely, those jurors could miss evidence that cuts the other way.
“Step outside your filter bubble to make sure you’re truly seeing the big picture when you strategize about your products and your company.”
You almost certainly have your own filter bubbles—around your products, your market, your company, your competitors, your user persona, and maybe a few others. Which means that you need to step outside that filter bubble to make sure you’re truly seeing the big picture when you strategize about your products and your company. You might discover insights that had been there all along.
So what does IDEO blogger Neil Stevenson suggest for getting out of your filter bubble? He’s got lots of practical suggestions: talking to different types of people, intentionally avoiding groups and conversations with people who think like you, etc. Read the full post.
You’ve probably heard this advice before, but it’s always worth revisiting. In this post—called 3 Ways Boredom Can Unlock Your Creativity—IDEO blogger Katie Kirsch makes the counterintuitive case that the last thing you should expect to flood you with great ideas is the nonstop stream of information, entertainment, and communication coming at you through your devices.
Nope. What all of that noise is actually doing is keeping your subconscious mind from pushing great insights and ideas into your consciousness. Those insights can’t surface in your mind because the channel is already blocked with a constant series of external inputs.
Katie’s advice, then, is to just sit there. Literally. Be still, be silent… and, if you can manage it, be bored. That’s when you open the channel to let in the brilliant stuff your mind wants to tell you.
So, how do you get to that calm, quiet, and unplugged state? We won’t steal IDEO’s thunder: Read the full post.
This post offers an insight similar to the first on our list, about stepping outside your filter bubble. Bursting your research bubble, though, is even less intuitive and will be even more difficult. After all, while we all recognize that have filters and biases—and that this is probably a bad thing—many of us would argue with the notion that research can be a drawback.
But IDEO blogger Owen Sanderson isn’t arguing against research here. He’s simply reminding us that we need to balance data with our “inner listener,” as he describes it, our intuition, and even perspectives that might challenge the data we’ve collected.
This post opens with the line, “Oh god, not another meeting!” So they’re already speaking our language—yours, too, we’re guessing.
In this wonderful post, IDEO bloggers David Boardman and Marco Righetto offer creative and practical advice for running meetings that don’t elicit eye rolls and profanity when the invites hit your colleagues’ inboxes.
If you run meetings with your team, or if you just attend them but have influence over the meeting host, we strongly suggest you check this blog out.
Just one of their great ideas: Create a distinct brand identity for your meetings. How interesting is that?! For more cool suggestions, read the full post.
Okay, this one is probably our favorite. We don’t know anything about the inner-workings of the airline industry or what’s involved in managing a commercial airport. The industry itself has nothing to do with what makes the post so ingenious, nor do any of the specific (and mostly great) ideas they offer for fixing the aviation industry’s many problems.
What’s so awesome about this blog is that it allows you to flex your own creativity muscles in a context that has nothing to do with your own professional life. (We’re assuming you’re not in the airline business.)
Once you start doing exercises similar to the ones the IDEO blogging team describes in this post—“Hmm, how could we make it less maddening to get through the security check-in line?”—you’ll find you can’t stop. You’ll be coming up with inspired ideas for every industry and every area of your life. Your mind will be redesigning the ATM experience, shopping-cart returns at the supermarket, ordering at a drive-through window, you name it.
And as that redesign muscle gets stronger, it’ll be eager to help you and your team build better products.
You’ve seen it 100 times in movies and TV shows. Something horrible is about to happen—an asteroid is hurtling toward earth, a pandemic is coming, zombies, whatever. Government officials in a secret bunker are arguing about what to do, and the conversation turns to how to alert the public. That’s when one character always says… “We can’t tell the public! It’ll cause a panic!”
Whatever side you take in that movie scene debate, you have to admit the “It’ll cause a panic!” character raises a valid point.
Transparency Can be a Smart Business Strategy, But…
You already know this intuitively and from your own life. Think of just a few of the everyday circumstances in which being transparent could be totally counterproductive.
It could ruin a surprise party.
It could needlessly upset your young child’s worldview, when you tell her that it was you who put that dollar under her pillow when she lost her baby tooth.
It could hurt your friend’s feelings and ruin her night, if you see her at a party and tell her you think her outfit is all wrong.
We believe creating a culture of transparency in your business can be an effective strategy. That’s why our team here at ProductPlan takes an approach that leans toward transparency both internally (we share information openly and often across the company) and externally (we’re quite open as a company with our customers and the market).
We’ve even built a tool into our product roadmap software that helps users facilitate transparency in their own companies: a Sharing Custom Views feature that lets teams share visions, strategies, and tactical-level plans with various internal and external audiences.
But the question “Is transparency a good idea?” can’t be answered intelligently without context. There are contexts in which being transparent can create value for everyone, and others when all you’ll do is unnecessarily upset people. Let’s look at a few examples of each.
Examples of Bad Transparency
This is a common misinterpretation of organizational transparency. Many companies think that being transparent means telling their customers and the public everything, so they share every detail of their plans, their progress, their setbacks—every step their organization takes.
The problem is, most people who are getting those frequent communications, including even the company’s most devoted customers, aren’t going to find all of those details interesting or worth their time.So in their misguided attempt at transparency, these over-communicators instead just become a nuisance.
Emphasizing the Negative
Companies sometimes also mistakenly believe a culture of transparency means going out of their way to let everyone know all of the bad things happening internally at their organization.
This misread actually makes some intuitive sense: A company might believe that the more candid they are with their market about their internal struggles, the more trust they’ll build.
Problem is, when these companies begin broadcasting all of their negative news, they can actually overdo it and create an exaggerated sense of how bad things are. They might chase away would-be customers who mistakenly view the company as perpetually troubled.
Sharing Problems Without Solutions
Here’s yet another way businesses get transparency wrong. They alert their customers to some piece of bad news— here’s a bug in their software, they’ve lost some customer data, their customer support site is offline—but they fail to offer any solutions to those problems.
From the customer’s point of view, the company that they’ve given their business and their trust just wanted to let them know something bad has happened and… well, that’s about it.
“Transparency can be a smart business strategy, but avoid over-communicating, emphasizing the negative, or sharing problems without solutions.”
So now customers are upset (even the ones who had no plans of contacting the inaccessible support team and would never have known or cared about the downtime). The relationship between those customers and the company is strained. And the company has lost some trust.
Will this company get much benefit from being transparent? Our guess: Not likely.
Examples of Good Transparency
Sharing Both What You’re Doing and Why You’re Doing It
Transparency can strengthen your relationship with customers and your market only to the extent that the information your company shares actually has value for those audiences.
So simply broadcasting a list of things your team is working on probably won’t be the best use of transparency—because unless your customers know how those items on the list will affect them, sharing it won’t have much value for them.
But if you share your plans for rolling out a new feature for your product and explain why you’re confident the feature will benefit your users, then you’re using transparency effectively.
Sharing Problems With Solutions
Let’s say a user of your software product contacts your Customer Success team to let them know they’ve discovered that a certain action taken in your software causes the whole app to crash.
If you blast out a communication to your entire user base alerting them to the issue, technically you’re being transparent. But you aren’t being helpful.
Now let’s say that as soon as you heard from your Customer Success team about this problem, you and your team instead immediately went to work figuring out both a short-term solution (a workaround in the current product that lets a user complete the task without crashing the app) and a long-term solution (prioritizing that fix for the next release).
If you send out a communication explaining both the bug spotted by a customer and your solutions for it (including the one your users can use right now), you’d be using transparency effectively.
Always Being Honest (Positive, But Honest) With Your Team
Before you should even begin to worry about how much information to share with external audiences like your customer base and the general public, you should first focus on striking the right transparency balance with your own team and the rest of your organization.
Your cross-functional team, after all, will be the ones responsible for helping you deliver a successful product to the market in the first place. The only way to make that happen is to make sure the team is built on open communication and trust.
This is why it’s extremely difficult to be an effective team leader—a key part of a product manager’s job—if you’re keeping information from the team, even when the news is bad. Plus, when you’re transparent with your team about the challenges the project is facing, you also empower your team to make better-informed decisions for the project.
You don’t want to go overboard, though, and bombard your coworkers with every worrisome detail you come across. That can give them an exaggerated sense of the product’s setbacks and undermine their own confidence and enthusiasm.
But if you can find that balance—always sharing as much information as you believe your team needs, but not deluging them with details—you’ll be using transparency intelligently.
Your Transparency Checklist: 5 Things to Ask Yourself
As we stated earlier, the team here at ProductPlan tends to favor transparency (both internally and for our external audiences) whenever possible. But we still take a strategic look at the information we’re considering sharing and weigh the pros and cons before we hit send.
Here’s a simplified version of that strategic approach we take. Have a look at the following checklist of questions to ask yourself about any piece of information you’re considering sharing with your audience.
Will it benefit our customers?
Will it benefit our company?
Will it benefit our product?
Do our customers really want to know about it?
Will it strengthen our relationship with our customers?
Figuring out what your customers will truly want—not what they say they will buy, but what they will actually buy and use—is one of the biggest challenges a product manager faces. It’s often just as difficult to learn how your existing customers are actually using your product in their everyday workflows, and what (if any) hacks or workarounds they’ve developed to make your product simpler or more productive for them. These insights would obviously be a boon to your product, but they’re not easy to come by.
There are a number of inherent difficulties in uncovering these answers using typical “Product” communication channels (product metrics, surveys and sales feedback). For example, here are few common problems you might encounter:
Your market surveys never tell you the whole story.
How could they? Your respondents are limited by the way the questions are framed, and by the fact that they themselves often don’t know exactly what they want. Also, checking a survey box that reads, “I’d be likely to use a tool like this” is very different from actually paying for the tool when it hits the market.
This is why surveys rarely, if ever, lead to those light-bulb moments where you discover a game-changing idea for your product. And while calling your existing customers directly can be a great idea—in fact, you should do this from time to time—you don’t want to over-interpret their suggestions or make generalizations based on the opinions of a few outspoken customers.
Focus-group tests can’t tell you the whole story, either.
According to the “observer effect” in physics, you can’t observe or measure a system without affecting that system’s behavior. The theory was developed to describe subatomic phenomena—like how electrons and photons interact—but the observer effect can also play out in everyday life. It’s why a lawyer grandstands during trial when there are cameras in the courtroom.
This can also affect the results you receive from your user focus groups. When they interact with your product in front of your team and answer your questions about it, are your prospective customers being honest? Are they just telling you what you want to hear about your product because, after all, you’ve given them snacks and drinks for their time and you’re treating them so nicely?
Your sales reps can’t—or won’t—tell you the whole story.
One place many product managers go for “real world” feedback is their sales force. That makes sense: Your sales reps are out in the field pitching your products, learning what appeals to prospects and understanding what their objections are. In theory, your sales team is compiling real-world market research that your product team should find valuable.
But your sales reps also have their own agendas and incentives. They might overstate the importance of a particular feature because they’re confident that including it will help them win one huge customer. And that feature, while a game-changer for that specific company’s processes, might not resonate with any of your other prospects.
So, trying to find the answers you need by going directly to your customers has built-in drawbacks. Relying on your Sales team to tell you how to prioritize your product resources has pitfalls as well. Where else might you find the key customer insights you seek?
Your Customer Success Department: a Hidden Treasure Trove of Actionable User Knowledge
As a matter of fact, there’s a team of professionals at your company, right now, who are gathering real-world user information every day that you could be leveraging: your Customer Success department. And if you’re like many product managers, you might be missing out on this treasure trove of actionable business intelligence just waiting for you in that department.
Think of the things your Customer Success team hears on a regular basis:
What users love about your product
Yes, even on help calls, some of your customers will share their success stories about using your products. Are you collecting that information?
What users hate about your product
You may well hear about these issues from your Customer Success reps, especially if they hear the same issues over and over. But are you talking with those reps to hear the whole story? Are you learning exactly why customers are having the issue, or whether the issue is part of a larger problem with the product?
Creative hacks or shortcuts your customers are developing for your products
What if, in a standard help call, your Customer Success rep learns that a user has found an ingenious way of shortening the steps required to complete a standard task with your product? Think that might be something worth hearing about, so you can use it to update the product or help other customers?
New uses for your products
Sometimes a customer will find an entirely new way to get value from your product—maybe by sharing it with colleagues in a different department that you’d never even thought of as a target user persona. And in discussing some other aspect of your product—even if the call is based on a complaint or concern—your Customer Success rep might learn this interesting new use for your product. Might that be something you’d want to know?
This list is far from complete, of course. There may well be other valuable things your Customer Success team could be learning about your product right now.
Our advice? Build a systematic way for your Customer Success reps to capture this all-important customer feedback and share it with you—so your product team can review it, analyze it, and use it to make better-informed decisions about your product going forward.
“Build a systematic way for your Customer Success reps to capture customer feedback and share it with the Product team.”
At ProductPlan, for example, we have a #customer-feedback channel on Slack that the Customer Success team uses to share relevant feedback from their conversations. This provides a high level of transparency into what the Customer Success team is hearing, and makes it easy to quickly discuss that feedback in real-time.
While a Slack channel might not work for every company, we’re confident that creating a communication channel between Product and Customer Success will help your team build an even better product for your users.
And it can all start with you inviting your head of Customer Success out for a cup of coffee.
If we asked you to think of the most mundane, uninteresting product that came to mind, you couldn’t do much better than to respond with the BILLY bookcase from IKEA. The product is so unassuming, so barebones simple, and so devoid of style that if IKEA tried to shave anything away from it, the bookcase would probably fall over.
Have you ever seen a BILLY bookcase? We’re betting you have. About 60 million of them have reportedly been sold globally—representing almost 1% of the world’s population.
And yet, even though it debuted four decades ago, and even though its look has changed so little in those 40 years that you probably couldn’t tell the difference between one sold in 1980 and one sold yesterday, the BILLY remains the bestselling bookcase in history, and its sales are stronger today than they were when it first hits the market.
Talk about shelf life!
So why are we talking about this? Why, on a product management community blog, are we exploring the history of a bookcase? Because if you’re a product manager—whether you’re responsible for the success of furniture, software or any other type of product—the BILLY bookcase phenomenon can offer you some useful lessons.
Its lack of a distinct style gives the product a longer, um, shelf life.
A story in AdWeek offers a good summary of this point. IKEA intentionally designed its BILLY bookcase to be a neutral piece of furniture, without any distinctive style.
And as you can see, the company succeeded. You can’t get much more neutral than the BILLY. There’s no molding adorning any of its surfaces, no fancy trim, no bullnosing of the shelves’ edges, no modern-looking rivets added for aesthetic purposes. It’s just a bunch of flat, rectangular pieces that fit together to hold your stuff.
Among the many benefits of this strategy (and we’ll discuss others below) was that it allowed the bookcase to fit nicely into the interior of any home or office, regardless of the room’s style or theme. Its clean lines and neutral look also meant the bookcase could last longer in any environment, even as styles, trends and tastes changed over time.
It’s counterintuitive, but building too bold a design into your product—even if that design style perfectly matches your target persona’s current taste—also means it won’t enjoy as long a relationship with your customers. Eventually they’ll want to replace it with something that better fits the new style.
Product Management Takeaway: If you’re building your product, even if it’s software, to match the modern look and feel of the moment, it’s worth asking: Are we limiting the shelf life of our product by developing such an era-specific look, and creating a lot of additional rework for ourselves as the aesthetic of the moment changes in a few years?
Its barebones style allows the company to sell it at a lower price.
An interesting aspect of the IKEA experience, which you’re familiar with if you’ve ever shopped there, is that almost all of its furniture products come packaged in a set of flat boxes—meaning you have to assemble the items yourself (or hire someone to do it for you).
This is another reason the BILLY has been such a steady success for decades. Because the company uses particleboard, medium-density fibreboard (MDF) and other lighter, engineered products, IKEA is able to manufacture, ship and store its BILLY units much more inexpensively than if it instead tried to sell a pre-assembled bookcase made from true wood.
Which means IKEA has been able to make the BILLY one of the most affordable—if not the most affordable—bookcase on the market. As a recent BBC feature explained, IKEA has built a series of “boringly efficient systems” around the BILLY’s production, systems that let the company continually reduce the cost of getting the bookcase to customers, which allows them to make it affordable to an ever-growing market of consumers.
Product Management Takeaway: Every product makes an implicit promise to customers. For the BILLY, that promise is a ridiculously simple, ridiculously inexpensive place to store and display books and other items. Everything else, they’ve stripped away—along with the cost of producing it.
Ask yourself what promise your product makes to your customers, and if there are any elements of your product (design, packaging, features, etc.) that could be stripped away without undermining that promise. If you can do that, maybe you can make your product less costly to produce—and more affordable for your customers.
It became the infrastructure of a creative bookcase movement—which invited more partners than competitors.
Think of the App Store, or the Google Play Store. Other than as the places where you buy your games or apps or music, how would you describe these sites?
One useful way to think about these platforms is that they’re infrastructure—they’re the backbone of the app industry, the marketplaces we all think of immediately when we want to find a new app or develop one to sell.
Could another company come along and build its own app store to compete with Apple and Google? Of course that could happen. But a better use of that company’s resources will probably be to build outstanding apps or games—and sell those products through Google Play or the App Store. Those platforms have already cemented themselves as the industry’s infrastructure.
Which brings us to what might be the most interesting lesson the BILLY bookcase can teach us.
By making the product so simple, so free of its own signature design, IKEA invites customers to make the product their own, to add their own creativity, and to transform the bookcase from an unassuming, almost-invisible piece of furniture into a showpiece for the owner.
Are there competitors to the BILLY? Yes, plenty. But if you Google “BILLY bookcase,” do you know what you’ll find almost immediately after you’ve scrolled below IKEA’s own sales listings for the products? You’ll find hacks.
You’ll find DIY design ideas to make your BILLY bookcase a unique piece of furniture. You’ll find BILLY owners proudly showing off their gorgeous BILLY creations—where they’ve added faux brick backing, rolling ladders, gorgeous paint jobs, crown molding, even built-in window seats.
The point is, you’ll find a community. IKEA’s product designers have not created a defined product but its opposite: a blank canvas that allows any owner to build her own product. In other words, the BILLY isn’t just another low-price-point bookcase; it’s the infrastructure for an entire subculture of DIY creatives eager to use the product to express themselves.
And every time customers learn about a clever BILLY bookcase hack that resonates with them—and, remember, the BILLY hack community happily shares its creations publicly—those new customers are more inclined to go out and get one for themselves.
Product Management Takeaway: Is there some aspect of your product, or even a new product altogether, that you can offer to your market as infrastructure—something they’ll be able to build on, in their own way, to make the product more valuable for their unique needs?
In fact, is it possible that if you spoke with your existing customers you’d find that they’ve done so already? Maybe some users have found creative ways to hook your product into another product, for example, or to use a feature for a slightly different purpose than you’d developed it for, and maybe these DIY improvements—these hacks—add massive value to your product for those users.
“If you find a way to turn your product into a platform that your customers can build on, then you can unlock some tremendous benefits for your business.”
If you can find a way to turn your product into a platform that your customers can build on—or if you can learn about the ways your users are already creatively extending the value of your products—then you can unlock some tremendous benefits for your business. You can leverage the collective creativity of your user base, for example, to build a community around finding clever uses for your products. You can also tap into a community-based sales force that will help introduce your products to new users—just as the BILLY hackers do for IKEA’s no-frills bookcase.
And you might even be able to give your products a longer shelf life.
As a product manager, you have two key roles in your company. Actually you likely have something more like 4,523 roles, but we’ll keep our focus tight. First, you’re the driver of your product’s strategic development. Second, you’re an information hub for the rest of your organization, the single source of truth for all questions, ideas, suggestions, and (sometimes unreasonable) requests relating to your products.
Two roles, two tools.
When it comes to the strategic, big-picture part of your job, you’ll want product roadmap software. That roadmap tool will help you develop, organize, and communicate the high-level strategy for your product, the ‘why’ behind the plan and the strategic objectives you’ve identified.
But after you’ve completed your roadmap, presented your strategy, and earned stakeholder approval to move forward, you’ll then have to start executing your plan. You’ll need to track the day-to-day details and tasks various teams will be working on to turn your strategic plan into a market-ready product. For that, you’ll need the ability to help shepherd these teams through the work. And this is where project management software should come in.
3 Ways Project Management Software Can Benefit Product Managers
As a product manager, project management tools like Trello or Asana can be an invaluable part of your toolbox for several reasons.
1. It helps you translate strategy into discrete, trackable tasks.
When you develop your product roadmap, you’re focused on strategy—why you’re prioritizing one feature over another, for example. But when your executives give you the green light on your roadmap…well, then what?
If you have an intuitive and easy-to-use project management tool, you can translate each strategic element on your roadmap into several actionable tasks. This is part of the process you use to break product features into user stories.
For example, say the roadmap for the collaborative web software your company develops calls for a new notification feature, which will present updates to your users when a colleague updates a project. On the roadmap, you simply needed a one-sentence explanation of the new notification feature. But now that it’s time to start developing, you might need to translate this feature into 10 or more discrete, actionable tasks.
“Project management software should be used in conjunction with product roadmap software to help product managers translate their strategy into discrete, trackable tasks.”
With the right project management software, you can create as few or as many individual tasks as you need to assign and monitor independently, and then roll them up into groups to help you maintain an up-to-date sense of the overall progress of any area of development.
2. It will make you more effective as your company’s touchpoint for product updates.
As we pointed out earlier, in addition to being the strategic driver of your company’s products, your other key organizational role as a product manager is to act as your company’s go-to source for the latest information about the status of your product.
When you’ve deployed the right project management software across your company, you’ll always be just a few clicks away from the most up-to-date status information relating to your product’s development—either for your own knowledge and planning purposes, or in case an executive or other stakeholder asks you.
And the reason it’s so important to use only purpose-built project management software—ideally a streamlined, user-friendly web tool—is that this type of application will give you quick, at-a-glance answers to all of the project and task management questions you or your team might have.
When you log in to your project management tool, for example, you’ll be able to see in just a second or two—using color coding, icons, or other intuitive visual cues—the status of a given task or project. In other words, you’ll be able to immediately answer that stakeholder.
3. It helps you and your various teams communicate and collaborate more quickly and effectively.
Another valuable use of dedicated project management software is the ability to allow various teams, no matter where they’re located, to communicate and share information about tasks using the tool itself.
You wouldn’t want to open your product roadmap up to allow everyone working on any aspect of your product to add notes and comments to the roadmap document. That’s not what a product roadmap is for.
But in the execution phase, the development phase, you definitely want the various teams working on different aspects of your product to be able to share knowledge, ask questions, make suggestions, and learn from each other. That’s why deploying the right project management application is such an important step. Because it allows your team members to add comments, post questions, and even share assets like screenshots or other images, such a platform will help facilitate fast, easy, and convenient collaboration across teams—which will help them do better work, more efficiently, and it’ll help make your life easier as well.
One of the most useful product management insights we’ve heard in a long time comes from a professional poker player. No, seriously. Hear us out.
Annie Duke, a two-time winner of the World Series of Poker, explained recently on The James Altucher Business Podcast that “truth can atrophy.” Annie had this epiphany when she began teaching poker to novices and she realized some of the tactics she had used so successfully years earlier as a player no longer made as much sense strategically.
In Annie’s case, it was when she tried explaining these tactics to her students that she realized for the first time that, yes, they had worked for her—but not for the reasons she thought they had.
And she could just as likely have discovered some of her go-to poker tactics no longer worked as powerfully for other reasons—such as the fact that other players had adopted the same strategies and the elite poker community had learned to spot and counteract them.
The point is, whether you’re a poker player or a product manager, sometimes even the things you’re certain about—your truths—can wear away or change over time.
As a product manager or product owner, you’re probably highly skilled at gathering information. We have no doubt you’ve worked hard to build a valuable knowledge base about your customers, your market, your competition, and the current technologies and best practices that allow you to improve your product and your users’ experience.
But you always need to remember that any part of the knowledge base you’ve built—even the elements you consider fixed, permanent realities—can and probably will change. Moreover, failing to spot these changes can undermine your product.
With that in mind, here are some things we think you should be testing regularly—even if you consider them to be settled truths.
Test what you’ve already tested.
Let’s say three years ago your product team went to your target market to gauge their interest in a new feature for your flagship product, or maybe an entirely new product. And let’s say the market said no.
If the idea for that same feature or product came up in a meeting tomorrow with your cross-functional team, we’re guessing you’d say, “Tried it. No interest.” That makes sense. You tested it, and you received a clear answer.
But truths can atrophy.
Maybe things in your market have shifted. Maybe the competitor that was already supplying the feature to your market (which you didn’t learn in your surveys because they didn’t ask that specific question) is no longer in business. Or maybe the industry has experienced enough turnover that there are plenty of new decision makers at your prospect companies who would be interested today.
“Just because you tested something once doesn’t mean you have an answer forever.”
Bottom line: Just because you tested something once doesn’t mean you have an answer forever.
Test your successes.
Direct marketers—the people responsible for filling your home’s mailbox with junk mail—are always testing their packages, even their winners. And that’s one key reason they make a fortune.
Because the industry has been learning and refining its strategies for more than a century, direct marketers know that even today’s hugely successful direct-mail package has a finite shelf life: Eventually everyone who’s going to buy the product or take whatever other action the package calls for will have done so. Marketers can’t run the same package forever, so they continually test other packages with limited audiences to find the winner’s eventual successor.
The same principle applies to your products. PMs can understandably get complacent when their product is a hit. Things are working, after all. Why mess with success?
First, as we can learn from direct marketers, you can’t afford to stand still. Today’s steep upward sales trajectory will eventually begin to slow, and then eventually begin to fall. So even if you find your feature or product is a winner, you need to begin testing other features and other products to fill that sales pipeline for the future.
And second, maybe you’ll find that another feature makes your successful product even more successful. So why not keep creating new things, and keep testing them?
Test your sales process.
Let’s say sales for your product are strong. That’s great news. But… why are they strong?
Are you doing well because you’ve got a couple of sales rock stars who do some kind of voodoo sales magic that nobody else in the organization—including the other sales reps—understands? If that’s the case, okay, enjoy the results those sales superstars are generating for as long as you can.
But understand that having a few sales geniuses on your staff isn’t scalable, and it won’t necessarily last forever. That truth can atrophy as well.
So test other ways of generating sales.
Test your data.
Data has a way of cementing quickly and permanently into a company’s reality. The statement “We have data on that” tends to shut down a debate.
But maybe your truth about what your market wants or what’s really resonating with existing customers comes from a flawed or incomplete data-analysis model.
Are you looking at the right usage data and drawing the correct conclusions from it? Is the information you’re gathering and analyzing mostly anecdotal or self-reported, as opposed to something you can view and verify firsthand?
Don’t assume that just because you are compiling data you’re getting the best answers.
Re-examine your methods of data collection, review and analysis, as well as whatever conclusions your team is drawing from that data.
Test your own assumptions.
Finally, you need to test your own assumptions.
This isn’t to say your gut instinct on any given point is necessarily wrong. You might have even put an assumption to an evidence-based test and found it to be correct.
But remember: Truths can atrophy. That’s why we’re suggesting the other types of testing above, which could demonstrate that some of your assumptions—even the once-accurate ones—are incorrect today.
Your gut told you your target personas were worried about data in the cloud and would therefore demand an on-premises solution. And when you asked them three years ago, you found out you were right. But are they going to be as concerned about cloud security today? Maybe it’s time to test what you’ve already tested.
Or perhaps your gut tells you to target a certain revenue number for a new product launch based on what you’ve seen your sales team generate from previous products. But maybe those revenue numbers have been artificially low, because instead of an efficient process across the entire sales team you’re relying on just a couple of sales stars. Maybe it’s time to test your sales processes.
“There’s nothing wrong with forming an assumption about how to handle some aspect of your product—as long as you test it.”
There’s nothing wrong with forming an assumption or gut instinct about how to handle some aspect of your product—as long as you test it.
You’ve tested it—and it works exactly as you’d envisioned. You and your cross-functional teams have reviewed your plans for marketing, sales, customer service, and manufacturing—and they’re all bulletproof. You’ve even talked up the product’s release date with prospects—and they’re eager for it. Yep, the product is ready.
A little voice in your head tells you to wait. Maybe it’s asking for one more survey. Maybe it wants another focus-group session where you sit with users and watch them interact with the product. Or maybe it’s whispering for you to review your existing customer data one more time, just to make sure you haven’t missed something. As your release date nears, that voice inside you gets louder and louder, eventually screaming at you: Please! Don’t hit that “go-live” button yet!
What’s happening here? Are you just so data-driven that you’re always looking to compile and analyze more of it to make sure your product is as good as it can be? Or is something else going on?
Staying in Customer Feedback Mode Can be a Form of Hiding
One irony of our big-data era is that, thanks to the unprecedented sophistication of the analytical tools you have access to today, your task as a product manager is more difficult than ever.
Yes, with systems like machine learning and predictive analytics you can glean more useful information about your customers’ needs and wants than any product professionals who’ve ever come before you. But even after you’ve crunched all of that data, even after you’ve turned all of your customer feedback into actionable insights, your product still might fail.
And if your product fails in our modern era, when there’s so much data out there that we all assume product managers have all the answers, then the fault must rest entirely with you.
Which is why it’s possible that it’s not your little data muse in your head asking for more evidence as you near your release date. It’s fear.
In fact, there are many reasons that sometimes drawing a line in the sand and making a decision—even though it might terrify you—should win out over your temptation to wait and seek more feedback. Here are a handful of those reasons.
5 Reasons to Stop Gathering Data and Just Make a Decision
1. You’re a product manager, not a data collector (or an order taker).
The most obvious reason to make a product decision rather than wait for more data is that your role as a product manager calls for both your market knowledge and your intuition.
“You’re a product manager, not a data collector (or an order taker).”
Yes, you need data. Yes, customer feedback is valuable. But in the end, it’s your responsibility as your product’s champion to feed all of that information into a larger decision-making process that also features your gut instinct.
After all, that gut instinct of yours isn’t just an uneducated guess. It will represent the totality of the knowledge you’ve gleaned in your role as PM, and your unique perspective about your market and user personas. Don’t be afraid to tap into it.
2. Your customers don’t always know (or tell you) what they really want.
There’s a funny story that circulates in the aviation industry, where every few years the airlines survey passengers about the types of in-flight snacks they’d prefer—a piece of cake, for example, or a plate of fruit. In survey after survey, the passengers overwhelmingly say they’d rather have the fruit. But when flight attendants roll a real cart down a real aisle on a real flight, an overwhelming majority of passengers ask for the cake.
Talking to your customers isn’t always the most direct path to the truth. Sometimes they won’t tell you what they’d really want, because they’re in denial about it themselves. Other times they simply don’t know what they want because they haven’t encountered it yet—and it’ll be your job to present it to them.
Music buyers told product managers they wanted CDs that didn’t skip—not an mp3 player (whatever the heck that was).
Remember, as a product manager your job is to lead your customers—not to follow them.
3. The data (or your interpretation of it) could be wrong anyway… so why not innovate?
A corollary to the idea above, that your customers can’t always articulate what they want, is that no matter how much data you compile and crunch, you might still come to an incorrect conclusion.
People are fickle. Tastes change. Priorities change. A competitive product that hits your market out of nowhere might change everything.
So don’t simply gather up a list of requests and demands from your customers and turn that list into a product. It might feel like the safe route, because you’re getting your list of priorities straight from your customers. But a product built strictly on orders from users and prospective users could for a number of reasons still turn out to be a dud.
So innovate. Show your customers and your market something new, something they weren’t expecting and might not have even realized they needed or wanted. That’s how you make a product worth owning and raving about!
4. Failure leads to learning. Hiding leads to… nothing.
Comedian Jay Leno once explained in an interview the reason so many comedians won’t stop talking even for a split-second after delivering a punchline is that they’re terrified of the silence that could follow.
So comics just keep rambling right after the punchline, adding filler statements like, “It’s ridiculous!” or “Know what I mean? Crazy, right?”
Such useless phrases can actually lead to negative consequences for the comic’s act. First, they clutter the punchline. An audience set to laugh at a joke might hold some of that laughter in if they think the comic isn’t finished. Second, they don’t allow the comedian to do the risky and scary work of delivering his line and then waiting, in silence, to learn if it worked.
And that second threat relates directly to you as a PM when you stay in customer-feedback mode, continually seeking, compiling and analyzing more data—rather than making a decision about it with the information (and intuition) you already have.
“Failure leads to learning. Hiding leads to… nothing.”
Products will fail. But the sooner you can get yours out there, and learn where and why it failed, the sooner you’ll be in a position to improve it.
And if it makes that voice in your head feel a little more relaxed, you can tell it that actually shipping your product is probably the best way to get more of the customer feedback it so desperately wants.
Which brings us to our final point….
The agile method of product development favors shorter development cycles so product teams can push their wares out into the market sooner and more often, giving customers a chance to experience the products firsthand and give their feedback.
In other words, agile should help you quiet that little voice in your head that’s afraid to make a decision, afraid to ship—and instead seeks the comfort of just one more survey or customer conversation.
If you adopt the agile method at your company, you’ll have more chances than ever to talk to your customers and gather feedback. And if you find your customers aren’t as happy with your current product as you had hoped, the agile method means you’ll be able to quickly punch up the product based (partly) on that feedback—and push it right back out to the market quickly.
And that little voice in your head that’s afraid to ship will go back to a deep, peaceful sleep.
Caution: Satirical post. Reduce seriousness ahead.
There is one recorded instance in world history of a PowerPoint presentation bringing an audience to wild applause, whistling and cheering. One.
It happened in Geneva on July 4, 2012, during a lecture at the European Organization for Nuclear Research (CERN). A team of physicists was there to announce they had found evidence of the Higgs boson.
The what? Don’t worry about it. It’s really important physics stuff, but not relevant here. (tl;dr: Higgs boson.)
And I know: It’s difficult to process “PowerPoint,” “audience,” and “cheering” in the same sentence. You might be wondering, is he making this up? Nope. You can watch a video of the CERN Higgs lecture here. Listen to the crowd go nuts, for example, at the 34:45 mark. (And what you won’t be able to see in the video, which shows only the PPT slides, is that many of the people in the audience were actually leaping to their feet.)
Now, you might be thinking: You shouldn’t be able to give PowerPoint the credit for all of that crazy cheering. Everyone knows physicists are always wild and rowdy.
Fair point. But still: Getting any group of people stirred up in a lecture based on a PowerPoint slideshow is an accomplishment—even if your presentation hilariously uses the Comic Sans font, as the CERN physicists did for some bizarre reason. (They did? They did.)
As you can imagine, though, there is no record of any such spontaneous cheering and hollering—anywhere in the world, ever—during a lecture built around an Excel spreadsheet.
So, if you’re still using Excel to maintain and present your product roadmaps, I have a few suggestions for you.
Why on earth would you want to use a spreadsheet that’s all row, column, row, row, column, column to present something as strategically important—and, ideally, exciting—as your product’s roadmap? Wouldn’t you want to use a more dynamic, visually compelling way to review your roadmap in those all-important meetings with your cross-functional teams and executive stakeholders?
Still here? Then I have to assume that for some reason—maybe your company insists on it—you’re stuck using Excel for your roadmaps. Ugh.
But okay. Here are some suggestions for livening up those Excel-based roadmap meetings (if you must).
1. Serve sugar-rich snacks
After about 10 minutes of aiming your laser pointer at the spreadsheet on the overhead projector and saying things to your attendees like, “If you’ll look at the first few rows in the second column…” even your most enthusiastic colleagues are going to have trouble staying alert.
So bring treats to your Excel roadmap meetings that’ll give your attendees a jolt. Cookies, juices, even Monster Energy Drinks will work.
The beauty of this strategy is that your attendees will be grateful for the treats. They’ll have no idea you’ve strategically placed them in the room to keep everyone from dozing off.
Caveat: Speaking of dozing off, it’s important to time these meetings just right, so you can wrap things up before your attendees hit the inevitable sugar crash.
2. Give your attendees rubber bands
I know, I know: Rubber bands? Huh?
This is a trick inspired by truckers—who work on a schedule that, like staring at your boring roadmap spreadsheet, can lead people to start nodding off.
So here’s a brilliant, elegant solution: Hand out rubber bands to all attendees as you begin your meeting, and tell them to place the bands around their wrists. If they feel themselves starting to lose focus or getting sleepy, all they have to do is snap the rubber band against their wrist and—“Youch! That stings!”—they’re wide awake again.
3. Bring an air horn
Let’s say tip two doesn’t work so well.
Maybe your attendees drift into unconsciousness too quickly as they stare up your Excel roadmap—and they forget they’re even wearing the rubber bands. Or maybe your colleagues just don’t like the idea of hurting themselves repeatedly to stay awake, so they refuse to comply with your suggestion.
That’s when you stop letting your attendees decide to keep themselves awake—and start deciding for them. An air horn works really well here, because we’ve evolved for two million years not to be able to snooze through a loud, sharp noise.
“Advice for livening up your Excel-based roadmap meeting: Bring an air horn!”
It works every time. And why wouldn’t it? No matter how boring your spreadsheet is, do you think anyone will be able to sleep through this?
4. This one might be controversial but… bring thumbtacks
How and even if you choose to try this suggestion will depend on your company culture.
For example, if your organization views itself as a cohesive team of professionals who care about each other, you might not want to ask people to poke themselves with a thumbtack to stay alert during your meetings. That might come across as cruel.
So you might have to sneak those pokes yourself.
Maybe you can walk around the room during your meeting and, as you get behind an attendee who’s nodding off, you can gently—gently!—jab him with a tack on the back of his shoulder.
Caveat: The success of this strategy depends entirely on the execution. If you poke your dozing attendees too hard, or if an attendee catches you stabbing people with a thumbtack, the whole plan could completely backfire. So use good judgment here.
5. Play triumphant movie scores
Finally, it’s worth remembering that a roadmap presentation is, after all, a presentation. That means you can spruce up even a boring roadmap meeting—and they don’t get much more boring than making your attendees stare at an Excel spreadsheet—with interesting elements to support it.
Music can work well here. My advice: Find a great movie score—Gladiator or Star Wars, for example—that creates a dramatic, triumphant feeling, and have that music ready to play in your Excel roadmap meeting.
Then, as you’re instructing the room to look at row 37, column C… hit play on your movie score. As your attendees look at the field on the screen, they’ll do so to the sounds of: “Duuh Duuh da da da Duuh Duuh, da da da Duuh Duuh, dun-dun-dun-duuuuh!”
Google “psychological safety” and you’ll see a ton of results. But, for such an important and widely discussed concept, it’s not always easy to actually do psychological safety in practice. It really takes an active leader to build that kind of culture and safety net for team members. Product managers, as strategic leaders in the organization used to building consensus and enthusiasm around a product, are uniquely qualified to promote this kind of culture. Here are a handful of ways product managers can foster a sense of psychological safety for their team members and members of other teams.
1. Practice Giving Feedback
Psychological safety is the antidote to fear and what communication scholars call the “spiral of silence” in which dissenting opinions are basically silenced in a group setting. As a product manager, you want individual opinions from team members. You want to hear feedback from team mates and other collaborators like UX designers, engineers, and sales and marketing folks. In practice though, team members often have some very concrete and understandable fears. Team members can be scared to speak up because they’re worried they might be ignored, laughed at, or even fired.
One way to combat this fear is to practice giving feedback, ensuring that when others are vulnerable and present a differing or minority opinion, you’re able to hear them out and provide some feedback in a respectful and encouraging way.
“Psychological safety is the antidote to what communication scholars call the ‘spiral of silence’ in which dissenting opinions are silenced in a group setting.”
As a product manager, you’re already used to soliciting feedback from your customers. Also, we’re pretty sure that most (successful) product managers respectfully accept that feedback without silencing or embarrassing their customer for sharing an opinion. Product managers often receive feature requests that aren’t on track with their product strategy, or might even be totally out there and potentially absurd. But, again, most successful product managers are experts at graciously receiving customer feedback and providing some kind of respectful response in the moment even if they know for sure they’re not going to enact a given suggestion. There’s no reason you can’t treat team members with the same kind of open attitude and respect, even if the idea might be totally off-base.
Practice giving feedback on a regular basis to ensure you never leave anyone feeling like they put their job or reputation on the line for no reason. It’s great to practice this on an individual basis with team members and in a group setting during brainstorms, prioritization exercises, and more. All ideas are welcome!
2. Get To Know Everyone
These days, pretty much every company out there talks about culture, team building activities, etc., but this point really cannot be overemphasized. Knowing someone well, understanding how they think, how they feel about different topics, and how they engage with the world, are the building blocks of trust. Trust is the basis of psychological safety. This one is probably the most important point on the list, but also potentially the one that’s the most fun. Get to know the people you work with. Have fun! Go out to lunch together. Go play trivia. Go to happy hour. Go square dancing! Whatever you and your team is into as a group and as individuals, it’s important to spend some time together outside the regular professional context.
The more you get to know each other personally, the more trust you’ll have in one another, and the less people will feel like they have to hold back their valuable thoughts and opinions because they’re too shy or scared to speak up. Maybe someone just spoke to a customer the other day and has a great new idea of how to solve an old problem. If they know they can share this novel approach without fear or reprisal or potential embarrassment, they’re much more likely to share it, and you as a product manager are much more likely to solve it and avoid hitting it from the same old angles. Get to know (and trust) your teammates and you’ll get to know the practice of psychological safety.
3. Collaborate and Share Ownership
This is another point that sounds obvious but is often ignored in product development. Despite the universal belief that collaboration is the key to success (you can literally see it on every job ad ever), in practice it’s often a little less straightforward. Teams can be possessive, silos can form, and instead of a beautiful, synergistic dynamic in which work is constantly brainstormed, planned, developed, and continually improved, things are frequently planned and built in isolation with lots of shoveling things over the fence, pointing fingers, and avoiding responsibility. Break the cycle! Several product managers we’ve spoken with over the years have told us that being more proactive with engineers and designers has been one way they’ve built trust and psychological safety at different companies over the years.
For example, say you frequently have issues with your UI after the functionality part of development is done. You drew up the requirement, even wireframed it out, and passed the specs to your development team. They did a great job on the technical part of the build, everything works the way it should, and it technically meets requirements and solves a real user issue. But. Things just don’t look or feel right. You’re frustrated that your dev team couldn’t read your mind to know exactly how the UI should look. Dev is frustrated they have to go back and do more work on something that objectively met your requirements. The customer is frustrated because they’re WAITING.
One way to fix this is to actually collaborate with development on design and UI components before handing off requirements. As a product manager, sit down with your dev team before you spec out the requirements and talk through the UI. Or, you could proactively let dev know that they can jump on building the functional components but shouldn’t devote a ton of time to the visuals and UI assets because they’ll likely change or evolve in the next sprint. As long as everyone is on the same page, there’s likely going to be a lot less rework and tension and a lot more trust. Yay!
4. Deal With Things When They Come Up
Just like when we talked about technical debt, it’s often the case that putting things off can have negative consequences. This is also true when you’re trying to build a culture of psychological safety.
Imagine a developer points out an issue with some underlying aspect of your application, highlighting the importance of upgrading or building out a certain part of its infrastructure before you push ahead with some new features. Then a couple more sprints go by and they point it out again. The last couple features that went out worked fine, so you continue with business as usual. They point it out again. More features, and so on. Until something breaks and your customers are upset and that developer is now up in the middle of the night working on a fix for something that should have been fixed months ago.
This dynamic is not promoting psychological safety. It’s promoting frustration and resentment and a general sense that the opinions of certain team members are less valuable than yours. If you operate from the perspective that other team members might have domain expertise that you lack, it’s easier to trust them and put their ideas into practice. Had the above fix been implemented earlier on, a lot of headaches could have been avoided, and that developer would probably feel more inspired to point out potential pitfalls going forward. The last thing you want is for team members to identify a critical issue and then say “what’s the point in bringing it up?”
5. Ask People How They’re Doing, and Mean It
This final point is another one that seems obvious but isn’t as commonly practiced as it should be. Product development moves fast, especially in software. People are ambitious. People get burnt out and overwhelmed and without psychological safety, you often don’t find out until it’s too late and someone leaves your team, project, or company. Make a psychological safety test a part of every standup meeting. Take your team’s mental temperature on an ongoing basis and make sure people know it’s ok to provide real estimates and let you know when something is going to take a lot longer than you thought it would.
“Promote a culture where honesty, accuracy, and mental health are prioritized over story points.”
Product managers often operate at a high level, crafting the strategy for their organization and then work with developers to break that strategy down so they can execute on it. But, since many of them aren’t developers themselves, they have to trust their dev team to provide estimates on how long things will take. We’ve spoken to a lot of developers over the years that have described the phenomenon of over-promising and accepting sprint plans that leave them overworked and exhausted or unable to complete the promised work. Instead, promote a culture where honesty, accuracy, and mental health are prioritized over story points.
Have more tips on how product managers can build a culture of psychological safety? Share them in the comments below!
So, you’ve had it with trying to get stakeholder buy-in on your product strategy using a lifeless spreadsheet to present your roadmap. Or maybe you’ve had it with the slow and tedious process of updating a slide deck every time your roadmap needs a change or addition.
The point is, you’re tired of wasting time building and maintaining your roadmaps using the wrong application—and missing out on what should be great opportunities to present your strategy to various audiences because the tool you used to develop the roadmap just doesn’t allow you to present it in a compelling way.
“Don’t waste your time and energy building and maintaining your roadmaps using the wrong application—and missing out on what should be great opportunities to present your strategy.”
And that means you’re ready to migrate to a purpose-built roadmap tool. We feel your pain. Heck, it’s why we come to work every day.
But before you sign up for the first roadmap application you find on the Internet, you’ll want to do some investigating to make sure the tool will be able to give you everything you need and want from a roadmap software. Here’s a quick checklist of things to expect from a purpose-built roadmap tool.
9 Things to Demand From Any Roadmap Software (and the Company Behind It)
1. It’s designed specifically for roadmaps.
Sounds obvious, sure. But there are plenty of “roadmap tools” out there that also purport to do project management and offer other functionality well outside what’s involved in building, sharing, and updating a roadmap.
That strategy might be useful for the company selling the software, allowing them to broaden their market and sell to a larger number of user personas. But when it comes to something as specific as roadmap software, what you’ll want, perhaps above all else, is a focused solution—a tool designed with the unique objectives of roadmapping in mind.
That means, to use just one of many examples, the roadmap tool should be designed to let you easily create swim lanes, themes, and epics, and to group items logically into containers. Moreover, the tool should be designed such that you can get a roadmap up and running in minutes.
2. It’s built for the cloud.
There are many benefits to a cloud-based roadmap tool, so we’ll list just a couple here.
Managing your roadmap in the cloud means you can host your roadmap with a single URL and assign access to the right users across your organization as needed. This means everyone will always be viewing the version of the roadmap you want them to see, and you’ll prevent the unavoidable version-control nightmare that occurs when everyone is passing around files called “ABC-Roadmap-v3-July8-SharonEdits.ppt.”
A cloud-based roadmap tool is also useful because it will allow you to easily assign various levels of user access—allowing members of your product team to edit the roadmap, for example, while providing development or sales view-only access.
3. It allows for the creation and quick copying of roadmap templates to make creating new roadmaps fast and easy.
Another feature to demand from your roadmap solution, particularly if your company offers more than one product or multiple versions of the same product, is the ability to leverage an existing template to create a new roadmap without having to rebuild the basic formatting from scratch.
You might already build a roadmap, for example, with a legend for a specific set of strategic goals and maybe even a color-coding scheme for your priorities. If you want to leverage that work for a new roadmap—or if another product manager at your company wants to use it for her product—the right roadmap tool will let you do this in a click or two.
This lets your team save valuable time by not having to rebuild roadmaps. It also lets you create a consistent system across your organization—such as strategic-goal verbiage, for example, or a color-coded hierarchy of priority that is understood company-wide.
4. It offers a portfolio view for multiple products or initiatives.
There will almost certainly be instances when you need to view or present multiple roadmaps—for example, when trying to determine where your company’s development resources are being deployed not on a single product but across all of your open development tasks.
“Make sure your roadmap tool offers a portfolio view for multiple products or initiatives.”
Trying to gain a comprehensive, at-a-glance understanding by viewing multiple Excel spreadsheets simultaneously will be difficult.
You want to be able to quickly and easily overlay the details of several of your roadmaps so you can see the overall picture. That’s why you want to make sure the roadmap software you opt for allows a seamless “master” view—where you can create a single, aerial view that includes multiple roadmaps.
5. It integrates seamlessly with your project management software.
The first item on this list requires that your roadmap software actually be a purpose-built roadmap tool, and not some other application that offers partial roadmapping capabilities.
With that said, though, it can be enormously valuable if your roadmap software can easily and seamlessly integrate with related tools—such as your project management software. This will allow you to get all of the benefits of dedicated roadmap software, but then easily tie your roadmap’s strategic content right into a project management tool that lets you create and track all of the task-level details associated with items on your roadmap.
With a specialized roadmap application, as depicted in the screenshot here from ProductPlan, you can set up lanes, themes, containers, and other elements in the time it takes you to drag a new bar onto the screen and type in your descriptor.
This means you can create a new roadmap—and update it anywhere, anytime—in minutes, all without manually reformatting anything.
6. It offers robust versioning capability—so you can always stay uncluttered and current but still keep historical data.
The right roadmap tool will also make it easy for you to archive all past versions of your roadmap, so you can keep your current roadmap clean and up-to-date while maintaining copies of previous versions.
7. It helps you score and prioritize the items competing for resources on your roadmap.
You should also demand from your roadmap tool the ability to plan and prioritize your initiatives based on a cost-benefit scoring model—to give you a more strategic understanding of where to place them on the roadmap.
Ideally, you’ll want some sort of planning functionality that lets you assign weights and scores to various initiatives competing for resources on your roadmap, based on criteria you select.
For the benefits of an initiative, for example, you might weigh its projected revenue or customer delight. For the costs, then, you might score those same initiatives according to how much development effort they will require, or what it will cost to train the sales team.
Your roadmap tool should be able to output an overall score for every initiative—taking into account costs and benefits—from which you’ll have a better idea of how to prioritize the roadmap.
What should you expect from the company behind a roadmap tool?
8. They have a track record—and a list of delighted customers—they’re willing to share with you.
Because the barriers to entry for creating web-based software are lower today than they’ve ever been, it’s important that you investigate any would-be software vendor beyond browsing their website.
One of the best ways to find the right roadmap tool for your company is to find out if the software creator has a list of satisfied customers they’re willing to share with you—ideally customers whose names and brands you know and trust..
9. They’ll let you try the full-featured roadmap tool for free.
Finally, to really get a sense of whether a given roadmap application is right for you and your company, you’ll want the chance to play around with it—to build a real roadmap using the tool, to present that roadmap to colleagues, and to experiment with the cloud-based sharing functionality to determine how easy or difficult it will be to collaborate on your roadmap with people across your company.
So here you’ll want to look for a roadmap software company that gives you unfettered, no-strings trial access to the tool for free.