If you’re subscribed to me here on Medium, please re-subscribe here:

petro.blog/subscribe

I’ll no longer be posting here.

One of my first assignments was to create a generic library for building search facets from a dataset: given a table, determine which columns are usable as discrete filters and what their distinct values are. I used frontier AI models to plan and implement it, but I found that this produced a confusing class structure and functions that were difficult to use. This would have been immediately obvious to any human actually trying to use it. I started noticing this same pattern elsewhere.

AI works better for me as a sounding board than as a primary author for designing systems, control flows, and software interfaces (like class structures and function signatures). A good interface depends on a feedback loop where the pain of a bad design decision makes it back to its designer. A bad interface becomes painfully obvious the moment you use it. AI is immune to this pain, breaking that feedback loop. Better prompting seems to help, but only to a point. Lived pain is the best teacher.

For me, no amount of reviewing code produces the same richness of understanding and joy that coauthoring it does. While it certainly feels productive for AI to generate everything for me to review, it also feels hollow. And it defeats the whole point I moved from management back into hands-on engineering: to create, not only manage. I’ve already started to see experienced engineers I respect move completely away from agentic coding because of this. For me, then, authoring key class structures and function signatures but delegating their internal implementations gives me the best balance of speed, quality, and creativity. This reminds me of README-driven development: define how you want consumers to be able to use your library/class/function, and then design and implement it to achieve that.

The broader lesson I’m seeing is that a human should make the decision when it directly affects another human, or when making the decision is how you get better at making them.

If you work in software, you’ve seen this AI craze firsthand.

You’ve probably heard your leaders hyperventilate about the “transformative nature” of AI. Heard them panic about making sure everyone is “making the most” of AI. Heard them say things like, “engineers who don’t use AI will be replaced by those who do.” And it’s probably exhausting.

Ten years ago, you could have replaced “AI” with “the cloud”. Twenty years ago, it was “mobile”. Thirty years ago, it was “the internet”.

Yes, generative AI promises to be a transformative technology on par with the above. But that doesn’t mean we should lose our heads.

Rushing to use a new tool without carefully considering its tradeoffs and downstream effects is a recipe for building unsustainable things nobody actually needs.

What never changes

What never changes is the need to solve real problems for real people.

Discovering unmet needs. Forming hypotheses for how to address them. Testing those hypotheses with real people. Scaling the hypotheses that worked, killing the ones that didn’t. Repeating.

AI can absolutely make many of these steps easier: identifying patterns in customer feedback, rapid prototyping, and coding the mundane parts of the implementation. But as a partner in decision-making, not as a replacement for human judgment and taste.

Put another way: use AI to move up the abstraction ladder, not replace it.

What AI actually changes

AI doesn’t invalidate many of the best practices we’ve learned the hard way over the years.

You still need to ask the right questions in product discovery. You still need to optimize your delivery lifecycle for learning over shipping. AI makes shipping faster, but shipping was never the point. Meeting customer needs is.

Shipping the wrong thing 10x faster still means you’re shipping the wrong thing.

Used thoughtfully, AI can help you spend more time on higher-leverage work:

• Use AI to synthesize customer feedback so you can spend more time crafting better hypotheses.
• Use AI to build prototypes faster so you can learn what you should build more sustainably.
• Use AI to fill in the more mundane details of a thoughtful architecture so you can focus on higher-leverage design decisions.

Where teams get into trouble

Where teams get into trouble is treating AI as a substitute for judgment instead of a force multiplier for it.

• Don’t use AI to do things non-deterministically when a deterministic interface would be superior. Sometimes a button with a dumb workflow is better than an AI chatbot.
• Don’t use AI to write more code than you would have written by hand. Code is a liability, and every piece of code you don’t read or understand is code that you will have to maintain indefinitely.

Ask yourself: if this AI-generated code was completely wrong, how would I know? What would the blast radius be?

The goal isn’t to maximize AI-generated output.

The goal is to solve meaningful problems sustainably.

Don’t lose the plot

The companies that survive technology shifts aren’t the ones that panic the hardest. They’re the ones that stay focused on fundamentals while everyone else is losing their minds.

So yes: use AI. Learn it. Experiment with it. Find where it genuinely creates leverage. But software history is full of teams that became obsessed with the tool instead of the outcome.

