When a customer or stakeholder asks whether a particular feature or design will be part of the solution, rather than answer the question, experienced product people turn it around and ask “Why?” Why is that feature important? What is it about that date? They are trying to understand what problem that stakeholder is trying to solve.

How do you please different stakeholders with your roadmap deck? Please don't write totally different roadmaps. This defeats your efforts to align the organization around a common cause. Rather, build the specifics each group wants to see on top of the common foundation of your vision, strategy, and themes.

If you make a habit of communicating roadmap updates regularly, you are training your stakeholders to expect adjustments

As a product grows in popularity, it often becomes more complex, with the added features, functionality, and scale demanded by its expanding customer base. These changes may require rewriting or refactoring parts of the code before you can expand further, addressing what is usually called technology debt.

What if you treated the people in your own organization as if they were customers? We often say we need them to “buy” what we’re selling, right? That’s more than a metaphor.

How do you describe risk on your roadmap? Naturally, you have a lot: resources in short supply, unproven technology, untested suppliers, unproven assumptions about the market....

Some companies have interesting product team structures. Rather than organizing by product, they focus on type of users. For years, eBay has had some product people devoted to buyers and others to sellers,

How do you deal with a new technology that you're not sure you will invest in?

Slack publishes its external platform roadmap here. With very few details, its roadmap effectively communicates who they serve, what their priorities are and why, and just enough details about what’s in the hopper to make people confident in their direction.

Well no, the customer isn't always right. But product teams often fail to listen deeply, solve problems and make customers thrive. Marty Cagan has a wise Pledge to Customers to look at…

How long into the future should your roadmap stretch? The answer depends on how fast you are learning. A start-up with new learning every week may have a roadmap of no more than a few months. An established product in a mature market may release features once each year, and will have a longer roadmap.

One of the chief functions of a product roadmap (and one of the key skills of a successful product person) is to get everyone excited about the future. A roadmap will paint a picture of a world where your customers are happy and your company is successful, making everyone in the organization want to be a part of it.

Objectives and Key Results (OKRs) track your organization's progress. They are most effective when you use them only to keep tabs on the most important issues. So where do you track those important but not desperate issues? Things like minimum cash in the bank? Support ticket resolution time? App Store average reviews?

OKRs are clever, but sometimes tricky, ways to track your organization's progress toward what’s most important. For each Objective, there should be 3ish measurable Key Results.

OKRs are a savvy way to track your organization's progress. But they can create problems if they are created by separate departments. OKRs work best for cross-functional teams, where success is success for everyone involved.

Agile was developed as a response to lack of consistent direction from business execs. But there is something missing in agile and lean. If anything, agile teams complain they spend so much time focused on the next few weeks that they lose sight of the reasons they are doing all this work.

Identifying customer needs is the most important aspect of your roadmapping process. Most items on your roadmap will derive from a job the customer needs to accomplish or a problem the customer must solve.

“Many of us use roadmaps as one-way communication to stakeholders, but the real magic happens when you work collaboratively WITH your stakeholders.”

Product people should focus on solving customer problems in ways that meet the needs of your business. How do you find out about customer needs? Get out of the building (on Zoom if you have to) and talk to them.

There are many books on the hard skills of product management, but not much on the soft skill of stakeholder management. In my experience, driving alignment is the most critical tool for the success of your product — and your career.