Product Practice #300: 7 Things I learned from writing a Weekly Product Management Newsletter for 7 Years

Published:

Estimated Reading Time:  Minutes

This week’s issue is a bit different from your typical program. I want to take a moment to celebrate the 300th(!) issue of this newsletter.

Sorry for the non-existent product management tips this week, but humor me as I go down memory lane.

I’ve been writing and sending newsletters in various formats since 2010, but I consider this newsletter shown below from September 2016 to be the first one as far as weekly publishing goes (except for my seasonal writing breaks).

I’ve been (and still am) passionate about turning ideas into tangible writing. So much that I enjoyed(!) writing for around 100 subscribers for two years every week between 2016 and 2018. The topics were always centered around my everyday experience working on products through various lenses, but often very wordy and all over the place. Things started to pick up significantly when I decided what to focus on in 2018 and even more so after going independent in 2019.

Today, I have the privilege of writing to around 10,000 subscribers every week, and I couldn’t be more excited about those hours when I get to sit down and type.

So, here’s the obligatory “7 Things I learned from writing a Weekly Product Management Newsletter for 7 Years” list:

  1. I always thought the quantitative numbers were what would keep me going. But it’s the qualitative feedback from readers.
  2. For the commitment to a weekly format to stick, it had to be a format that comes somewhat easily to me (writing is at the core of how I express myself).
  3. I stopped keeping a long-term content backlog since I learned that my best writing is based on experiences from the practical client work I do every week.
  4. I made the newsletter the red line that nothing professional can cross. No matter what happens, the newsletter happens.
  5. Subscriber Count and Open Rates are vanity metrics that are unreliable predictors of content relevance and usefulness to readers.
  6. Subscribers approaching me at in-person events to say hi gives me goosebumps to this day. Keep it going!
  7. People come through recommendations or specific events but stay for my perspective on topics they care about at a given moment. I don’t have to reinvent the wheel.

With that said, thank you so much for allowing me to serve you, and here’s to the next 300 newsletters. 🥂

Thank you for Practicing Product,

Tim


7 Evergreen Favorites from 7 Years of Curation

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.

Read it here

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.

Read it here

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.

Read it here

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.

Read it here

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.

Read it here

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.

Read it here

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.

Read it here


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
>