In my first VP Product role, my company had a charismatic founder with a strong vision of where he wanted the organization to go. But the vision was high level and long term, like the top of a pyramid. At the bottom of the pyramid were the stakeholders' actions and tactics, a list of dozens of requests.

When planning your product strategy, getting opinions from your stakeholders is key. However, those opinions should not be the final arbiter. You should make the final decisions.

When planning your product strategy, naturally you have to get input from your stakeholders. Do not do this in one big group. A meeting of everyone on the executive team will be full of jockeying and politics. Have your stakeholder meetings one-on-one for honesty.

A new release is a golden opportunity to learn. Sometimes called a discovery period, it's when you get new data showing success or failure for customers and for the organization. Has the new capability changed customer behavior measurably? Are they more engaged? More likely to buy, upgrade, or renew?

In the old way of running companies, goals were set by management over long periods of time. In contrast for the knowledge economy, Objectives and Key Results (OKRs) are set by teams and looked at frequently... some weekly.

OKRs are meant to create alignment on goals. The best approach is to create one set of shared OKRs for an entire team. Shared OKRs promote collaboration, problem-solving, and focus. This may mean that individuals have no OKRs of their own — and that’s ok! The team rises or falls together.

When creating Objectives and Key Results, consider two types:
Committed are OKRs that you must meet. These are things like contractual obligations or new SLAs you need to improve to hit.
Aspirational are more like a stretch goal, something where you want to reach as far as you can and 70% of that number is still good. They may be recalibrated along the way.

A few weeks ago, I ran a contest on Product Vision MadLibs. The idea was to create your vision statement using this MadLibs template:

We help [type of customer] [achieve a benefit] by [what we do best].

The winner (drum roll, please)…

A fun way to develop your product vision is to hold a MadLibs game. Stakeholders individually fill in the following sentence:

We help [type of customer] [achieve a benefit] by [what we do best]

How far out should your roadmap go? Generally, the pace of change and development is directly related to your product’s stage of life and the maturity of its market.

As the product person, you are ultimately responsible for the success of your product. This usually means you inform, direct, and coordinate among functions as diverse as engineering, sales, and even finance. Sometimes, you may have to get into the weeds, even doing some of the work yourself. (I once spent 2 years doing partnerships because my product needed it.)

Recency Bias: You get off the phone with a customer, and you believe their problems are the most pressing, even if earlier customer calls were the real mess. How to prevent this?

Tesla, Netflix, Dollar Shave Club — these organizations don't just succeed. Each has redefined the rules of their industry and achieved results once considered impossible. But they didn't succeed, really, on technical innovation. The key ingredient was (and remains) culture.

I've seen more General Manager positions at product-led companies recently. A GM is like a meta-Product person, and has the responsibility of a product leader, plus more… Do you have them in your organization? Does it make sense?

I’m often asked how best to manage dependencies between teams. My answer is… don’t!
The best way to reduce the drag introduced by dependencies among teams is to eliminate the dependencies. This requires making the teams able to operate independently, to be autonomous.

Many companies are turning to feedback tools like UserVoice to get a sense of customer needs. Anyone can propose and vote for a feature or other change for your roadmap. These tools work best when you follow up to understand the needs behind the feature requests.

Where is your product in its lifecycle? Is it in early startup mode? Rapid growth? Cash cow? Most big companies get big by having a portfolio of products to “stack" lifecycles on top of each other. Sometimes you have to produce a roadmap of several products at the same time, a “portfolio roadmap".

The one thing that kills most OKR implementations? Not using them often enough. Unlike old-fashioned approaches to goal setting, progress on OKRs is meant to be measured frequently, maybe even weekly. (Facebook tracks metrics daily.)

We've talked a lot about prioritization for companies and teams. But how do you prioritize yourself? Product people often are pulled in a million directions. Now, with so many of us working at home, that balance is even more strained.