Influence is the superpower of good product people. Few people report to your average PM, but they have outsized impact on their organization. They provide direction on what to build to Engineering; they provide direction on target markets and messaging to Marketing; they recommend alliances and acquisitions to Business Development, etc.

Here are some New Year's Resolutions. Some are eerily similar to a talk I gave on product culture. Others not so much. 

Premise 1: Agile was developed as a response to lack of consistent direction from business execs.

Premise 2: A good roadmap keeps your organization inspired and on course toward its destination. 

That doesn't mean the two are incompatible. Yet many companies I have worked with fear mapping out a course, thinking "it's not allowed in Agile."

Personas deal with softer characteristics. They are often defined as representations of users that embody the qualities, feelings and preferences of groups. They are typically depicted with photos or images surrounded by descriptions and supporting attributes.

This week my friends at ProductBoard published an ebook with wisdom on being a superb Product person. I wrote a chapter on Roadmaps (surprise!), entitled "Focus your Roadmaps on Outcomes, Not Outputs." 

A Dear John letter tells a romantic partner that they are dumped. In my roadmaps workshops we practice writing Dear Roadmap letters. We complain about all the things that are not working in our relationships: "It's time to split. We do the same thing every three months...."

I’m curious: If you had to create the Superhero Product person, what attributes would you demand? Shooting lasers out of their eyes? Possibly. Leadership and communication skills? Definitely. How technical would the dream Product hero be? Able to write a brilliant roadmap in a single bound?

The hardest thing about roadmaps is making it clear to people that they will change -- and that change is not failure but a considered response to evolving conditions.

A roadmap conversation with a customer is an opportunity for a product person to verify their understanding of market needs before actually building the product. If you’ve done a really great job in your customer discovery, then the roadmap is merely "confirming the mutual understanding" of these needs.

I hung out last week with thousands of people, most of whom had never met and will never do so again. And yet there was a clear sense of community among these people, of shared values and ways of thinking, and critically of passion for making great products that make customers happy and businesses successful.

In successful product cultures, objectives change: no longer shipping on time and on budget, but solving customer problems in ways that meet the needs of your business. This change in approach puts a spotlight on the customer. How do you find out about customer needs? Get out of the building and talk to them.

I spent the last 3 weeks in Auckland, Wellington, Queenstown and other locations in New Zealand for business and pleasure. I’m happy to report the product culture there is growing rapidly.

Answering “why” is the job of leadership and, in the world of product, is the essential job of product management. Answering “how” is the job of management and is core to the project management role.

When product people are considering a job at a new company, the thing they most want to know is whether the company has a good culture, including an appreciation of the role of product. And I am witnessing an increasing recognition among CxOs that product management is the sort of leadership role that can pull the right team together and get them moving in the right direction. This is Product Culture.

You have to revisit your roadmap at intervals that match the pace of change in your market. Intel's public roadmap goes out 2 or 3 years. In contrast, many start-ups change directions every few months.

Execs at growing companies see product people as their surrogates, the "adult in the room," as I've heard more than a few say. 

Product teams often use tools to communicate and collaborate as they flesh out their roadmaps. There is roadmapping software out there. Other teams use general products. What are these tools useful for in your organization? How are they not? 

Output vs. Outcome: The roles are complementary. Can you do both? Can you do both without going crazy? Does your organization know the difference?

Roadmap themes represent the underlying problems you really want to solve. It takes a savvy Product person to tease these ideas out of the noise of requests from every quarter. 

"You want to put the customer at the center of everything. This is very unnatural for most product companies, because we're thinking, 'What are we going to do to make more money?'