The goal was never to maximize lines of code written, story points shipped, or now, AI-generated output. The goal is still the same as it’s always been: solve meaningful problems for real people.

Just don’t lose sight of that in the process.

You do not need to calm down because AI isn’t important.

You need to calm down because it is.

From a systems thinking perspective, problems become more expensive the later they’re discovered. Effort invested earlier in the process often prevents far more work later.

In practice, this usually breaks down into four stages:

1. Define the problem
2. Design the solution
3. Implement the solution
4. Maintain the solution

1. Define the problem

• What problem are you actually trying to solve?
• Is this a root cause or a symptom?
• What evidence suggests this problem is worth solving now?

2. Design the solution

• What constraints are real, and which assumptions should be questioned?
• What are the tradeoffs between possible approaches?
• Can ideas from multiple approaches be combined?

3. Implement the solution

• What is the minimum change that delivers value?
• How can value be delivered as early as possible?
• How will you evaluate whether the problem was actually solved?

Implementation is also a learning process. Some uncertainty can only be resolved through execution, and some problems only become visible once a solution interacts with the real world.

The goal isn’t to eliminate iteration, but to make it more intentional and less wasteful.

4. Maintain the solution

• What ongoing work is required to sustain it?
• How can this require less ongoing work over time?
• Does the solution continue to deliver value over time?

The hardest part is that defining problems and designing solutions rarely feels productive in the moment. But that’s often where the highest leverage actually exists.

Simply put, it’s the act of transferring full or partial ownership of a task to someone else, ideally to maximize the collective impact and growth opportunities of everyone involved. When done well, this can create space for delegators to focus on their highest-leverage activities and give delegated individuals opportunities to work on things that help them grow. When done poorly, it can create resentment, frustration, and waste for everyone.

Delegation levels

There are many ways to define delegation styles, but I’ve found the levels below to be the most practical.

Common delegation problems

Delegating well is difficult, and most people aren’t amazing at it (myself included). The most common problem I’ve observed is that delegators don’t use the delegation style that’s appropriate for the task and the delegated individual’s skill at that task. This manifests itself in one of two ways:

• Insufficient autonomy: The delegator doesn’t give the delegated individual enough autonomy in completing the task. At one extreme, the delegator doesn’t even delegate the task — they do it themselves. At the other extreme, they micromanage every detail unnecessarily. This can be incredibly frustrating and demotivating for the delegated and a poor use of time by the delegator.
• Too much autonomy: The delegator gives the delegated more responsibility than they can effectively handle, and the delegated struggles to deliver. This typically happens when delegated individuals lack experience with the skill required by the task, and what’s asked of them is too far out of their comfort zone and area of competence.

How to fix a delegation problem

Once you’ve identified that you have delegation problem based on the signals above, follow these steps:

1. Identify which delegation level you’re using for the task.
2. Diagnose which of the two situations you’re in — too little or too much autonomy — and adjust your delegation level up or down accordingly.

Finally, remember that delegation levels are task-dependent: the same person may be operating at one delegation level for a task but at a completely different level for another task.

This may seem counterintuitive, but it’s true. Quality is not something that can be achieved through thought alone; it requires contact with reality to get feedback on what is good and what’s not. And the only way to get feedback is to put it out there — to deliver it in the hands of an end user.

This parable from David Bayles and Ted Orland’s book, Art & Fear, puts it best:

[A] ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work — and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Applied to software product development (the focus of this blog), this takes many forms:

• Share a boxes-and-lines napkin drawing of a proposed architecture for feedback in the next hour instead of spending a week putting together a polished technical design
• Share a draft pull request that only defines class and method signatures for feedback instead of waiting to implement all code changes
• Share a vibe-coded prototype with customers for feedback instead of building out the feature in full

In short:

If the first time someone is asked for feedback is on the finished product, it’s already too late.

Get feedback early — even painfully early. There’s a real truth to the saying that you should release before you feel you’re ready. The risk of waiting is wasted time and effort from going down the wrong path. Feedback is your GPS: check it early and often so you don’t get lost.

1. Leave things better than you found them

In everything you to do, there’s always an opportunity to make an improvement, no matter how tiny. Are you doing the bare minimum to accomplish a task, or are you using the task as an opportunity to improve some part of the process? This can come in many forms:

