Want to get a shoutout on this newsletter?

I plan to record a Q&A video session in the coming weeks. It'll be only available to subscribers of this newsletter.

If you want to get a shoutout on this recording, reply to this email with a question YOU would like to hear me answer! This could range from all things Product Strategy, Product OKRs, Product Discovery, or my work as a Product Coach in general.

Just hit reply. I love hearing from you!

If the idea of these sessions catches on, I might do one every quarter in the future.

The Product Strategy Stack

Great stacks have clearly defined components which are stacked in order: Company Mission, Company Strategy, Product Strategy, Product Roadmap, and Product Goals. Great stacks help build great companies. Incomplete stacks usually have one or more components missing. Often this component is company or product strategy. Working on incomplete stacks leads to misaligned priorities across teams and shipping product with unclear strategic direction.

Cascading OKRs at scale

When the organization has only one or maybe two levels of hierarchy, a straight cascade might make sense. The executive team sets the company OKRs, then departments (product, marketing, sales) can set theirs. Engineering and Design can skip having OKRs for their departments, because 99% of their work is with the other teams. But when a company grows, it changes. I heard a story about a (real but I won’t name) new CEO who came into a very large company that was on the skids and tried to use OKRs to straighten it out. Sadly, she was a micromanager, and it took a month to get her to approve all the department head okrs.

The Best Product Managers are Truth Seekers

Keep in mind that you'll often be making decisions without the luxury of hard data to defend it. And that's fine. But it's important to remember when you are leveraging gut, or more specifically product instinct, you are in fact leveraging data in the form of patterns you've discovered in the past. And a truth seeker is great at articulating those patterns that are driving their product instinct, enabling them to defend their viewpoints better, educate the team on why they have a specific view, as well as re-calibrate their product instinct as they learn and see cases where it has failed. They also understand that their product instinct was built on the patterns they've had a chance to observe, so they are always seeking new experiences to increase their exposure to more patterns.

Are You Confusing Product Discovery With Research?

We cannot expect interested parties to come check in with us any time they are curious about what’s going on. If they did, it would be exhausting and overwhelming to respond to all the inquiries. Let stakeholders know what you’re up to. In whatever format works best in your organization, have a channel for sharing important updates. Because you have transparency in how decisions were made, questions about “how” or “why” should be minimized. If your updates reveal you have missed a key piece of information that needs to be considered, you can incorporate the new information into your transparent process for all to see.

Why Principles Over Practices Are The Key To Timeless Success

Most teams have a small set of practices to be successful in any situation—a limited set of options to solve problems. Teams who focus on principles pull in whatever practices are best for the problem they’re solving and the circumstances they’re in, and end up being much more innovative as a result.

KPI Trees: How to Bridge the Gap Between Customer Behavior, Product Metrics, and Company Goals

Let’s state the obvious: If you want to build your own KPI tree, you need to start from somewhere. If there is an obvious top-of-the-tree metric, like a North Star metric, start there. However, if you don’t yet have a clear top of the tree, start from what you do have: for example, customer metrics and other business goals. Once you’ve nailed down at least one KPI, you can continue to populate the tree. Keep in mind this will be a messy process and you will almost certainly need to revise and refine your tree over time.

Reducing Product Risk and Removing the MVP Mindset

Earlier in my career, I would have told you everything should be AB tested, and that you should build only as little as you need to validate a hypothesis. Every problem should have user research involved at the beginning, aligned on the problem instead of just validating or invalidating solutions. Every key result should be outcome based. Every engineer, designer and product manager on the team should be involved in defining the problem and the solution. These are all good ideas. However, once you add enough of these “best practices” up, it reads kind of like those articles talking about the morning habits of the most successful people in the world.

Here are a few ways we can work together:

Learn through my free, in-depth Product Strategy, Product OKRs, or Product Discovery content libraries.

​Hire me to work with you or your team(s) 1:1 in workshops or coaching.