Now that it’s been around for a number of years and many businesses have been able to use it to great effect, agile product management must seem like an absolute no-brainer to many product professionals.

It’s a brilliant strategy. Build something. Not the whole thing, not every feature or every bell or every whistle. Just something. Then get it out into the world as quickly as you can, and let people use it. Learn from those people what works, what doesn’t, and what you might have missed. Then pour that knowledge into your next iteration, send that out into the world, and repeat as many times as necessary.

In our hyper-competitive era, with low barriers to entry in most industries, and affordable tools available to build, test, and promote products, why on earth would a business not want to work this way? Why would they insist on the old-school, all-or-nothing gamble of deciding and documenting everything they’re going to build at the outset, and then releasing this fully-formed product to their market without getting any feedback from the market along the way?

Often, the answer is simple inertia. Many organizations continue with a waterfall approach because that’s how their staff and executives have always done it. And change is difficult.

So here’s the question: If you’re a believer in the agile product management approach, and you find yourself responsible for a product in an organization still dominated by a waterfall mindset, what can you do?

Can you make the agile product management methodology work—all by yourself—in a non-agile environment?

Read How Agile Product Managers can Build Better Products ➜

First the bad news, then the good news.

Agile Product Management is a Team-Oriented Methodology

I’m going to rip the bandage off in one quick motion here: No, you really can’t make agile product management work if you’re the only person in your company who will be using it.

That’s because, fundamentally, agile is a team-based approach. If you want to apply the agile methodology to any undertaking in your organization—agile development, agile roadmapping, even agile project management—that effort is going to require the participation of a cross-functional team operating under a unified philosophy.

If your development team insists on a waterfall approach, they’re going to demand detailed documentation for everything you want for your product before they start work. Not much you can do about that.

If your executive stakeholders have the waterfall mindset, then before they give you the green light and development resources you need, they’re going to want to know exactly what you have in mind for the finished product—not the minimum viable product you’d like to release so you can gauge what resonates with early adopters. Not much you can do about that, either.

So the bad news is, if you’re an agile-minded product manager, and you can’t get any of the key players in your company to adopt that philosophy, you almost certainly won’t get very far implementing your agile approach to product development.

But wait: You’re a product manager, right? That means, almost by definition, that you’re an expert at leadership, persuasion, and strategically moving a cross-functional team toward a shared goal.

So, the good news is you don’t need to make agile product management work alone. You already have the skills required to encourage the broader adoption of agile throughout your organization.

Here are some suggestions for doing that.

3 Ideas for Moving Your Organization Toward Agile Product Management

First, some more good news: If you’re worried that your organization is going to be stuck in the waterfall muck forever, you’ll be happy to know that the statistics paint a very different picture.

When ProductPlan completed our 2017 Product Planning Report (based on surveys of product managers and roadmap owners around the world), we found that the trend is continuing and even increasing toward a shift from waterfall to agile.

One way to spot a waterfall-based organization is that the company updates its roadmap only about once a year. With an agile team, this isn’t possible. User feedback, new market data, and the iterations this information leads to will demand far more frequent changes to the roadmap. Our Product Planning Report survey found the number of companies updating their roadmaps once a year dropped sharply from 2016—by almost half, in fact.
update roadmapsSo the trend is in your favor: Statistically speaking, eventually your company will likely make the shift to agile.

But, assuming you’re not willing to wait for eventually, and you’d like to drive that organizational shift to agile product management now, let’s review some ideas.

1. Be Sneaky: Don’t Call it Agile

Asking your entire organization to make a wholesale change to the way they approach product development would be a tall order. You’d be proposing not only that your cross-functional team make sweeping changes to how they operate, but also that they adjust their entire approach to designing and building products.

So don’t call it agile. You can talk up specific benefits of the agile methodology and gradually introduce agile product management principles to your organization without ever referring to them as agile. No need to alert everyone that you have a larger agenda to bring them around to an agile philosophy.

2. Be Tactical: Switch to the Right Roadmap Tool

Remember, a key difference in how waterfall and agile organizations operate is in how they use their product roadmaps. A waterfall-oriented team develops its roadmap as a long-term, detailed, set-in-stone plan—and then follows that plan linearly, no matter what.

An agile roadmap, by contrast, reflects the agile company’s understanding that strategies will change, priorities will change, and real-world user feedback can and should affect how a product is built.

Tweet This:
“An agile roadmap reflects the agile company’s understanding that priorities will change.”

This is one reason waterfall product teams can get away with using static tools to build their roadmaps. These applications (presentation software, spreadsheets) aren’t ideal for roadmaps in any environment. The need for manual updates, the difficulty involved in sharing documents, and the version-control issues that inevitably arise, all make them suboptimal choices for housing your roadmap. But for a waterfall team that doesn’t plan to revisit its roadmap more than once a year, they can provide a workable solution.

For an agile team, on the other hand, having the right roadmap tool—ideally a web-based, easy-to-build and easy-to-share application designed specifically for roadmaps—is essential. Building your product roadmap with the right, purpose-built application will also make it much easier to subtly bring your team around to the agile mindset.

When you hold product meetings, with your web-based roadmap projected on the wall (or shared via your screen with your video-conference attendees), you can make updates to the roadmap in real-time. Just showing your colleagues how easy it is to make little adjustments to the product’s strategic plan will have the subtle effect of convincing them that they don’t need to rigidly adhere to a plan written down eight months ago.

When everyone can easily view your product roadmap online, and see when and how small tweaks have been made to the strategy, that will also have the positive psychological effect of making the original, documented plan feel less like it has to remain set in stone.

So if you want to persuade your organization to transition to an agile company, choose your product roadmap software wisely.

3. Be Strategic: Start Small

Finally, remember that agile is all about chunking down, not up. So why not apply this approach to your plan to introduce your organization to agile product management?

Start with small adjustments. Shift from documenting product features to describing user stories. Make yourself more available to your development team. Share user feedback and other relevant data with your executive stakeholders more frequently.

These are all agile principles, of course—but you’re not likely to receive much pushback on any of them. In fact, your teams are likely to embrace them all. And before you know it, you’ll be an agile shop!

In other words, you can use the agile approach itself to create an agile mindset across your company. Cool, right?

Do you have any suggestions for a PM who wants to move her company to agile? Please share them in the comments field.