Focus on “why” in your roadmap instead of “what.” It communicates more clearly where you are headed, and what success looks like. 

User research as it is practiced by user experience professionals is very aligned to what good product people do (or know they should do). Both need to do qualitative research with users and buyers, to watch in person and ask questions, to understand the larger context for the business.

When you are a product person looking to get a roadmap in place, you need alignment and collaboration. You don’t need consensus. Really.

For those of you outside the USA, today is our national holiday. In working with companies around the world, I’ve observed that many of them look up to American product people. They feel we’ve got it all figured out and they are hungry to learn from our success. Sure, product communities in many cities around the world are smaller and younger. But I find that people are just as smart, focused, and hard-working wherever I go.

I’ve seen a lot of roadmaps where the reason for many items was given as “competitive necessity.” In other words, “me too” features.

Don't you hate inane, lengthy Product surveys? They exist because someone hasn't thought enough about when to use qualitative or quantitative methods. Qualitative methods get the why and how answered before you can formulate the right quantitative questions.

When preparing the next version of your roadmap, it's smart to engage in stakeholder shuttle diplomacy. Entice them with a draft of your roadmap and ask for their input. Then sit down with each stakeholder, one-on-one.

I had to let a product manager go once because he just did not have the influencing skills necessary to do his job. He was intelligent, thoughtful, articulate, hard-working and motivated, but he never quite understood that he was supposed to provide direction, rather than receive it.

Objectives and Key Results (OKRs) are a simple system for aligning teams around common objectives. OKRs are hot right now, but there are caveats. They can quickly drive a firm into a narrow fixation on business results, unethical behavior, and short-term outcomes that can eventually undermine the business itself.

Engineers are rightfully afraid of providing estimates for things they don’t know enough about. If they’ve been around the block, they’ve probably been burned by a wild-ass guess that turned into a commitment to a date when someone in management got hold of it.

Is it ever OK to compromise on quality? Surprisingly, yes.

If you know your product will be used by millions with minimal changes and refinements, it makes sense to invest up front. But what if your product is a new and untried idea? What if you might have to iterate several times to arrive at the optimal fit between the product and what the market needs? 

You have a mountain of tasks to get done as a Product person (or in life). Where to begin? Here's my formula:

(Value ÷ Effort) x Confidence = Priority

What is your Kryptonite? In your org, what stands between you and victory? What saps your strength and renders your roadmap impotent? Let us know.

Objectives and Key Results (OKRs) are a worldwide phenomenon, helping to drive the success of organizations like Google, Zynga, Oracle and Twitter. They are particularly suited to driving the alignment for a high-performing cross-functional Product team.

Sometimes stakeholders don't get along. Or their view of the product doesn't match. Or their priorities don't jive. That's where Shuttle Diplomacy goes a long way. I like to meet with stakeholders individually as I'm drafting a new roadmap. Then we meet all together for final buy in.

How can a Product person justify changing a roadmap midstream? Won’t customers, partners, salespeople, the board, etc. expect you to deliver on the roadmap commitments? Actually, no.

“How do product teams really know the right thing to build? Many products aren’t successful because teams haven’t done enough problem discovery and validation with customers. Those processes need to be a part of a product team’s culture.” 

My favorite product tool is Google Docs. I use it for interview notes, meeting agendas, personas, product charters, OKRs, and more. I like it because it makes any document collaborative. People can edit and comment on the same document simultaneously from anywhere in the world.

Outputs are the specific changes your team is making to your product or service to improve things for your customers and your business.

Outcomes are what you are hoping for as a result of those outputs. 

A lot of organizations balk at hiring Agile coaches (aka scrum masters) for every team. They find it hard to justify that many people who aren’t coding, designing, or figuring out what’s next. I agree.