In general, the real org chart has nothing to do with the official hierarchy. The real org chart is the people you care about, who can influence your product.

Your mission statement is one of the most important tools to help your team, investors, stakeholders, and customers know who you are and what you’re all about. This one statement serves as an essential way to ensure the customer remains front and center.

At your organization, who is the ultimate owner of a project? It can be a product manager, or someone else. At companies like Apple, that person is called the "directly responsible individual," or DRI (Orwellian?). Every project is assigned to a DRI who’s ultimately held accountable for the success or failure of the project.

My friends, let’s make 2023 the year of impact. We all work hard (often too hard). We all deliver a lot to customers and stakeholders. I know I sometimes forget to step back and examine which things are making an impact, and which things — even if they seemed like good ideas — don’t measure up in terms of ROI.

Many stakeholders are looking to the roadmap to tell them exactly what they can expect and when. However, that type of artifact is not a roadmap — it’s a project or release plan.

In B2B especially, buyers and users are often different people. They have different concerns, motivations, and needs. A product needs to solve for both, as does its marketing. Personas are a team sport. Successful product cultures bring all the functions together to develop a common understanding of buyer and user needs.

In the 5 years since we wrote Product Roadmaps Relaunched, our outcomes approach to roadmaps has become the acknowledged best practice. I’ve distilled everything we’ve learned from teaching thousands of people how to do roadmaps right into an online masterclass. It has updated and expanded content, exercises, templates, and help when you need it.

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?