• Fixing documentation that you just read
• Cleaning up nearby code when implementing a feature
• Teaching a better mental model of approaching a problem while reviewing a pull request
• Help someone that you see struggling

Small improvements accumulate into major impact. The reverse is also true: large impacts can be broken down into many small improvements. For instance, I once did an experiment called “Refactor-a-day” in which I spent 30 minutes every day identifying, implementing, and delivering a single refactor to the codebase. These were tiny edits — a dozen lines at most — that made incremental improvements to the codebase. At the conclusion of this 3–6 month experiment, I had completely rearchitected and improved the web routing layer of the core product, something that never met the threshold as a dedicated project.

2. Do what you say

What is your do-vs-say ratio? Do you do everything you say you’ll do and by when you said you’d do it? If you want others to trust you, having a high do-vs-say ratio is essential. Nothing erodes trust faster than someone who needs constant followups to get something done. Be the person that others go to to get the job done.

This doesn’t mean you need to do a lot. Not at all! Rather, it means you need to be honest — with yourself and others — about what you can do and by when. It’s easier to work with others whose volume and velocity are known and consistent than with those where it’s inconsistent and unreliable. Low volume and velocity is an easier and better problem to solve than unreliability.

Of course, things can happen that affect your ability to deliver what you said you would. When this happens, the key is to communicate early and align on updated expectations. Don’t wait until you’ve broken your commitment before communicating and renegotiating it.

3. Be proactive

Finally, the common thread in all of this is proactivity. Do you wait to be told what to do or for others to start, or are you the one taking initiative and setting the tempo? The most successful individuals are impatient and refuse to wait for others. A good measure of this is if others are asking you to slow down. If no one is telling you to slow down, you’re probably not being as proactive as you could be.

We all make decisions. Constantly. Whether to snooze the alarm, what to have for lunch, or what to watch tonight. Most are inconsequential like these, but others have a larger, unknowable impact on our future. Whether to apply for that job, strike up conversation with that stranger, or book that trip on the Titanic.

Despite its ubiquity, decision-making is a skill. Like many skills, it can benefit from the same principles behind deliberate practice. That’s a technique for taking an activity and breaking it down into parts that can be measured, practiced, and improved in a feedback loop.

So how do you apply this to decision-making?

First, separate the decision from the decision-making process

Don’t judge the quality of your decision-making based on the outcome of an individual decision. Sometimes the worst outcome happens in spite of a good process, and other times you get lucky in spite of a bad one. It’s probabilistic, not deterministic. Good decision-making just increases the probability of success.

Second, realize that success is more often about avoiding mistakes than it is about being gifted

Sports is a great example. At all but the highest levels, winning is mostly about avoiding unforced errors than it is about playing brilliantly. Like sports, most of the improvement in decision-making comes from minimizing the risk of failure and regret.

Third, the goal is to maximize your rate of learning

The most successful individuals and organizations are the ones who learn the fastest about what makes them successful—and what doesn’t. But you can’t learn without trying and failing. A lot.

A decision-making framework

Based on these principles, dedicated training, and years of deliberate practice, I try to follow this structure for all my consequential decisions:

1. Define the problem
2. Identify the reversibility of the decision
3. Select the participants
4. Define the evaluation criteria
5. Ideate and evaluate the options
6. Premortem the best options
7. Make a decision
8. Later, retrospect

1. Define the problem

This is both the most important and most often overlooked step in making a decision:

What problem are you trying to solve?

To paraphrase a passage from Alice in Wonderland: If you don’t know what the problem is, then any solution will do.

Many problems are really just symptoms of a deeper problem. Addressing the symptom instead of an underlying cause will probably not solve the problem in the long-term, if at all. One of the qualities of a good decision is its longevity, i.e. how long it lasts before being revisited.

When defining the problem, resist the urge to accept the stated problem at face value, and confirm for yourself whether it’s (a) actually a problem and (b) the right problem to solve instead of a deeper one.

If you follow this rabbit hole of deeper causes to its logical conclusion, you might discover that the ultimate root cause is change—in the system or its environment. However, most decisions and decision-makers have a limited scope, so it’s up to you to decide how deep you want to go.

