Adventures in Product: The First 90 Days

The importance of systems for learning how to learn.

This is part of a series following my journey into product management.

This year is the second time I’ve made a significant role change. The first was moving from an engineer to an engineering manager role, which was fundamentally about switching from writing software to supporting individuals. In many ways that was a bigger change than my current lateral move into product management, but I’ll save that reflection for another post.

The specifics of these two transitions are different, but both have followed the same underlying paradigm to answer the question:

How do you learn something new, broad, and complex?

One-off approaches to learn some new topic X or discipline Y certainly work, but the biggest gains are found in developing a repeatable way to learn. In other words, a learning system.

My learning system

OODA loop diagram

Source: Visual Paradigm

Mental models are simplified representations for how things work and can be useful to help understand complex systems and make decisions in them. The most prominent mental model in my learning system is the OODA loop, a four-stage cycle for information ingestion, processing, and acting originally developed in the U.S. Air Force.

Stage 1: Observe

This stage is all about information gathering and is where I spend the most of my first 30 days. My goal for this stage is to understand what things exist, how things work, and why things are the way they are.

When I moved into new roles as a people manager and a product manager, I had to gather information on two distinct areas: the new systems I’d be operating within, and the role itself. For example: What systems would I be shaping as a product manager? What does effective product leadership involve?

For both information gathering areas, I started by casting a wide net:

  • I talked to as many people as possible who I’d be working with or who had first-hand experience with the role. This included folks outside of my org and the company, too. I followed this approach and set up 30-minute 1:1s with each person where I asked the same set of questions: What should I know? What challenges do you see? Who else should I talk to?
  • I subscribed to newsletters, joined Slack groups, and created reading lists to get a broad and diverse set of perspectives on the role. You can find the full list of resources I used at the end of this post.

It sure felt like information overload at first, but it was necessary. Without first knowing what’s out there, it’s difficult to define better information filtering. As I learned more about the role and the systems I’d be operating within, I was able to be more selective with what I ingested and more specific with the questions I asked.

Stage 2: Orient

The mountain of observations and information collected in the previous stage needs to be processed into something useful. With the context—and especially biases—of each observation in mind, I started to build my own mental models of each of the systems I needed to understand.

As a new engineering manager, this mental model creation was mostly unconscious. As a new product manager, however, I tried to be more explicit by drawing these mental models as system diagrams or by explaining them in posts like these. It’s the Feynman Learning Technique in action: you don’t truly understand something unless you can explain it to a stranger.

These mental models aren’t static; I continuously refine them based on new information and feedback. Feedback from individuals is a good start, but the best feedback comes from experimenting with and observing changes in the real world. Enter the final stages.

Stage 3 & 4: Decide & Act

The feedback and mental models I’ve developed at this point have given me a holistic understanding of the systems involved. Well, holistic enough for me to start pressure testing it by making changes in the real world.

Some people recommend only starting with small changes. Others make large, sweeping changes early in their role. The former can fail to capitalize on the fresh outside perspective you bring to the role—a perspective that’s lost if you wait too long. A common example of the latter is the new leader who immediately reorganizes the reporting and ownership structure of the team. This can be problematic too if you don’t fully understand the reasons why things are the way they are (aka Chesterton’s Fence).

Either approach applied exclusively will likely be less successful than a blended, highly contextual approach. This is what I follow:

  1. What are the least disruptive improvements I can make that will (a) allow me to safely test my understanding and (b) start to build trust and momentum?
  2. What are the highest-leverage improvements that will have an outsized effect on the people, systems, and organization?

Rinse & repeat

Like the name says, this OODA loop is a repeating cycle. The first iteration can take 30–90 days, but additional cycles are much faster. By the end of the first iteration, I try to have a set of processes established that enable regular information gathering, feedback, synthesis, and action. For example:

  • Weekly 1:1s with individuals I work with to get feedback on what I should do and what I’ve done
  • Regular surveys to everyone I’ve worked with to learn what I’m doing well, what I can improve, and any blind spots
  • A regularly-reviewed decision log that identifies decisions that need to be or have been made, why, the approaches considered, and the outcomes
  • A regular writing habit to clarify my thinking (like this post)
  • A daily reading habit to continually discover new and divergent ideas

Learning resources

Product

Courses:

Newsletters:

Articles:

Books on vision, strategy, and organization:

Books on customer research:

Engineering

Newsletters:

Books:

People leadership

Books:

Blogs:

General problem solving and systems thinking

Courses:

Newsletters:

  • Farnam Street (clearly one of my favorites, if you can’t tell by the number of links in this post)

Books:

Psychology

Design

Other