Finally, how will you know if you’ve actually solved the problem? What would be true? Can it be measured? An essential part of defining the problem is to describe what the world looks like when the problem no longer exists.

2. Identify the reversibility of the decision

Every decision has an opportunity cost. What are the tradeoffs if you decide one way vs. another vs. not making a decision at all?

One of the biggest opportunity costs is learning. You can’t learn what works and what doesn’t until you try, and you can’t try without first making a decision about what to try.

The speed of your decision-making has a direct impact on how soon you’ll be successful. The slower you are at making decisions, the fewer decisions you’ll make, and the less you’ll learn over time. For many organizations, a slow rate of learning can be fatal. But making a rushed decision can be dangerous too, particularly if the cost of making a wrong decision is high.

For many decisions, the speed-vs-quality tradeoff is obvious, and we choose the appropriate one intuitively. You’d certainly spend more effort deciding on your next home vs. what to have for lunch. But for many decisions—especially those in the workplace—it’s more ambiguous. How do you know when to decide quickly vs. carefully?

One answer is to classify decisions based on their reversibility:

How costly or difficult would it be to change the decision if it ends up being the wrong one?

Mostly reversible decisions: Decide as soon as possible

Mostly reversible decisions are like walking through a door: if you don’t like what you see, you can go back. For example, deciding between different products on Amazon is easily reversible due to flexible return policies and free, fast shipping.

For these decisions, decide as soon as possible since the cost of making the wrong decision is probably lower than the cost of indecision.

Mostly irreversible decisions: Decide as late as possible

Mostly irreversible decisions are expensive or impossible to undo. For example, deciding to move to another city is mostly irreversible due to the high cost of switching homes/schools/jobs and the fact that it may not be possible to return to the same ones if you change your mind. Some decisions are completely irreversible, such as whether to be a parent. These are one-way doors.

For these decisions, decide as late as possible since the cost of making the wrong decision is higher than the cost of indecision. Meanwhile, try to lower the risk of making a wrong decision by collecting more information that will help you make a decision. Keep collecting information until (a) you stop collecting useful information or (b) the cost of indecision becomes greater due to missed opportunities and other risks.

Collecting information is more than just research. One of the best ways to collect information is to run experiments. Is there a lower-risk way to test the different options you’re considering? Large decisions can often be broken down into smaller, more easily tested ones.

3. Select the participants

Who should be involved in the decision? An alphabet soup of popular models exist for identifying participants and their roles: DACI, RACI, DARE, RAPID. These models are largely the same and differ mostly in how they draw the lines between the different areas of decision-making activity.

Regardless of the approach, you’ll need to be able to answer the following questions:

• Who’s making sure a decision gets made?
• Who should be consulted before making a decision? What’s the heuristic for identifying who to include? Primary sources are better than secondary ones.
• Does anyone need to formally approve the decision? If so, they should be consulted early in the process to understand their needs and incentives.
• Who should be informed of the final decision?
• Who will implement or execute the decision?
• Do the selected participants represent a diverse set experiences and perspectives?

The last point is particularly subtle and rarely considered, but it has a large effect on the robustness of the decision. A group of people who think alike are likely to, well, think alike and generate a smaller set of similar ideas. Compare this to a group of people with wildly different ways of thinking who are more likely to generate a broad set of divergent ideas. Like we see in nature, solutions born from diverse pools of possibilities are more resilient than those coming from small puddles of homogeneity.

In short, the creativity and resilience of a solution is strongly affected by the diversity of its inputs.

Finally, on a more administrative note: remember to write things down. Not only should the individuals here be identified, but also documented. If it’s not written down, it’s at risk of being forgotten. Nothing sinks a decision faster than forgetting to include key stakeholders or misremembering what problem you’ve agreed to solve.

4. Define the evaluation criteria

How will the success of the decision be evaluated? Without explicit, measurable criteria, it will be difficult to confidently say whether the decision actually solved the original problem. Confirmation bias and the highest paid person’s opinion often then takes hold in these cases.

In addition, decisions often fail because of unvoiced differences in what each of the participants are optimizing for. How likely are participants to align on a decision if they disagree on what the most important factors are? Making these factors explicit and resolving their differences is a critical step in reaching a decision that everyone can move forward with.

This is why it’s vital that evaluation criteria are defined before making a decision. To help identify criteria, consider the following questions:

• What factors are important in selecting a viable option? Discriminating factors are more useful than ones that all options will satisfy.
• What is the relative importance of these factors? What’s the most important one?
• What constraints exist? eg. Cost cannot exceed $X

For example, say you’re looking for a new home. Your evaluation criteria might be:

1. Distance to work and school: No more than 20 minutes by car
2. Cost: No more than $X/month
3. Size: Minimum 2 bedrooms
4. Amount of light: To what degree does sunlight illuminate the interior?
5. Proximity to a park/green space: Is it in walking distance?
6. Quality of interior: wood vs. tile vs. carpet, quality of appliances and fixtures

Defining these criteria and their relative important up front can help you avoid getting seduced by a home that seems great but ends up not actually being what you want—aka buyer’s remorse.

You might also discover that you and your partner’s lists of criteria are pretty different. I can tell you from personal experience that it’s far easier to discuss and resolve those differences before you commit to a home then after.

5. Ideate and evaluate the options

What are all possible options to solving the problem? Time to brainstorm! The goal here is quantity, not quality, so go wide and include options even if they may not be viable.

Try these strategies to discover additional options you might not have otherwise considered:

• Eliminate options. If one or more of the most promising options weren’t available, what would you do? These constraints can help you think of more creative solutions.
• Combine options. Can parts or the whole of different options be combined in novel ways?
• Look at opportunity costs. By pursuing a particular option, you’re forgoing other opportunities. What are they? What if you pursued those instead?

Once you’ve identified a whole menu of possible options, now it’s time to evaluate each of them according to your evaluation criteria. It should be easy if you’ve defined the criteria as measurable things.

6. Premortem the best options

By now you should have at least one viable option for consideration. Imagine that you selected it, but it failed to solve the original problem. Why? What happened?

If success is indeed mostly about avoiding failure than it is about being brilliant, then:

We can ensure a higher probability of success by identifying and mitigating the ways in which we might fail.

In contrast with a postmortem, which attempts to diagnose the causes of failure after the fact, a premortem is a thought exercise that attempts to identify potential sources of failure before they happen.

To do a premortem, start at the end — you’ve failed — and work backwards. What are the things that failed, and what were the steps that led to them?

Continuing the previous home-hunting example, imagine you selected a particular home to move into and quickly discovered that you hate it. Why? The neighborhood sucks. Nothing is in walking distance, and even if you drive to the nearest cafes, bars, and restaurants, they’re all mediocre.

But don’t stop there. Why didn’t you discover earlier that the neighborhood sucks? Perhaps you didn’t realize the importance of walkability, nor did you realize how disappointing the surrounding establishments are. As you continue asking why and working backwards, you may discover important criteria like these that you hadn’t considered.

Mitigations to these sources of failures will become clearer as you work backwards. For instance, perhaps you can spend a few days actually living in the prospective neighborhood (via Airbnb or a hotel) to see how it really feels to be there. Be creative! Remember, time/effort/money spent reducing risk now will often be more cost effective than fixing the problems caused later. As famed architect Frank Lloyd Wright once said, “You can use an eraser on the drafting table or a sledge hammer at the construction site.”

7. Make a decision

Ironically, this is the easiest part once you’ve done the work of the previous steps. During the evaluation phase, a picture of the optimal solution likely emerged: one that addressed the most important criteria better than the others. If a clear winner wasn’t evident, it should have at least made it clear what the main tradeoffs are between the top contenders.

In either case, it’s time to make a decision. Whatever ownership model you’re using (DACI, RAPID, etc.), someone needs to select the appropriate option and get a commitment from the others needed to move forward with it. Others can disagree with the decision but should still commit to trying it. Committing and moving forward is more important than consensus, because after all, any particular decision is still a hypothesis that might be proven wrong. But its success or failure will be unknown until a decision is made and implemented.

8. Later, retrospect

So you’ve made a decision. Champagne! Are we done? Not yet. In addition to the work to actually implement the decision, the most important step remains: to learn from it.

It’s tempting to move onto the next decision right away. However, recall that the goal of this whole process is to maximize your ability to learn what will make you successful. And:

Learning cannot happen without reflection.

Once the decision has had time to take hold—which can take weeks or months—reflect back on both the outcome of the decision and the way in which it was made. Particularly:

• Did the decision actually solve the original problem? If not, why?
• How could we have made this decision more thoughtfully or efficiently?
• What can we learn from it and apply to future decisions?

I’ve found it helpful to schedule the retrospective in advance so it’s not forgotten.

And that’s it! We’re finally done.

⌘

How did I get here?

My foray into product management started auspiciously. I was motivated and had a clear plan. What the hell happened? It’s tempting to try to pin it on a single cause, but in reality it was likely the combination of several factors:

• No post-onboarding plan
• Broad scope of product oversight
• Piloting a different hiring process
• No clear “wins” after months of effort
• Lack of established processes

No post-onboarding operating framework

My initial 90-day onboarding plan was explicit and informed by a learning framework. Past that, my plans were a bit light on specifics. From my onboarding, I identified that we needed to define a clear product vision and strategy in addition to facilitating planning and execution of projects. But how does that translate into what my day-to-day and week-to-week should be? I didn’t have a great framework for organizing how I should operate.

As a result, I had trouble being proactive and ended up reacting to urgent needs and requests from others. Given my broad scope of product oversight, it was easy to become wholly consumed by reactive work. I remember many times when I would cycle endlessly—and mindlessly—between email and Slack to tackle the next reactive thing that came in. It wasn’t healthy.

Broad scope of product oversight

I oversee the products produced by five engineering teams. These are internal data platform products that include:

• data pipeline infrastructure tools
• data discovery products
• foundational analytics datasets
• experimentation services

The list of customer segments is broad: software engineers, data analysts, marketers, data scientists, and product managers. And it’s not just product I’m responsible for. Many of these products have a UI as well, but we don’t have any part- or full-time designers dedicated to this area. So UX and UI design falls to me as well.

Piloting a different hiring process

It was clear from even before I started that we’d need to hire a second product manager to help. Since I started in this role, I had been actively hiring. However, the entire process took longer than usual because I wanted to improve the typical product manager hiring process to reduce bias and increase diversity. There was more back-and-forth with recruiting to post an acceptable job description, and more time spent planning and coordinating the interview process. Ironically, this contributed to my already heavy workload and delayed getting help. But regardless, I’m glad I did because we learned a lot from it which I’ll share in an upcoming post. Most importantly, I hired someone who promises to be a great partner in product.

No “wins” after months of effort

I heard someone describe burnout as the application of effort without positive feedback or success. That feels true. My learning plan definitely called out the need to make small changes in order to learn, build trust, and gain momentum. However, applying that was more challenging than expected.

Relatively early on, I identified what I thought was one such small change: sunsetting a legacy SDK and API used for serving A/B experiments. Teams using those legacy components were eager to get off them, but unexpected attrition in engineering meant that our team would have to pause that work to devote more of our staffing to higher-priority projects for the greater org. Unfortunately for me, those higher-priority projects were long-running with completion dates months away.

Surely there were small UX issues I could have addressed? Perhaps, if I hadn’t been so spread thin. I was still learning about customers’ needs across my entire scope of ownership and didn’t have much time to go deep working on any particular UX.

Lack of established processes

We didn’t have definitive answers to any of these questions:

• How do we review and change our strategy?
• How do we discover, distill, and prioritize customer needs?
• How do we capture, synthesize, and act on customer feedback?
• How do we plan what to work on for the next few months?
• How do we test, build, release, and iterate on solutions?

Don’t get me wrong, I love that none of these had been answered yet. This ambiguity is what attracted me to this role in the first place. It’s a clean slate, our own create-your-own-adventure. However, this ambiguity combined with everything else above probably contributed to my near-burnout.

What did I do?

Several things:

1. I talked to someone about how I felt.
2. I created a plan.
3. I took a break.

Talk to someone

This someone was my manager. The first thing we discussed is why we didn’t talk about my feelings of burnout earlier—especially since we have 1:1s twice a week. We attributed it up to my own lack of self-realization that I was getting burnt out and to a period of fewer 1:1s because of vacations and scheduling conflicts.

My manager and I talked through my feelings and what could be contributing to them. Together, we created a plan to address those probable causes.

Create a plan

• Focus on hiring that second product manager.
• Identify the steps needed to define the things that are missing: product vision, strategy, operational model, and processes. Coincidentally, I had just finished reading Inspired by Marty Cagan which provided a helpful operating model to try.
• Delegate project management to engineering managers or technical program managers (TPMs).
• Be less of a bottleneck for filtering low-level or urgent requests from customers by empowering engineering managers to handle many of those requests directly while keeping me in the loop.
• Reflect on how I’m feeling and doing every two weeks.
• Take a break.

Take a break

I took two weeks off the grid. One with family in Europe, another alone as a staycation. If I’m being honest, the second one was the most restful, because there’s no such thing as fun for the whole family (ha). I would have taken more, but after two weeks I was feeling better and eager to put my plan into action.

What did I learn?

This was a great learning experience. My key takeaways:

• Reflect regularly on how you’re feeling and why. I’ve started a daily journaling practice and will continue my regular retrospectives with my manager.
• Be kind to yourself. You’re not a robot. It’s a certainty that some days you’ll feel great, and other days you won’t. Don’t beat yourself up on the latter days; treat yourself like you would a friend or loved one in the same situation.
• Take time off for mental health. Any amount helps, from a few hours to a whole week. I’ve started using sick time for those days when I’m feeling mentally drained and need a break. Sick days shouldn’t be used only for when you have the flu; your mind is part of your body too.
• Work backwards from the end to define the plan. Start with the end—what outcome you want to achieve—and work backwards to identify the steps needed to make it true.

In the end, I’m glad I identified the burnout when I did and didn’t try to power through it like many others do.

Stay safe, stay sane.

Mike

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

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:

• Intro to Product Discovery

Newsletters:

• Lenny’s Newsletter
• Bring The Donuts
• Product Talk
• Black Box of Product Management

Articles:

• Circles framework
• Start Talking! How To Do Customer Interviews That Reveal Priceless Insights
• Product Talk: Customer interview articles
• Collection of UX research articles

Books on vision, strategy, and organization:

• Build What Matters: Delivering Key Outcomes with Vision-Led Product Management by Ben Foster
• Outcomes Over Output: Why customer behavior is the key metric for business success by Josh Seiden
• INSPIRED: How to Create Tech Products Customers Love by Marty Cagan
• EMPOWERED: Ordinary People, Extraordinary Products by Marty Cagan
• Escaping the Build Trap: How Effective Product Management Creates Real Value by Melissa Perri
• Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams by Richard Banfield
• Good Strategy/Bad Strategy: The difference and why it matters by Richard Rumelt
• Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs by John Doerr
• Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts by Annie Duke
• Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton

Books on customer research:

• The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you by Rob Fitzpatrick
• Why You Are Asking the Wrong Customer Interview Questions by Teresa Torres

Engineering

Newsletters:

• Software Lead Weekly
• Pointer.io
• Irrational Exuberance
• The Pragmatic Engineer

Books:

• An Elegant Puzzle by Will Larson

People leadership

Books:

• Drive by Daniel Pink

Blogs:

• Rands in Repose (there’s a Slack group as well)

General problem solving and systems thinking

Courses:

• Decision by Design

Newsletters:

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

Books:

• Thinking, Fast and Slow by Daniel Kahneman
• The Fifth Discipline: The Art & Practice of The Learning Organization by Peter Senge
• The Fifth Discipline Fieldbook: Strategies for Building a Learning Organization by Art Kleiner
• The Great Mental Models: Volume 1 by Shane Parrish
• Out of the Crisis by W. Edwards Deming
• Thinking in Systems by Donella H. Meadows

Psychology

• Switch: How to Change Things When Change Is Hard by Chip Heath
• Made to Stick: Why Some Ideas Survive and Others Die by Chip Heath
• Influence: The Psychology of Persuasion by Robert Cialdini
• Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones by James Clear

Design

• Lean UX: Designing Great Products with Agile Teams by Jeff Gothelf
• Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience by Tom Greever

Other

• Sapiens: A Brief History of Humankind by Yuval Noah Harari
• The Inevitable: Understanding the 12 Technological Forces That Will Shape Our Future by Kevin Kelly
• Deep Work by Cal Newport
• Death by Meeting by Patrick Lencioni