I used to think I could get by on six hours of sleep. Most of us do. We grab a coffee at 2 PM, push through the afternoon slump, and figure it’s just the baseline cost of being a busy adult. But a US Navy study wrecked that delusion for me, and it holds the real thesis for how we need to think about rest.

For decades, the Navy used an 18-hour watch cycle for submariners. This schedule meant sailors regularly got much less than the recommended 7 to 8 hours of rest in a 24-hour period. When researchers finally tested the cumulative effects of this schedule, they found that sleeping 6 hours a night for two weeks straight causes the exact same level of cognitive impairment as staying awake for two full days. Those restricted to 4 hours of sleep reached this same level of impairment much faster (showing severe declines by about day 6).

The most terrifying part of the study was the invisible decline of the sleep-deprived brain. The sailors actually felt fine, and their subjective feeling of sleepiness leveled off, but their objective reaction times plummeted to legally drunk levels. They genuinely believed they had adapted, even as their test scores collapsed. Like the sailors, I was lying to myself.

That’s the true danger of sleep deprivation, and it’s the core argument of this guide. Your judgment is the first casualty of exhaustion. As your cognitive bandwidth narrows, you lose the self-awareness required to realize how tired you actually are. It creates a brutal feedback loop: the less you sleep, the less able you are to make the rational decision to go to bed.

TikTok and Reddit are currently fixated on wringing an extra 2% of efficiency out of our sleep cycles with expensive tracking rings and complicated routines. But if you’re a normal person navigating work, friends, family, and the friction of modern life, you don’t need that noise. We just need to systematically reduce the friction around a few boring, highly effective basics.

Before we dive in: this is straightforward, but not easy. Sometimes life just gets in the way. If you have crying babies or toddlers waking up at 3 AM (or, ahem, a teen out with the car on a Saturday), you probably aren’t going to get enough sleep. There should be a different article on how to survive acute sleep deprivation (checklists, single-tasking, letting folks know what’s going on, and cutting yourself slack). But that’s not what this guide is for. This one is about fixing your baseline when you actually have the agency to do so.

Why sleep actually matters

We tend to treat sleep like passive downtime, but your brain’s actually doing the heavy lifting while you’re out. The American Academy of Sleep Medicine and the Sleep Research Society both say that adults need seven or more hours of sleep each night. Right now, nearly 36% of adults get six hours or less.

When we consistently sleep less than seven hours, things start to break. Short-term memory doesn’t get filed into long-term storage. Your glymphatic system acts as your brain’s plumbing network, and it absolutely requires deep sleep to function. Cerebrospinal fluid physically washes through the brain while you sleep to clear out metabolic waste (specifically amyloid-beta proteins). Failing to get enough restorative rest ruins your sleep architecture, and that disruption is strongly linked to the buildup of these proteins and the development of Alzheimer’s disease.

Lack of sleep also disrupts your hunger hormones, leptin and ghrelin. This shift drives intense hunger and cravings, making you significantly more prone to weight gain, insulin resistance, and type 2 diabetes. Combined with weakened immunity and cardiovascular stress, you can’t just power through these realities. We can, however, fix the underlying habits.

The ordered steps

Ignore the expensive gadgets and tackle these foundational steps. The first few are the absolute backbone of good sleep, while the latter ones are more conditional depending on your lifestyle. They’re ranked roughly by how much ROI you get for your effort.

1. Anchor your wake-up time and ignore the sleep bank

Stabilize your biological clock before you worry about anything else. Waking up at the exact same time every day, including weekends, is the single highest-yield habit for better rest. We have to abandon the myth of the sleep bank. You can’t accrue a sleep debt during the workweek and pay it off by binge-sleeping on Saturday. Studies show that weekend catch-up sleep causes metabolic dysregulation and social jet lag, giving your body a hangover every single Monday.

A 2024 study in the journal Sleep actually found that sleep regularity predicts mortality risk better than total sleep duration. Waking up at the same time keeps your brain’s master clock perfectly in sync, ensuring your evening melatonin release happens predictably. Of course, there’s some flexibility. Sleeping in by a half hour on a weekend is fine and won’t derail your rhythm.

2. Seek morning light

Your brain needs bright light to know the day has started. Getting 10 to 15 minutes of outdoor sunlight within an hour of waking up sends a massive biological signal to your brain. Indoor lighting usually isn’t bright enough to fully trigger this mechanism on its own. If you wake up before sunrise, turn on as many bright overhead lights as possible to start the wake-up process, and then get natural sunlight later when the sun is up.

If wrangling kids prevents you from stepping outside immediately, just get the light as soon as you realistically can. Any morning sunlight is vastly better than none. Your commute can be highly effective, as the natural light you receive while driving to work is often enough to trigger these biological signals. When bright natural light hits specialized cells in your eyes, it sends a direct signal to immediately halt melatonin production and start a countdown timer for when you’ll feel tired that evening.

3. Respect the caffeine half-life

I quit caffeine a few years ago. I did it mostly so I wouldn’t have to manage the chemical clock in my head, but the self-righteousness is nice, too. If you still drink coffee, you need to respect its caffeine half-life (roughly 6 hours).

If you drink a large coffee at 3 PM to survive a meeting, half of that caffeine is still actively circulating in your brain at 9 PM. A chemical called adenosine builds up in your brain throughout the day to create sleep pressure. Caffeine physically blocks the receptors that detect this pressure, hiding your exhaustion from your own brain. Try to set a strict caffeine cutoff time of 12 PM or 1 PM to ensure the drug clears your system before bed.

You might know someone who drinks an espresso after dinner and falls right asleep. But passing out isn’t the same thing as getting restorative rest. A landmark meta-analysis in the Journal of Clinical Sleep Medicine showed that consuming caffeine even six hours before bed disrupts objective sleep architecture. When monitored in a lab, even people who claim to be immune to caffeine and can fall asleep still show degraded sleep quality, reduced deep sleep, and frequent micro-awakenings.

4. Eliminate the alcohol trap

Alcohol’s the most misunderstood sleep aid in the world. A glass of wine might act as a sedative and help you conk out faster, but sedation isn’t quality sleep.

Alcohol initially acts as a central nervous system depressant, but its metabolism later in the night triggers a sympathetic nervous system arousal. This rebound effect suppresses highly restorative REM sleep early in the night and drives fragmented, low-quality rest in the second half (why you might wake up with a racing heart).

Social drinking is a very real part of adult life. If you choose to drink occasionally, lessen the blow to your sleep architecture by drinking smarter. Opt for a happy hour instead of a late nightcap, and aim to stop drinking at least 3 to 4 hours before your head hits the pillow. Drink a full glass of water for every alcoholic beverage and eat a solid meal to slow the absorption of alcohol into your bloodstream. Expect an elevated resting heart rate and poor sleep quality, accept it as the cost of a fun night out, and get back on your regular schedule the next day.

5. Control your environment and your stimuli

Remember that feedback loop of sleep deprivation? Your judgment degrades first as you get tired. Staying up late to watch another episode is usually an issue of competing goals and environmental friction, combined with that impaired judgment. Revenge bedtime procrastination (like bingeing Netflix when you know it’s time for bed) is a desperate bid to reclaim a sliver of your day when you lack the cognitive bandwidth to make a better choice. Make the right choice the default choice by moving your phone charger into the bathroom and buying a cheap alarm clock.

You also have to protect your brain’s association with the bed itself. The human brain is an associative machine. If you regularly answer work emails, watch television, or scroll through social media while lying under the covers, you train your nervous system to associate your mattress with alertness and stress. Use your bed exclusively for sleep and intimacy. If you want to read or watch a movie before bed, do it on the couch.

If you can’t fall asleep within 20 minutes, get out of bed and do a quiet activity in dim light until you feel sleepy. Staying in bed while frustrated teaches your nervous system to associate the mattress with anxiety. Break that friction by resetting in another room.

6. Cool and darken your shared cave

Aim for a bedroom temperature between 60 and 67 degrees. Your body must drop its core temperature by one to two degrees Fahrenheit to initiate and maintain sleep. If the ambient room temperature is too warm, your brain will struggle to cross the threshold into deep sleep. Combine this cooling with absolute darkness. Even small amounts of ambient light from streetlamps or electronics penetrate your eyelids and suppress pineal melatonin production. Blackout curtains or a simple eye mask are incredibly high-yield investments.

Clinical sleep guidelines often assume we sleep in isolated vacuum chambers. The reality is that most of us sleep in shared, messy ecosystems. You might know a cool room is best, but you still have to negotiate the thermostat with a partner who runs cold. Good sleep hygiene requires pragmatic compromises. Maybe suggest changes as temporary experiments rather than absolute rules. Agree to try a cooler thermostat setting for just two weeks to see how it impacts energy levels. If your partner runs cold, heat the person, not the room. Invest in separate blankets with different warmth levels rather than fighting over the duvet (my wife and I did this last year, and it’s been life-changing).

7. Time your meals and exercise

Late-night digestion competes with your body’s attempt to lower its core temperature and rest. Try to avoid heavy meals within three hours of your target bedtime. But going to bed hungry can also disrupt sleep by causing your blood sugar to drop, triggering the release of stress hormones like cortisol to wake you up. If you’re genuinely hungry before bed, opt for a small, easily digested snack rather than suffering through the hunger.

Aim to finish strenuous exercise at least two hours before you plan to sleep. A major meta-analysis in Sports Medicine found that evening exercise is generally beneficial for sleep, with one major exception. Vigorous, heart-pumping workouts completed within an hour of bedtime significantly delay sleep onset and reduce total sleep time because they heavily elevate cortisol, heart rate, and core body temperature.

8. Optimize the mattress within reason

The right environment’s crucial, but don’t fall into the trap of thinking a luxury mattress will cure your sleep problems. Most studies suggest we should use a medium-firm mattress to alleviate back pain, but your preferences may differ, and spending lots of money is unlikely to produce measurably better sleep. Treat finding the right mattress as another experiment. Take advantage of generous trial periods and return policies offered by many companies to test out different options. Get something comfortable and supportive that isolates motion if you share a bed, and then focus your effort on behavioral habits.

The noise: supplements and biohacking

Once you master the basics, you might be tempted by the world of sleep supplements and trends. These interventions usually offer marginal gains at best for people who are already doing everything right. Some are easy and safe enough to try, while others are potentially harmful and should be avoided entirely.

Melatonin is a clock, not a hammer

Melatonin is the most widely misused sleep supplement on the market. People treat it like a sleeping pill because large doses right before bed act as a mild sedative. Biologically, melatonin is a darkness signal that tells your brain it’s time to begin the wind-down process. Taking massive doses is counterproductive and usually leaves you groggy the next day. Clinical data show melatonin is most effective in micro-doses (0.3mg to 0.5mg, which is way below most of what is sold but is within the range of what your body produces naturally) taken several hours before your target bedtime to gently shift your circadian clock.

Blue-light glasses and night modes

Consumer blue-light blocking glasses are incredibly popular, but the clinical data don’t strongly support their use. Standard consumer lenses don’t actually filter out enough light to prevent the suppression of melatonin. Software features like night mode or warm color shifts on your phone and computer are also mostly a matter of personal preference. The raw brightness of the screen and the cognitive stimulation of whatever you’re looking at matter far more than the color tint. Turn down the overall brightness of your screens or, ideally, put devices away entirely.

Over-the-counter aids and cannabis

People frequently turn to over-the-counter antihistamines like Benadryl or ZzzQuil when they struggle to sleep. Your body builds a rapid tolerance to them, rendering them ineffective within days. Long-term use of these anticholinergic drugs is also linked to an increased risk of dementia in older adults. Cannabis is often used to initiate sleep, but it actively disrupts your sleep architecture by suppressing REM sleep and often causes rebound insomnia when you try to stop using it.

Magnesium and other supplements

A massive industry has been built around supplements like Magnesium Threonate, Apigenin, and L-Theanine. While some mechanistic evidence suggests these compounds can promote relaxation, the clinical data for their effectiveness in treating actual sleep issues are relatively weak. The American Academy of Sleep Medicine states there’s insufficient clinical evidence to recommend supplements like magnesium for the treatment of chronic insomnia. (I take a low-dose generic magnesium pill before bed because it gives me incredibly vivid dreams - but not for sleep.)

The mouth taping trend

Mouth taping has become a popular social media trend, promising deeper sleep and reduced snoring by forcing nasal breathing. Nasal breathing is physiologically superior, but taping your mouth shut is a potentially dangerous band-aid for an undiagnosed problem. If you breathe through your mouth at night, it’s usually because your nasal airway is obstructed or because you suffer from obstructive sleep apnea. Taping your mouth doesn’t fix the obstruction; it just forces your body to work harder to get oxygen.

What about naps?

While napping is an incredible tool for cognitive performance if you follow a strict playbook (a NASA study found a 26-minute nap improved pilot alertness by 54%), naps are a double-edged sword.

Keep them under 30 minutes and finish them before 3 PM. A brief nap keeps you out of deep sleep, preventing that severe grogginess when you wake up. Keeping it early means you won’t burn off the valuable sleep pressure you need to fall asleep that night. Napping longer or later erodes your nighttime sleep drive and is linked to diabetes and metabolic dysregulation.

And while we’re here, you might have heard of polyphasic sleep (breaking your rest into multiple short chunks around the clock). Don’t worry about it. It’s an extreme optimization trend that you shouldn’t even consider.

Age-specific nuances

The biological rules of sleep change as we age. Teenagers aren’t just being lazy when they want to stay up until 1 AM and sleep until noon. Biology triggers a legitimate delay in the circadian phase during adolescence. Their bodies simply don’t release melatonin until much later in the evening than adults, making early school start times a severe biological mismatch.

Older adults frequently experience an advanced circadian phase, feeling tired very early in the evening and waking up before dawn. The timing shifts, but the biological requirement doesn’t. Older adults still need 7 to 8 hours of sleep for optimal health. Changes in brain architecture often make it much harder for them to consolidate that sleep, leading to frequent nighttime awakenings.

When to stop trying and see a doctor

Sometimes, good habits aren’t enough. If you’ve diligently reduced the friction in your routine for several weeks and you’re still chronically exhausted, it might be time to look for a medical issue. Good sleep hygiene can’t fix structural problems, and attempting to lifestyle-hack a clinical disorder is frustrating and dangerous. Consult a primary care physician or a specialist at a sleep clinic if you regularly experience certain warning signs.

Obstructive sleep apnea

Loud snoring, gasping for air, or waking up feeling like you’re choking are classic symptoms of Obstructive Sleep Apnea. This condition occurs when your airway physically collapses during sleep. If diagnosed, a CPAP machine physically keeps your airway open, immediately restoring oxygen levels and deep sleep. Talk to a doctor - if untreated, this is very dangerous.

Chronic insomnia

You likely need clinical support if you consistently can’t fall asleep or stay asleep despite having a good sleep environment and a strict schedule. Doctors usually prescribe Cognitive Behavioral Therapy for Insomnia (CBT-I) to address the underlying anxieties keeping you awake, as that’s been found to be successful in most people and much more effective than drugs.

Restless legs syndrome

An uncontrollable, uncomfortable urge to move your legs when you’re trying to rest in the evening is the hallmark of Restless Legs Syndrome. A doctor will likely check your iron levels and can prescribe supplements and/or medications - this is fixable.

Hypersomnia and narcolepsy

Severe daytime sleepiness that interferes with your life is a major red flag. If you find yourself falling asleep during normal, active situations (like driving, sitting in meetings, or talking with friends), your brain is experiencing a pathological level of sleep debt. Treatment is highly specialized and prescribed by a sleep specialist.

The truth about consumer sleep trackers

Wearable devices like the Apple Watch, Oura Ring, Garmin, and Fitbit have made tracking your rest incredibly accessible. But doctors rely on an electroencephalogram to directly measure electrical brain wave activity to accurately define sleep stages. Your smartwatch or tracking ring can’t read brain waves. These devices rely on secondary signals (primarily movement and heart rate variability) to estimate what your brain is doing.

Trackers often struggle with wakefulness detection because they rely heavily on movement. If you lie in bed awake but completely still, your device will likely assume you’re asleep. Consumer trackers often overestimate your total sleep time, creating a false sense of security about your rest. The detailed charts showing your light, deep, and REM sleep should be viewed as educated guesses rather than clinical facts - none of these trackers work universally well. Use them to observe broad, multi-week trends in your bedtime routine, but don’t obsess over a single night’s sleep score. If the numbers make you anxious, take them off.

The bottom line

We spend a lot of time obsessing over the perfect evening routine, our nighttime pills, the right mattress, and the exact temperature of our bedrooms. Those things matter; however, they’re entirely secondary to the real battle.

The biggest threat to your sleep isn’t a glowing screen or a late-afternoon cup of coffee. The biggest threat is the invisible decline of your own judgment. When you’re tired, your brain loses the capacity to realize it’s tired. It’s pernicious: you can’t decide to go to bed, which only makes you more exhausted the next day.

You don’t need more willpower to break that cycle. You need to build a system that makes the healthy choices automatic. Anchor your wake-up time, cut off your caffeine at noon, and put your phone charger in another room. Systematically eliminate the friction required to get into bed, and your biology will take care of the rest.

If there’s a shortcut, I’ll take it. If there is a tool that promises to do my work while I nap, I will buy it. When the new wave of “agentic AI” tools started dropping (tools like Claude Code, Devin, or AutoGPT), I was first in line. The pitch was incredible: Don’t just get help writing the code. Get an agent that writes the code, runs the tests, fixes the errors, and deploys it while you watch Netflix.

Trigger warning: this post will have a lot of “grumpy old man” energy.

I remember the last time we were promised a magical solution to software development. It was the early 2000s, and the promise was “outsourcing.” We were told that if we just wrote a detailed enough spec, we could hand it to a team in a different time zone, pay them a fraction of the cost, and wake up to a finished product.

We all know how that ended. We spent big bucks to build products that checked every box in the spec but failed in the market. I recall endlessly revising documents to explain “user delight” to a team that had never used the product, only to get back code that was technically functional but excruciating to use.

The good news is, today’s non-technical founders aren’t dropping $100k on an agency. They are dropping $20/month on Claude. But the bad news is the industry is lying to itself again.

I see founders convincing themselves that the reason outsourcing failed was the people. They think, “If I can write the perfect prompt and include the right context, the right skills, and use enough tokens, I’ll get it right,” and “Well, the offshore team didn’t understand my vision, but Claude Code does! Claude is smart!”

But outsourcing didn’t fail because of the people. It failed because the handoff is a lie.

The return of Waterfall

I recently tried to use Claude Code for a simple task, a Python script to scrape some data (well, a lot of data). I spent 20 minutes crafting the perfect prompt (the modern PRD). I set up the permissions. I hit enter. I leaned back.

Two hours later, I came back to a mess. I had 14 new files, 600 lines of code, and a confident README that described a script that didn’t quite work.

The agent had technically done what I asked. It wrote code. It passed tests. But it had built the wrong feature.

For example, the dataset had missing timestamps. A human partner would have asked, “Should we drop these rows or infer the time based on the sequence?” The agent just dropped them. It was a valid code decision - the script didn’t crash - but it made the time-of-day analysis I wanted to do impossible.

What it built was technically correct, but practically useless.

We’ve confused toil with thought.

We are trying to outsource the hard work of thinking to a machine that is designed to satisfy a prompt, not solve a problem. We are recreating waterfall development.

It feels like speed. It looks like shipped features. But it’s actually just “unplanned work” waiting to explode: the firefighting that destroys your roadmap. Agents are efficient engines for generating unplanned work. They let you ship “planned” code today that requires a forensic investigation to debug tomorrow.

Agents fail when you use them as a batch processor for ambiguous work. You trade the tight feedback loop of a copilot for the blind handoff of an agent.

When you use an agent to do the work for you, you skip the friction. You skip the learning. You get “alibi progress,” a pile of artifacts (code, text, slides) that look like work, but contain no actual understanding.

The “micro-Boeing“ moment

We’ve seen this movie before.

In the early 2000s, after the merger with McDonnell Douglas, Boeing’s culture shifted. The new finance-driven leadership didn’t want to run an engineering company; they wanted to run a “business.” And in a business, you reduce costs.

For the 787 Dreamliner, they decided that “integration” was just another cost center to be slashed.

They didn’t just outsource the parts (Boeing had always bought tires, landing gear, etc), they outsourced the integration (assembly). They told their “Tier 1” suppliers: “Here is the spec. You figure out how to build the entire fuselage section. Just send us the finished product.”

The finance team loved it. It looked efficient on a spreadsheet. But they had made a mistake: They had outsourced the struggle.

In the olden days, Boeing engineers fought with suppliers, argued over tolerances, and battled over how the wiring harness would fit through the bulkhead. That friction wasn’t waste; that friction was where the quality came from.

By handing off the integration, they removed the moment (and the incentive) for the different parts of the process to struggle together.

The result was a mess. It started with 787 sections that arrived at the factory and didn’t fit. It festered into a culture where nobody owned the whole. And it ended, twenty years later, when a cabin door plug blew out of a 737 MAX mid-flight. The door plug failure was symptomatic of the same pattern: when you separate the people doing the work from the people designing the work and from the people bringing it all together, you lose the ability to catch the small things that become big things.

My Python script was a “micro-Boeing” moment.

When I handed off the task to the agent, I created what manufacturing folks call traveled work: the work comes back without the why, and now you’re paying a tax to reconstruct the context.

This is an architectural failure, not just a process one. We forget that software architecture mirrors our org structure. When you hand off a task to an Agent, you are effectively creating a silo of one. You sever the high-bandwidth communication loops required to discover, understand, and solve complex problems. You aren’t just outsourcing the task; you are breaking the architecture.

Polanyi’s Paradox explains why: We know more than we can tell.

I can’t prompt my taste. I can’t prompt my risk tolerance. I can only apply it while I’m watching the work happen. When you pair-program or pair-write with a copilot, you transfer that knowledge in real-time. When you hand off to an agent, that knowledge is lost.

The partner and the associate

So, are agents useless? Absolutely not. I use them every day. But to use them effectively, I’ve found I have to treat them very differently depending on the mode I’m in.

When I use a copilot, it feels like pairing. I’m still driving; it’s just faster to explore options. I type a little, it suggests a little, I accept some, reject most, and the real work is that constant nudging (my judgment is in the loop every few seconds).

The authors of Apprenticeship Patterns call this “Rubbing Elbows.” You learn by sitting next to a master (or just a peer) and watching how they work. When I use a Copilot, I am rubbing elbows with the model. I am learning from its suggestions, and it is constrained by my intent.

An agent is different. An agent is a handoff. You point it at a task, go make coffee, and come back to a finished-looking artifact. That can be amazing, until you realize it made ten “reasonable” choices you never would have made, and now you’re debugging someone else’s mental model.

It’s like delegating to a brilliant first-year associate: they are smart, diligent, and eager to please, but they optimize for “finishing the task,” not “solving the problem.” And because you treat them as an expert, you don’t supervise them. You let them work all night, only to discover they produced the perfect solution to the wrong problem.

The mistake we make is assuming the associate can do the partner’s job just because they work hard and talk smart.

The commodity trap

Lately, I’ve noticed a pattern in myself. If I can build it in Claude Code, it might be cool, and it might solve a problem, but I’m likely not fundamentally adding value in a strategic way. (Check out my site https://goodmon.day to see what I mean.)

In engineering strategy, we distinguish between “Core” (what differentiates you) and “Context” (what you need to exist, like logging or payroll). Agents are incredible at Context. They can scaffold a boilerplate app in seconds. But if you use them for Core - if you let them define your unique value proposition - you are admitting that your Core is generic.

If I can describe the solution so perfectly that an agent can build it without my intervention, then I am building a commodity.

Satisficing vs. differentiation

The heuristic comes down to one question: Is “good enough” actually good enough?

Use agents for satisficing (the toil). There are parts of your job where “perfect” is a waste of time. Formatting a messy JSON blob from a legacy API. Writing unit tests for a stable function. Summarizing a 60-minute meeting transcript. Converting a Jira ticket into a release note. In these cases, the outcome is binary. It works, or it doesn’t. If the agent gets it 90% right, the cost of fixing the last 10% is low. Delegate the toil.

Use copilots for differentiation (the strategy). Then there is the work where you are making substantial bets: Defining the product vision, architecting a new system, or writing a difficult email to a churning client. In these cases, “satisficing” is failure - if your strategy is just “average,” you lose.

This doesn’t mean you can’t use agents within strategic work, like drafting copy, summarizing research, or enumerating edge cases. But you have to keep the core judgment loops tight. The agent tries to minimize friction to get to “Done.” The copilot forces you to engage with the friction to get to “Good.”

Shadow competency

The final danger is shadow competency.

When TSB Bank had its massive IT meltdown in 2018, locking millions of customers out of their accounts, the post-mortem was fascinating. They had outsourced so much of their IT that they no longer had the ability to judge if the work was good. They had lost their shadow competency, the ability to inspect the work of others.

The classic book Pragmatic Programmer advises using “Tracer Bullets, “ code that penetrates all layers of the system to test feasibility (I love this model). When you write the code or the email yourself, you’re firing tracer bullets. You feel the friction of the database; you see the latency of the API, you notice the awkward phrasing. To maintain shadow competency, you need to do enough manual reps to know what “good” actually looks like. You need to read the code. You need to rewrite the draft. You need to ask, “What would make this wrong?” before you ship.

Why does this matter? Because if you don’t know what good looks like, you can’t spot what bad looks like.

The tl;dr

If you’re a product manager, tech leader, or founder, your value isn’t your output. Your value is your judgment.

When you hand off a task to an agent, you are trading your judgment for speed. Sometimes, that’s a great trade (fixing Excel errors). But for the work that matters, the work that requires empathy, insight, and strategy, that trade hurts you.

Don’t try to outsource your thinking. Use agents to clear the brush. Use copilots to climb the mountain. And know the difference.

Try this:

Try the Surprise Test. Look at the last piece of AI-generated work you used. If you were surprised by the output and just accepted it, you are likely in the “satisficing” trap. If you argued with the AI, refined the output, and caught a nuance it missed, you’re doing it right.

Then, audit your friction. If you spent longer writing the prompt than you would have spent doing a rough first draft, you tried to waterfall a creative process that only reveals itself while you’re building it. That’s your cue to switch modes.

Finally, define your “associate” tasks. Pick five recurring chores that don’t require judgment, set up an agent workflow for those, and keep the rest close—because that’s where your taste and strategy actually live.

The six crises every organization faces (Tim Casasola)
Does it ever feel like your organization solves one major problem only to create a new one? According to a classic 1972 model from USC professor Larry Greiner, this isn't a sign of failure but a predictable cycle of growth. The article revisits this framework, showing how companies evolve through distinct phases, each ending in a crisis that sparks the next stage of growth—from a "crisis of leadership" to a "crisis of red tape." The primary takeaway is that growth is not a linear path but a pendulum swing between centralization and decentralization; solving for a lack of direction requires structure, but that structure eventually stifles autonomy, requiring delegation. For leaders, understanding this model provides a powerful tool to anticipate the tensions on the horizon and proactively prepare the organization for the inevitable challenges ahead. (link)

Is this strategy any good? (Will Larson)
Judging a strategy's quality is notoriously difficult, and simply looking at the outcome isn't enough. This article argues against grading a strategy solely on its outputs (which ignores context and cost) or its inputs (which ignores whether it actually worked). A more effective rubric evaluates a strategy on three key questions: How quickly is it refined, how expensive is that refinement for the teams involved, and how well does the current version solve the initial diagnosis? This approach treats strategy as a living endeavor that must adapt. The other key insight is to view strategy in phases; a once-successful strategy may need to be abandoned when a new phase, defined by new information, renders the original diagnosis incomplete. This reframes ending a strategy not as a failure, but as a necessary and often savvy evolution. (link)

Share

Subscribe now

The Anti-Goal Setting Guide: Creating Objectives People Actually Care About (Allison McMillan)
If the phrase "goal setting" makes your team collectively groan, the problem isn't the goals—it's the lack of genuine connection to them. To move beyond objectives that just gather digital dust, leaders must focus on emotional investment. The article suggests three practical approaches: first, understand each person's individual relationship with goals by exploring their natural patterns of achievement. Second, frame the exercise as a narrative by asking, "What's the story you want to tell about yourself a year from now?" This taps into identity and is far more compelling than typical frameworks. Finally, ensure the goal is entirely within the person's control, reframing objectives that depend on external factors. When people start referencing their goals unprompted, you know the process has moved from obligation to opportunity. (link)

The Real Cost of Leadership Paralysis and How to Lead with Clarity Again (Rachael Lowell)
Leader burnout is often misdiagnosed as a personal failure to keep up, but it's more likely a symptom of trying to operate within a system not built for today's complexity. This article posits that leadership paralysis stems from navigating constant uncertainty and pivoting, a challenge that standard frameworks can't fix. The solution isn't just another model but a set of "survival strategies" that integrate humanity with performance. The proposed SHIFT framework outlines five core capacities for leaders to cultivate: Security (internal steadiness), Horizon (a future focus), Impact (cutting through the noise), Fluidity (moving with change), and Ties (leading through connection, not control). These aren't soft skills; they are essential tools for finding clarity and leading effectively when the ground beneath you feels chaotic. (link)

Feedback in the workplace (Tom Geraghty)
What if most of the feedback being delivered in your organization is doing more harm than good? New research suggests this is a widespread reality, with a stunning 80% of survey respondents stating that feedback has, at some point, undermined their confidence or motivation. While about two-thirds of people agree that feedback sometimes helps them learn, an equal number feel it is often irrelevant. This highlights a critical disconnect: the same feedback can simultaneously help and harm. The analysis further reveals that feedback has a polarizing effect on psychological safety, with 42% of people reporting it makes them feel less safe. The core takeaway is that feedback isn't fulfilling its potential. To fix this, those giving feedback must focus on delivering it constructively, empathetically, and clearly to drive performance while minimizing harm. (link)

AI writes bad code, but what if that’s the good news? (Yannick De Pauw)
Is messy, AI-generated code a threat or an opportunity? For non-technical founders and product owners, AI is becoming a powerful prototyping intern, enabling rapid validation of ideas directly in the codebase. This creates a natural tension with engineers focused on clean, scalable architecture. The key strategic takeaway is to reframe the engineering role from gatekeeper to mentor. Instead of rejecting AI-generated code, engineers can guide its evolution from a promising, if flawed, prototype into a robust, production-ready feature. As the author notes from his own experience, “Refactoring to me means: this feature is worth keeping.” This mindset shift treats messy code not as a failure, but as a signal that an idea has enough merit to invest in, turning AI into a collaborative tool for accelerating value discovery. (link)

LLMs are mirrors of operator skill (Geoffrey Huntley)
With AI fundamentally changing software development, how we identify skilled engineers is now broken. The author argues that since large language models can solve most traditional interview questions, screening must evolve to assess a candidate's true proficiency with the new tools. An LLM, in this view, is a mirror reflecting the operator's skill. The critical takeaway is to shift interviews from rote problem-solving to direct observation. Companies should ask candidates to "dance with the LLM" on a screen share, observing their workflow, how they build context, and their ability to critique and refine AI-generated output. This assesses deeper skills like taste and judgment, which are the new differentiators. As the author puts it, if an interviewee teaches you a new meta, they’re a great fit. (link)

Share

Subscribe now

When AI Has Better Taste Than You ( )
As AI's creative and analytical skills accelerate, what is left for humans to contribute? Drawing on a conversation with Notion CEO Ivan Zhao, this essay proposes a framework of three value components: capabilities (our skills), taste (our preferences), and agency (our will to act). AI is rapidly conquering capabilities and can likely learn taste by pattern-matching across vast datasets. The most durable human advantage, therefore, is agency. It's the motivation to decide which problems are worth solving, the drive to pursue a vision, and the will to act on our values. While AI can optimize for a programmed objective, humans provide the initial spark of intent. In a world where skills and even taste become commoditized, our agency—the choice to move the hand to draw what the eye admires—may be our final, most precious moat. (link)

Pace Layering: How Complex Systems Learn and Keep Learning (Stewart Brand)
How do robust civilizations adapt and endure over time? The answer lies in "pace layering," a model where different parts of the system operate at different speeds. Brand identifies six layers: fast-moving Fashion/art and Commerce at the top, followed by slower Infrastructure, Governance, Culture, and finally, the geological pace of Nature. The strategic insight is that this structure creates a healthy tension that fosters resilience. The fast layers innovate and propose, while the slow layers stabilize and constrain. "Fast learns, slow remembers. Fast gets all our attention, slow has all the power." A society runs into trouble when one layer's pace is forced upon another, like when commerce's demand for speed is allowed to degrade nature. Understanding this dynamic provides a powerful framework for thinking about long-term strategy and systemic health. (link)

Prompting is Managing ( )
A recent study suggested LLMs create "cognitive debt," but this piece offers a compelling reframe: prompting isn't just a simple action, it's a form of management. The author introduces the "Prompting-Managing Impact Equivalence Principle," arguing that the cognitive load of using an AI assistant mirrors that of supervising a junior human. The perceived mental "idling" isn't sloth; it's the watchful calm of a manager engaged in supervisory control: delegate, monitor, integrate, and ship. This perspective holds a key lesson. The challenge of the AI era isn't a neurological decline but a skills gap. We're putting novice users in a manager's seat without management training. The upgrade path isn't to ditch the tools but to teach people the craft of oversight, quality control, and strategic intervention. (link)

June 2025: The AI agent schism ( )
A schism is quietly forming in the world of AI agents, splitting between non-deterministic (autonomous, reasoning) and deterministic (predictable, API-like) approaches. While the hype often centers on autonomous agents that can think for themselves, the reality in high-stakes enterprise environments is starkly different. For enterprise use cases in sectors like healthcare and finance, what users truly want is an API—a tool that delivers the same output reliably, every single time. The core takeaway is that at any real scale, variability is a liability. A non-deterministic agent that chooses its own path introduces an intolerable risk of exceptions. The winning strategy for enterprise agents, therefore, is to be deterministic by design, using models to handle edge cases and self-heal UI changes, not to make core operational decisions. (link)

ChatGPT: H1 2025 Strategy (OpenAI)
It’s not often we get to see the internal strategy of a company at the center of the tech universe, making this leaked document a valuable artifact for thinking about our own strategic planning. The plan details OpenAI's vision to evolve ChatGPT from a chatbot into a "super-assistant" that is deeply personalized and serves as a primary interface to the internet. The strategy outlines a "T-shaped" assistant with broad skills for daily life (planning trips, managing calendars) and deep expertise in complex domains like coding. A core principle for H1 2025 is to first build a valuable, indispensable product before pursuing wider third-party integrations. Key initiatives include relentless weekly iteration, strengthening the brand to be synonymous with its category, and a policy push to let users set ChatGPT as their default assistant on all major operating systems. (link)

The Great Talent Drain: Why Your Best People Are Ghosting You (And How to Win Them Back) (Angelo Santinelli)
If you're wondering why your best employees are leaving, this article offers a blunt diagnosis. With a private sector separation rate of 4.4% and over half of employees disengaged, the "Great Talent Drain" is a crisis for startups competing with BigTech salaries. The core issues aren't surprising: poor leadership, scant growth opportunities, and uninspiring company cultures. The key takeaway is that founders can't just wing people management. The piece advocates for concrete actions like structured leadership training, frequent and meaningful feedback (especially for Gen Z), and creating genuine psychological safety. This is the kind of objective feedback leaders need on why their people are quitting; the advantage startups have isn't cash, but the agility to build a culture that truly values its team. (link)

Transmitting user empathy via data ()
Simply presenting data rarely fosters true user empathy within a team. The author argues that quantitative researchers have a crucial role in building this connection by providing the necessary context that makes numbers feel real. A metric like a "2-minute wait time" for a UI operation is just a number until it's framed by the context that users become frustrated after mere seconds. Data is not neutral; researchers must have a viewpoint and deliberately use context to guide stakeholders toward the correct interpretation of user pain. A key goal for leaders is to ensure everyone has a deep, empathic understanding of the user, and that quantitative data, when presented with the right narrative, is a powerful tool to achieve it. (link)

Share

Subscribe now

How to sell annual plans ()
In the face of volatile, project-based AI usage, driving customers to annual plans is a powerful strategy for improving retention and cash flow. This article presents 14 tactical ideas, cautioning against forcing the switch and instead recommending softer nudges. Key strategies include making annual plans the default on pricing pages (a practice used by 88% of Cloud 100 companies), offering more generous discounts based on LTV data, and creating lifecycle triggers that prompt an upgrade early, when customers are most engaged. Hard data trumps intuition, even for people as experienced as the author. While one might think it's best to wait before pushing an upgrade, data shows customers are 3-4 times more likely to upgrade in month two than in month nine. It's a playbook of data-backed nudges over assumptions. (link)

How to redraw a city (Anya Martin)
Japan's evolution into a nation of hyper-functional cities, despite facing immense challenges like fragmented land ownership, offers a profound lesson in urban planning, and planning in general. "Land readjustment" is a process of pooling plots, redrawing boundaries to accommodate infrastructure, and redistributing the new plots. This approach built durable public support for drastic change by sharing the profits of development and requiring supermajority consent from landowners. Does this sound like anything PMs do? The article serves as a powerful reminder of how the planning process can significantly influence the outcome. By designing a system that aligns stakeholder incentives and ensures shared benefits, Japan successfully executed massive infrastructure projects that would be politically impossible in most countries today. (link)

PM Jobs - a podcast playlist (Josh Herzig-Marx)
Here's something I created for anyone navigating a PM job search. It's a custom "podcast" feed that aggregates episodes from several different podcasts into a single, subscribable playlist. You can stream the episodes directly from the page or copy the unique RSS feed link into your preferred podcast player to listen on the go. I built the underlying platform, Podfolio, for anyone who wants to create their own curated collection of podcast episodes. I hope you find it useful! (link)

Is Your Hiring Process Accidentally Pushing Away Amazing Neurodiverse Engineers? (Andrew Murphy)
This article critically examines common pitfalls in tech hiring that inadvertently alienate neurodiverse talent, as well as women and individuals from underrepresented groups. It outlines seven key problem areas, from overly demanding "unicorn" job descriptions to lengthy interview processes and the biased concept of "culture fit." The piece provides actionable strategies for each, advocating for more inclusive language, streamlined processes, a focus on "culture add," structured interviews, transparent communication, and diverse talent sourcing. This is a crucial guide for any organization committed to building genuinely diverse and high-performing engineering teams. (link)

My AI Skeptic Friends Are All Nuts (Thomas Ptacek)
This provocative article argues that many AI skeptics in the programming world are "nuts" for dismissing the transformative power of Large Language Models (LLMs) in software development. It debunks common criticisms, such as "hallucination" and the production of "shitty code," by emphasizing the role of AI agents and the need for developers to adapt their workflows. The piece argues that LLMs excel at tedious coding tasks, boost productivity, and are immune to inertia, thereby freeing human developers for more complex and creative work. It challenges the notion of "craft" in professional software development, suggesting that resistance to LLMs often stems from misplaced concerns or a lack of understanding about their current capabilities. (link)

Subscribe now

What the collapse of the Ming Dynasty can tell us about American decline (Noah Smith)
This article draws a compelling parallel between the 17th-century collapse of the Ming Dynasty and potential signs of decline in contemporary America. It identifies key factors in the Ming's stagnation, including isolationism, disregard for science, and a "paradox of development" or "high-level equilibrium trap" that led to complacency. The piece suggests that America exhibits similar concerning trends, such as anti-immigrant sentiment, geographic illiteracy, a decline in interest in STEM fields, and a reluctance to acknowledge areas where other nations surpass it. This serves as a timely historical warning, urging America to shed its complacency and embrace global learning and reform to avoid a similar fate. Despite being from 2015, the themes of insularity and resistance to adapting to external progress feel acutely relevant today. (link)

Your product can't see itself. (Mike Watson)
This article argues for a fundamental shift in how product teams approach observability, moving it from a post-development afterthought to an integral part of the planning process. It highlights the common issue of shipping features "flying blind" due to inadequate instrumentation, leading to missed errors and user struggles. The piece proposes "flipping the product planning script" by defining necessary measurements and signals before design, fostering a shared language around learning goals. It offers practical "Monday-morning moves" for implementing this, such as identifying critical user paths, creating learning maps, defining observable signals, and establishing weekly observability reviews. The core message is that upfront investment in observability leads to "compound returns" in understanding user behavior and building better products. (link)

An AI "Metamorphosis": Transforming into an AI-native company (Sarah Tavel)
What does it truly mean for a company to become AI-native beyond surface-level tool adoption? This interview with Rekki's CTO, Borislav Nikolov, reveals that a genuine transformation involves a "metamorphosis" in organizational thinking and structure. A key strategic takeaway is the shift in the CTO's role from task executioner to an internal PaaS provider, empowering all employees by giving them the right "primitives" to solve their own problems, essentially turning everyone into a developer. Another vital tactic is fostering a deep understanding of LLMs across the company, challenging the ingrained belief that only engineers can code and thereby democratizing technical capability. This profound change hinges on believing in the capacity of non-technical people to code and building the infrastructure to support them. (link)

The Tech Recruitment Ruse That Has Avoided Trump’s Crackdown on Immigration (Alec MacGillis)
What happens when policy incentives are fundamentally misaligned with stated goals? This ProPublica investigation into the PERM green card process illustrates a stark example relevant to US tech founders and product managers, revealing a system almost designed to be gamed. The requirement for companies to "search" for US workers after an H-1B employee is already integrated into the team often leads to perfunctory efforts, like obscure newspaper ads, rather than genuine recruitment, a direct consequence of rules clashing with practical incentives to retain proven talent. For founders, this highlights the challenge of navigating flawed regulatory landscapes, impacting long-term workforce planning and the ethical dimensions of talent retention. (link)

Subscribe now

Why Bell Labs Worked (areoform)
How did Bell Labs become the crucible of 20th-century American innovation, and why can't we seem to replicate its magic today? This piece argues that the lab's success, orchestrated by leaders like Mervin Kelly, stemmed from a culture of radical freedom and patronage, not metrics-obsessed micromanagement. The core strategic principle was Kelly's belief in "managing genius by not managing it," trusting handpicked, driven individuals with resources and autonomy for years if needed. Tactically, this meant fostering an environment where researchers and makers could cross-pollinate, driven by curiosity and a desire to impress peers, not just a boss. The article posits that modern "MBA culture," with its relentless focus on narrowly defined productivity and accountability, has stifled the conditions necessary for such groundbreaking, long-term research. (link)

Leading From The Front (Stay SaaSy)
Effective leadership isn't just about being reachable when things go wrong; it's about consistently being present where the action is. This article champions "leading from the front" as crucial for gaining firsthand information, motivating teams, and catalyzing meaningful action. A key strategic understanding is that a leader's predictable presence in critical situations—be it customer calls or incident responses—unlocks higher-order motivations like professional pride and duty in their team. Tactically, this requires calendar discipline to ensure availability, developing the skills to be genuinely useful (like basic debugging or coordinating resources), and maintaining a poised, determined demeanor that instills confidence and urgency without causing panic. Crucially, it also means rigorously following through on issues to prevent recurrence. (link)

What Real Feedback Sounds Like (Claire Lew) Effective leadership hinges on the courage to deliver clear, direct feedback, yet many managers falter, opting for diluted messages or avoidance. This piece offers concrete scripts for addressing common challenging situations, such as an underperforming team member or a "brilliant jerk," emphasizing that clarity, while sometimes uncomfortable, is kinder than ambiguity. The core takeaway is that real feedback isn't about harshness but about respectful, unambiguous communication that helps individuals understand their impact and areas for growth; a second crucial point is the necessity of "emotional courage" to initiate these vital conversations. By providing actionable language, the article empowers leaders to foster a culture where honest, constructive dialogue is the norm, ultimately leading to stronger teams and better outcomes. (link)

The Era of the Product Creator (Marty Cagan) The product management landscape is evolving, ushering in "The Era of the Product Creator" where the emphasis shifts to individuals actively shaping products and solving genuine customer problems. This article highlights that the role of a product creator isn't confined to a title but defined by a proactive involvement in product discovery and a commitment to tackling product risks, especially with the rise of generative AI empowering more team members. A key strategic insight is the increasing value of "high-agency" product managers who drive innovation, rather than simply manage backlogs. Furthermore, the piece suggests that this era will see a clearer distinction between those who truly create and those who perform more administrative product tasks, welcoming all who aspire to build impactful solutions. (link)

Subscribe now

What if pricing was your best feature? (Amit Godbole) Could your pricing model be more than just a number, perhaps even your product's most compelling attribute? This article challenges product teams to treat pricing strategy as a core feature, capable of significantly impacting user acquisition and perception, much like Spotify transformed its offering through its pricing. The primary takeaway is that thoughtful pricing can alleviate major friction points in the customer journey and should be integrated into the product experience, not just tacked on. A second insight is that by reframing pricing discussions and experiments as "pricing features," teams can unlock new avenues for innovation and value delivery, making the cost feel like a seamless and fair part of the overall product value proposition. (link)

Your product can't see itself. (Mike Watson) Many product teams fly blind after launch, lacking the instrumentation to see how features truly perform or where users struggle, as illustrated by a new checkout flow that doubled support tickets due to unmonitored errors. The article argues for making observability a foundational part of product planning, not an afterthought, by asking "What would we need to measure to validate our hypothesis?" before design even begins. A key tactical takeaway is to start small by picking a critical user journey, creating a "learning map" with the tech lead to define success and failure signals, and setting up a focused dashboard. This approach transforms instrumentation from overhead into an essential tool for understanding, enabling teams to make data-driven decisions and build institutional knowledge about actual user behavior. (link)

You should play with vibecoding for GTM (Alex Shartsis) Go-to-market strategies are being revolutionized by "vibecoding" tools (like Lovable, Bolt, Cursor, Replit) that empower even non-technical folks to build significant GTM leverage quickly. This article demystifies AI coding, showing how it differs from simple automation by enabling the creation of actual web products, prototypes, and lead magnets from scratch, often in hours. The primary strategic takeaway is that GTM leaders no longer need to be solely reliant on engineering teams; they can now rapidly develop tools like ROI calculators or conference scraping scripts to directly impact lead generation and sales conversations. A practical insight is to start with a specific pain point, provide clear context and instructions to AI coding agents, and iterate quickly to build valuable assets like interactive landing pages or feature prototypes, unlocking previously unattainable speed and efficiency. (link)

What Product Leaders Get Wrong (Melissa Perri, Supra Insider podcast)
If you’ve ever stepped into a Head of Product role and wondered, “What exactly is my job?” this interview is a masterclass. Melissa Perri outlines the real work: bridging the gap between strategy and execution, partnering with the CEO to define (and sometimes clarify) company direction, and aligning teams on what matters most. She dissects why so many product leaders fail—not due to lack of vision, but because they haven’t diagnosed their context or calibrated expectations. It’s packed with advice on growing into CPO roles, supporting founder-led orgs, and building trust without giving up your own judgment. (link)

Unlocking High Software Engineering Pace: Strictly Limit Work in Progress (Jim Grey)
Want to speed up your dev team? Stop starting so much work. This sharp post explains how WIP (work in progress) limits are the secret to higher quality, faster throughput, and lower delivery risk. Jim walks through common anti-patterns, like spreading a team of five across five parallel streams, and shows how swarming sequentially leads to faster delivery and fewer defects. A quick, tactical read with powerful implications for any team struggling with predictability. (link)

Delivery Is the Catalyst (Adam Thackeray)
In fintech, you're not just shipping software, you’re shipping trust. Adam nails why delivery isn’t just execution; it’s the beating heart of scale. From the social pitfalls of misalignment to the compounding returns of operational excellence, this piece reframes delivery as the thing that unlocks everything else: innovation, confidence, momentum. Tons of strong lines here (“It’s not the product. It’s the catalyst.”) and a must-read for product leaders in high-stakes domains. (link)

Four Things Queueing Theory Can Teach Us About Software Development (Jeff Foster)
Think queueing theory is academic? Jeff shows it’s everywhere in software development. From WIP limits and Little’s Law to why batching work kills flow, this is a practical crash course in how invisible bottlenecks are killing your velocity. The simulations make abstract ideas feel grounded, and the four final takeaways are gold. A surprisingly fun, illuminating read. (link)

It was Monday, 8:30 AM. My first day. The whole company, all eight of us, crammed into the tiny conference room. The CEO, gesturing towards a half-erased whiteboard sketch, kicked off the “weekly backlog review.” He told me just to listen while I got my bearings, but sitting in the corner didn’t feel right. I’ve been hired into new roles like this a bunch of times. Some transitions went well; many could have gone better. Mapping out a 30-60-90 plan sounds great on paper, but in a startup, it collapses fast. My process is counterintuitive and fueled by late-night Notion pages and endless Slack threads. But it works.

Especially if you're an experienced hire joining a rapidly evolving company, that traditional 90-day roadmap is usually too slow. I tried the usual path at a 2,000-person PE-owned company. My first few weeks were spent interviewing colleagues and stakeholders, reviewing plans. But by my third month? Massive turnover and a new company strategy rendered much of what I’d learned irrelevant. And in the meantime, I still hadn’t done any “real” work. Startups pivot. What looks important on Day 5 might be a forgotten relic by Day 45. Your meticulous plan? Obsolete before you even hit the halfway mark.

People crave structure during transitions; the 30/60/90 tries to set expectations and track progress. But in the startup world, where velocity is king, resources are tight, and change is the only constant, that rigid, lengthy structure often crumbles. Its underlying assumption of stability just doesn't fit.

What’s my alternative? A counterintuitive process I call the 3/6/9 Onboarding Plan: what you should accomplish by your third day, sixth day, and ninth days on the job. The numbers are approximate, but the core idea is: Take on the “physical” work faster than you think you should, and go slower on applying judgment.

The “shadowing trap”

Let’s begin with typical advice when starting a new job: “You’ll just shadow me for a week.” It sounds helpful. In practice, it's often a disaster.

That person you’re shadowing? They’re already drowning; that’s why they hired you. Now, they still have their full workload, plus they have to teach you. In addition, the constant question of whether you’re finally ready to go solo adds to their cognitive load. For a while, every day is a little worse than the one before. Their stress level increases. And when people are stressed? They take shortcuts. Instead of explaining, they just do it themselves. And as the newbie, it’s rough to watch your presence make things worse.

Subscribe now

The 3/6/9 plan: Dive in, document your learning, delay big calls

Instead of passively shadowing, you’ll hit the ground running, learn by taking ownership, and build trust fast.

Phase 1: Grab the work & start logging

Day 1. Don't just shadow. All the meetings, reports, updates, etc., that you’ll ultimately be responsible for? Start doing them right now. For instance, I grabbed Tuesday’s bug-triage call, the one nobody wanted because it always ran 20 minutes long and left everyone grumpy. Take them over. Tell your new colleagues, “As of right now, I'm running. It'll be messy at first, I'll ask a million questions, but I'm taking it.” You’ll feel incompetent, maybe even overwhelmed; that’s okay. Even better, you were likely hired because someone wasn’t able to give the work as much time and attention as it deserved—you may not be as bad as you think!

Key point: while Day 1 is rough, Day 2 is slightly less rough. Every day is a little better than the one before. You’re creating an upward trend. Your colleagues see progress daily, not weeks down the line. Because of recency bias, people tend to weigh recent events more heavily and feel this positive momentum strongly. The faster you can contribute meaningfully, the quicker you build confidence, both your own and the team’s.

And start writing, but for yourself. Start a doc or crack open a new notebook – your Phase 1 Log. Dump everything in: names, terms, workflows you see, questions you have, stray thoughts. Don't organize, just capture. This helps you handle the flood of new information and frees up mental bandwidth.

Phase 2: Do the work & structure the mess

Week 1: Keep running the things you took over. Your questions will naturally get better, less “Where is...?” and more “Why this way?” Build relationships by doing the work alongside people. But resist the urge to critique or change. You don’t have the context. Assume people were smart when they set things up. Avoid the “action imperative,” that urge to “fix” things before you understand them, a trap Michael Watkins warns about in his classic, The First 90 Days:

Falling prey to the “action imperative”: You feel as if you need to take action, and you try too hard, too early to put your own stamp on the organization. You are too busy to learn, and you make bad decisions and catalyze resistance to your initiatives.

Focus on comprehension. You can still deliver small, straightforward wins, like fixing a nagging bug in the checkout flow or drafting that overdue help doc, to build credibility.

Now, structure your notes – Phase 2 Synthesis. Start organizing that log from Phase 1. Focus on the concrete aspects of how work actually happens – the elements you will eventually influence. I think of these as:

• Artifacts: The stuff – product requirements docs (PRDs), designs, internal wikis, reports, dashboards, templates, code.

• Rituals: The meetings – stand-ups, planning sessions, design reviews, and async team communications, too.

• Cadences: The schedule on which work happens – sprints, release cycles, reporting periods.

• Org Structure: The who – teams, roles, reporting lines. Mapping these helps you see how things actually get done clearly, separate from the big-picture strategy (that comes later).

Phase 3: Map the system & test your understanding

Week 2: You should be getting the hang of the day-to-day. Now, dig deeper into why things are the way they are. Ask about historical decisions. Understanding this history isn't about critiquing the past; it's about gaining the context needed for productive conversations about where to go next.

Start Phase 3 Drafting. Crucially, you're writing things to share, but specifically to get corrected. Take your Phase 2 understanding of artifacts, rituals, etc., and map it out: “Here's how I think our release process works. Please review this and tell me where it’s wrong or incomplete.” You’re making it easy for people to edit your understanding. Think of these drafts as conversation starters, not final proposals. Getting things written down helps everyone get on the same page. You’re also starting to form hypotheses about the actual strategy. What game is the company playing? This is vital because misalignment, especially with a founder's vision, is deadly in startups.

What the listening tour is really for

A listening tour matters, partly because you’re expected to do one. But its real value early on is often misunderstood. Research on trust confirms what feels intuitive: connecting with people personally (warmth) builds trust faster than just trying to impress them with your hard work and skills (competence) right away. For instance, Shelly, our usually quiet designer, only really opened up about her frustrations with the handoff process after we’d chatted about our shared love for obscure board games during a coffee break. (Just be aware of participation bias – how these tours can preference the voices of those most comfortable or eager to speak up). Your goal isn’t to collect ‘objective truth’ and form snap opinions. You don’t have enough context yet, so slow down on judgment.

What you’re really doing is demonstrating that you’re the kind of person who will listen. This helps create the psychological safety needed for people to eventually share honest feedback. And, when you do eventually share your hypotheses or question the status quo (using your Phase 3 drafts), your colleagues will already trust that you genuinely want their input because you showed them you listen first.

Finally, listening tours work great early in your tenure because people will still talk to you! The classic questions (from Watkins): What do you think of our existing strategy? What are the biggest challenges we face in the short term? What are the biggest opportunities we face? What resources could we leverage more effectively? How could we improve the way the team works together? They feel natural on your sixth day but awkward in your sixth month.

The peril of premature judgment

Judging slow—even after a solid listening tour—protects both you and the company from rash calls before you've built that essential trust and context. Jumping in with solutions before understanding the landscape can be disastrous, as the following story illustrates.

A friend of mine, VP Engineering at a startup, saw this firsthand. They were acquired, and a new Chief Product Officer was brought in two weeks after the deal closed. The new CPO, despite a successful track record elsewhere, arrived with "high confidence and low context." On day one, he started making sweeping changes and immediately applied his own playbooks for things like customer migration.

Initially, he had the CEO's backing to shake things up. However, this "pinballing between big decisions" without knowing which ones were truly critical or needed more time became a pattern. Five months in, the board fired him. This story is a stark reminder: good judgment is implicitly necessary to know which decisions are big and should be delayed. Good judgment starts with knowing which calls are big and which can wait.

Share

Getting to the “real work”

This 3/6/9 isn't easy, but it’s effective. Remember that bug-triage call I took over? By the end of week two, we’d tweaked the agenda, clarified roles, and it was finishing on time. Small win, but it unblocked engineering and made Tuesday mornings a little less dreaded. You build trust and authority through collaboration and contribution, not just talk. You learn faster by doing. You give immediate relief to your boss and colleagues. You avoid career-limiting early missteps and finish your first two weeks on an upswing.

The learning never stops. Ramping up is continual, but after you’ve stabilized the day‑to‑day, it’s your cue to start leading where the org should head next.

Michael Watkins notes you earn “the right to play” only after delivering early wins. That’s why the strategic layer comes only after you absorb operational load and bank trust. This order, doing then thinking/judging, stops you from making plans that don’t match reality while positioning you faster for future success.

Next up: Turn that hard-won context into a clear strategy and roadmap to align your org and empower your team.

How to Get Better at Strategy? (Will Larson)
Larson closes his forthcoming book on engineering strategy with a meta-strategy: write your own plan for getting better at strategy. He offers four pillars. Explore public artifacts (engineering blogs, company postmortems) but read between PR lines. Excavate private sources, “strategy archaeologists” inside your org and peer networks, then catalogue them in a personal repository. Practice without permission by drafting and debugging team-level strategies, even if you lack org-chart authority; lower the altitude until no one can stop you. Finally, operationalize the habit: track every strategy you read, write, or refine; review quarterly with a learning circle that’ll call your bluff if you coast. His refrain: you’re never “too busy” for strategy—if you haven’t written one in six months, face that you simply don’t value it. A tough-love roadmap for turning strategy from occasional deck into weekly craft. (link)

What Is Strategy? (and What It Isn’t) (Dan Olsen)
The most overused word in product gets a much-needed dusting off. Olsen distills three dictionary definitions into one line: “a plan based on consequential choices designed to achieve long-term success.” Then he sharpens the edges by contrast: vision inspires, mission explains purpose, slogans sell, but strategy means saying no. Good strategy commits to one path, precluding others; if you’re not rejecting ideas, you’re still at tactics. And while he borrows Bezos’s “one-way vs. two-way doors” to claim that strategy is a one-way door, I’m not sure that’s true. A useful primer for teams that keep shipping “roadmaps” nobody can actually kill. (link)

Subscribe now

How to Sequence Your Growth Squads (Elena Verna)
Verna argues most “growth” orgs fail before they start because they hire teams in the wrong order. Her rule of four: Activation → Monetization → Acquisition → Retention. Nail first value, then price it, then pour fuel on TOFU; otherwise, you’re “churn with extra steps.” She outlines squad charters, metrics, and when to spin up rogue teams like Growth Infra or Experimentation SWAT. Budget guidance: growth should hover at ~25 % of R&D once you hit $30 M ARR. If you’re lobbying for headcount, this article is basically your slide deck. (link)

The Cynical PM’s Prompt Playbook (Justin Williams)
Williams delivers a profane, hilarious field guide to “robot whispering” in 2025. Four techniques anchor the manifesto: Contextual prompting (treat prompts like UX specs), Persona prompting (make the model role-play Steve Jobs or your grumpiest customer), Step-by-step prompting (force LLMs to show their work), and the nuclear option: let AI fix your dog-shit prompts. Alongside, he drops rapid-fire hacks (politeness boosts accuracy 9 %, store prompts as swipe files, different models for different moods). Beneath the snark is a serious thesis: prompt design is the new UX layer, and product managers who can’t wield it will get lapped by “Chad from growth” high-fiving himself in Slack. (link)

Why Do We Do Blameless Incident Reviews? (Fred Hebert)
Hebert walks through the mechanics of a post‑incident “five‑whys” done without finger‑pointing, showing how teams that feel safe surface root causes faster and push code more boldly the next week. He bolts in the neuroscience (cortisol vs. learning), the cultural math (psych safety × frequency of change = shipping velocity), and a set of concrete facilitation tips you can steal for your next retro. My takeaway: blamelessness is less about warm fuzzies and more about protecting the feedback loop that keeps us competitive. (link)

How to Work Better with Product, as an Engineer (Gergely Orosz interviews Ebi Atawodi)
Ebi Atawodi—now Director of Product at YouTube Studio, formerly at Netflix & Uber—recounts how she and Gergely transformed a rocky PM/eng relationship at Uber into a high‑trust, high‑impact partnership. Tactics I loved: a quarterly “business scorecard” that tied every squad to revenue or cost metrics; “State of the Union” updates that let engineers see the why behind head‑count asks; and a rule that new PMs must earn trust before rewriting roadmaps. The thread running through the episode: product‑minded engineers out‑execute everyone else, and the fastest way to grow them is full transparency into how product gets funded. If you coach eng managers on cross‑functional trust, bookmark this. (link)

Subscribe now

Melissa Perri: Why AI Is a Terrible Strategist (Interview by Leah Tharin)
Perri argues most “add AI” mandates come from boardrooms chasing higher multiples, not from user pain. She recounts coaching a Series C team that burned $2 M on a Gen‑AI feature nobody adopted, and offers a litmus test: if the model’s outputs can’t meaningfully change customer behavior today, ship a slide deck instead. Clip-worthy quote: “Strategy is what you won’t ship—especially when the hype train is loud.” (link)

It’s Me, Hi. I’m the Vibe Coder. (Katie Parrott)
Forget the “everyone will be a developer” cliché. Parrott—writer, not engineer—shares how AI helped her build real tools not by learning to code, but by reimagining code as conversation. She frames “vibe coding” as a kind of applied domain intuition: a marketer fixing their own workflow, an ops lead spinning up an internal dashboard, a parent prototyping a family planner. The power isn’t technical, it’s contextual. It’s a good distillation of why I find these full-stack AI coding tools compelling. (link)

Politics (Rich Mironov)
Mironov says we call it “politics” when we’re bad at it. He reframes exec‑suite jockeying as core product leadership: translating roadmap impact into P&L language, merchandising wins so R&D isn’t short‑changed, and pre‑aligning CFO/Support/Marketing before the next “special” sales request lands. Coaching founders, I label this “managing up & across,” and this essay is a field manual. (link)

The Purpose of a Building Is How It Looks (Ralph Stefan Weir)
Glendinning chronicles the swing from utilitarian brutalism to today’s craft‑forward architecture, arguing beauty re‑emerges when artisans regain control from spreadsheet designers. Hard not to map his thesis onto software: frameworks & templates raised the floor, but differentiated products still come from opinionated craftspeople. Bonus inspiration for your next design‑system debate. (link)

How I Quit Shopping (Charlotte Cowles interviewing Ashlee Piper)
Piper’s “No New Things” experiment started as a 30‑day detox, morphed into two years, erased $22k of debt, and rewired her dopamine loop. Beyond personal finance, the piece is a mini‑case study in habit design—urges last 2‑7 minutes; add friction; replace with a quick win. A nice counterpoint to the “growth at all costs” mindset. (link)

Top 5 Things Marketers Should Know About Engineering (Justin)
Good GTM leaders translate both ways. Justin lists five tech basics—data models, deploy flows, internal no-code tools, infra 101, and technical SEO—and reminds us that product & marketing execs must advocate for engineering’s realities to the rest of the org. (link)

Wharton Blueprint for Effective AI Chatbots (Thomas McKinlay)
McKinlay—author of the “Science Says” marketing series—teams with Wharton to turn 100+ peer-reviewed findings into chatbot do’s & don’ts. Perfect reading while every GTM team races to bolt AI onto the funnel. (link)

Subscribe now

AI Side Effect: Human Scope Creep (Jim Morris)
Give ChatGPT a simple idea, and you’ll get a 10-second spec—then watch you bloat it. Morris shows how AI accelerates ideation so fast that we skip MVP discipline, turning specs into Franken-products. Experience it for yourself next time you’re vibe coding. And remember that product sense and real user validation should still gate what ships. (link)

A Response to Sam Lessin’s 2025 Update (Gil Dibner)
I’d been meaning to reflect on Lessin’s “VC factory is dead” post—glad Gil beat me to it. He calls today’s funding game a messy “regatta,” agrees AI commoditizes plain-vanilla SaaS, and tempers the “software is worthless” hot-take. For context, here’s Lessin’s original. (link)

At the top of everyone's first-time manager checklist should be “set up 1:1s.” When done well, your 1:1s are how you build a productive and rewarding management relationship. But what does it mean to do 1:1s well?

When I was a young manager, I knew 1:1s were valuable, but I didn’t know how to make them work—sometimes we'd run out of things to talk about after ten minutes, other times the meeting devolved into a complaint session. Often, they felt merely performative. That's why in this article, I present a straightforward and structured model for 1:1s, so you have a guide and don't feel like you need to flail like I did. This approach will be productive, easy to manage, and set you up for success.

Subscribe now

One note: this is a long document, there are lots of details, and might be overwhelming. So here’s the tl;dr: Having a mediocre 1:1 is better than not having 1:1s at all. And ultimately you, as the manager, are responsible for your direct reports, even when you’ve given them work.

What are 1:1s, and why are they foundational?

Skip this section if you don’t need to be convinced!

When we talk about 1:1s, we mean the recurring meetings that a manager has with the people who report to them. These aren't status updates; they are dedicated time to benefit your direct reports. I consider them one of the most powerful tools a manager has, and neglecting them or doing them poorly isn't just missing a meeting; it's failing at a fundamental practice that is essential for successful leadership.

Why invest this time? Having and protecting this regular meeting time boosts engagement and reduces regrettable attrition. They build trust and psychological safety; committing to a regular schedule and protecting that time fosters an environment where reports feel secure sharing challenges and aspirations openly. This dedicated time signals the value you place on their individual growth and perspective.

Because the meeting is routine, it lowers the risk of bringing up hard subjects. Frequent check-ins help keep small problems small, allowing you to address issues before they escalate—e.g., weekly meetings offer 4x the opportunities of monthly ones. This regular cadence also provides an affordance for difficult conversations like feedback or career concerns, making them less awkward. Ultimately, 1:1s are the primary venue to drive performance and development through coaching, feedback, and goal alignment, and they make formal performance reviews easier by promoting alignment and addressing issues proactively.

Keep in mind that these regular check-ins aren’t the only kind. You might hear references to a skip-level 1:1 (a meeting with your boss’s boss), 1:1s tied to performance reviews or as part of a PIP (performance improvement plan), an onboarding meeting, a stay interview, an exit interview, or something else. This article focuses on the regular, recurring 1:1 between a manager and their direct report.

Setting up your 1:1s: The logistics

Getting the logistics right demonstrates the value you place on these meetings.

• Frequency: While optimal frequency is debated, I think weekly 1:1s are best for newer or junior employees and new managers. While bi-weekly is cited as a viable alternative for more experienced reports or if weekly isn't practical, and they might be tempting if your schedule is already tight, weekly provides more opportunities for both you and your report to practice the skills of giving and receiving feedback, building rapport, and discussing development. Plus, issues are surfaced much faster.

• Duration: I like starting with 30 minutes because it forces me to be better focused and because I hate saying, “Let me give these 20 minutes back” when we run out of things to say. However, some argue it’s insufficient for deep conversations, so pay close attention: if you consistently run out of time or feel rushed covering topics like career development, consider extending to 45 or 60 minutes. But don’t let the 1:1 devolve into a tactical working session – it should retain its focus on the employee's needs, feedback, and growth.

• Scheduling: Look for a spot on your weekly calendar using a recurring invite. I like to schedule my 1:1s early in the week because those time slots seem easier to protect and to start the week off well. Be careful not to set the meeting too early or too late, as that makes it more likely to be bumped by family or non-work needs, and consistency is non-negotiable. Every time I’ve canceled a 1:1, I could see a bit of our relationship dying. If you must cancel, reschedule immediately, don't just blow it off. This consistency signals reliability and the meeting’s significance more than almost anything else.

• Location (prioritize privacy and preference): As a baseline, find a consistent place where you can both speak freely without being overheard – a conference room, a huddle room, or ensure you both have privacy if remote. Check with your report about their preference; some prefer standard offices/conference rooms, others prefer occasional walks or coffee shops, but not everyone does. Personally, I like walking meetings, either in person or over the phone, as they both feel more emotionally intimate and can reduce tension.

Prework and agenda

I prefer that my reports do the physical pre-work, not just because I’m stretched, stressed, and lazy. This is the first opportunity to illustrate the difference between ownership (theirs) and responsibility (yours). I ask reports to write a “weekly wrap-up email” (template), ideally on Friday, covering three areas: current priorities (for alignment), blockers (where they need help), and what’s on their mind (for broader topics). Critically, you need to read their email before the meeting and come prepared to discuss the details.

Let me say that again: You, the manager, need to read their email before the meeting and come prepared to discuss the details.

Alternatively, many use a shared agenda document (like a running Google Doc) where both manager and report add topics beforehand, with the employee driving the agenda. This enhances transparency. You can search for highly detailed templates (covering OKRs, KPIs, etc.), but these are overkill initially. A potential caution with adding detailed agenda items in writing beforehand is that text lacks tone, and seeing a sensitive topic appear without context causes unnecessary anxiety.

Whether using a wrap-up email, a shared doc, or another method, the key is having some pre-work process so both participants arrive ready for a focused conversation.

Does this feel overwhelming? Start with my suggested structure, pay attention to the quality of the meetings, and adapt as you go.

How to run the 1:1: A recommended flow

While different structures exist (more on that below), here’s a practical flow focusing on the employee's input while making sure key areas are covered. The subtle tension is that even though you’re asking them to “own” the meeting, you’re still the manager and you’re still ultimately responsible for the meeting, the relationship, and their performance.

• Set the tone: Start by being fully present and minimizing distractions (more below). Check your own emotional state and try to set aside any negative energy, as your mood is contagious. Begin with a brief non-work chat, share a win, or express appreciation to build rapport and safety.

• Review priorities and alignment: Start by discussing the priorities your report identified in their pre-work. Is their focus aligned with team and company goals? Is there any new information or context you possess that would change their priorities? If you haven’t shared relevant context earlier that would have impacted their plans, acknowledge that and apologize – it builds trust. The goal here is mutual understanding and alignment.

• Address blockers: Move on to the blockers they’ve identified. Acknowledge each one clearly so they know you've heard it. For each blocker, determine if you can remove it for them (if so, commit to doing it and always follow through) or if it’s something they can solve with guidance. If the latter, coach them through it, asking questions to help them find a solution they ideally control. It’s also good practice to briefly review blockers mentioned in the previous 1:1 to check if they’re resolved or need further action, promoting accountability.

• Discuss “what’s on my mind” (and guide broader topics): This is where your report shares topics beyond immediate tasks. Let them lead. However, your role as a manager is also to teach them the breadth of things they should be thinking about for their role and career. Even if they don’t bring them up, make sure you’re regularly weaving in conversations about:

  • Career development: Their long-term goals and aspirations, as well as promotions and new responsibilities.

  • Skills progression: Where are their growth edges? What opportunities exist to learn?

  • Relationships: How are things going with peers, the cross-functional team, and the broader organization?

  • Ideas and innovation: Solicit their ideas for improving products, processes, or team culture.

  • Feedback: Both giving feedback to them and explicitly asking for feedback on your performance using direct questions (“What can I do better?”) or frameworks like “I like, I wish, What if?”

  • Well-being: Check in on their job satisfaction and work-life balance. Consider using "magic questions" about how they feel (1-5 scale) about work life, personal life, WFH, the company, the team, and working with you. It’s okay for them to drive the specifics each week, but you need to confirm these vital areas aren’t consistently missed. Guide the conversation by asking open-ended questions.

• Quick retrospective check (if needed): Was there a specific event, project milestone, or interaction from the past week that warrants reflection? Decide if a brief retrospective (“How do you think X went?” “What could we learn from Y?”) fits within this meeting or if it warrants a dedicated session. This isn’t a working meeting!

• Wrap up with action items: Before ending, clearly summarize takeaways and define action items for both of you: who does what by when.

A simpler way to think about this: Your 1:1 time is ideal for that work which is important but not urgent.

Other structured frameworks

While the flow above provides a practical approach, being aware of different formal structures is helpful. Flexibility is key; don't let a rigid structure kill a valuable conversation.

• Manager Tools 10/10/10: A simple, popular model for a 30-minute meeting: 10 minutes for the employee's topics, 10 minutes for the manager's topics, 10 minutes for the future (career development, follow-up). Ensures balanced coverage. I love the balance but struggle with the rigid structure.

• Time-based: Icebreaker (5 min), review past actions (5 min), employee-led discussion (15 min), feedback/coaching (10 min), next steps/actions (5 min). Offers a concrete alternative. Same as above, the rigid structure feels like something from an HR handbook rather than a human connection.

• Bill Campbell's structure: Focused on 1) Performance against KPIs/goals, 2) Relationships with peer teams, 3) Leadership/Management development, and 4) Innovation/Ideas. More strategic, suited for longer meetings. While it’s tough for me to disagree with Silicon Valley’s greatest coach, this one never felt right at an early-stage startup.

The manager’s role during the 1:1

• Eliminate distractions: Give your report your undivided attention. This means closing Slack, email, and distracting browser tabs. Turn off notifications on your computer and phone. Make eye contact. Being present signals respect and the value of the conversation.

• Master active listening: Your goal should be to listen far more than you talk. Aim for the report to speak 50-90% of the time. Focus on understanding their perspective, not just waiting for your turn to speak. Feeling heard is fundamental to psychological safety.

• Employ powerful questioning: Use open-ended questions (“What,” “How,” “Tell me about...”) to encourage reflection and deeper discussion. Avoid leading questions or ones that elicit simple yes/no answers. Good questions explore context ("What's challenging about that?"), promote learning ("What did you learn?"), empower ("What does your ideal outcome look like?"), and support growth ("How would you like to develop?").

• Adopt a coaching mindset: Shift from directing and fixing to guiding. Help your report think through problems and develop their own solutions, as they often have more context. Ask questions like “What have you tried so far?” or “What options are you considering?” But, while you should resist the urge to jump in with your answer immediately, making them guess isn’t helpful either.

1:1s in the bigger picture

They aren't the only place where feedback happens. Think of it like a pyramid:

1. Base: A culture of continuous, immediate feedback (both praise and constructive criticism) given in the moment, as things happen. I agree with Radical Candor that feedback should be immediate and not saved for 1:1s.

2. Middle layers: Regular weekly 1:1s (you are here!) and team meetings (for alignment, group problem-solving).

3. Higher layers: Formal performance reviews and quarterly planning (less frequent, more structured assessments and goal setting).

4. Peak: Actual individual and organizational outcomes (company strategy, actual results, OKRs met).

Your weekly 1:1s are a critical middle layer, supporting and being supported by both continuous feedback and more formal processes.

Common challenges & mistakes

Even with good intentions, you face bumps or fall into common traps.

1. Cancellations/unpreparedness: As the manager, model commitment. Avoid cancelling. If your report is unprepared or cancels often, use the 1:1 to discuss why. Is the meeting not valuable? Is trust lacking? Address the root cause.

2. Dominating the conversation: Remember to listen more than you talk. For me, silence feels wildly uncomfortable, so if my report isn’t talking, I’ll tend to fill the gap. Don’t be like me! If you’re staying quiet, you’re giving them space to talk.

3. Using it only for status updates: Handle tactical updates asynchronously or at team meetings. Use 1:1 time for richer conversations.

4. Focusing only on tasks: Employees need feedback on skills and career growth, not just task completion.

5. Different communication styles: Adapt your approach. For quieter reports, focus on building safety, ask open-ended questions about their experience/feelings, and be patient. For talkative reports, use the agenda to gently guide the conversation back on track while ensuring they feel heard.

6. Difficult conversations: Use the private 1:1 setting to address performance concerns or interpersonal issues promptly. Choose your battles wisely, focus on behaviors and solutions you can control. Prepare talking points and use “I feel” statements. If there's been conflict, use the next 1:1 to repair and clarify. When a report is venting or threatening to quit, your role in the moment may be just to listen (but don’t forget to take this promptly to your manager).

7. Absence of difficult conversations: The opposite is also true. Work is hard and stressful, and if you’re not having hard, stressful conversations, your 1:1 is just operating on the surface. There are lots of ways to build psychological safety, but my favorite trick is to change the power imbalance. For example, try scheduling some 1:2 or 1:3 meetings with a few folks on your team (take them for lunch) and see if they open up.

8. Not following up: If you agree on action items, confirm they happen. Dropped balls erode trust.

9. Not asking for feedback on the 1:1s themselves: How can you improve the meetings if you don’t know what’s working? If you do nothing else, do this. It’s a “one weird trick” for being a better manager.

But all that said, remember the tl;dr: Your 1:1s don’t need to be perfect, but you still need to hold them. So, if the only way to get engagement is spending time on updates or tactical work? Start there.

Share

Are your 1:1s working?

How do you tell if this significant time investment is paying off? Look for these signs:

• Direct report engagement: Are they actively contributing to the agenda? Do they come prepared? Do they seem open and willing to discuss challenges?

• Reduced “surprises”: Are you hearing about problems or roadblocks sooner?

• Improved performance & growth: Are you seeing progress in their skills and contributions? Are they addressing feedback? Are they moving towards their career goals?

• Increased trust and candor: Do they bring difficult topics or constructive criticism to you?

• Action items get done: Are commitments made during the 1:1 followed through on (by both parties)?

• They don't cancel (often): Reschedules happen, but frequent cancellations warrant a conversation.

• Direct feedback: Ask them! Periodically check in: "How are these 1:1s working for you?" or "Is there anything we could change about our 1:1s to make them more helpful?"

As a product manager, good 1:1s feel like good product market fit: Are we excited for the meeting? Is the structure and cadence pulling in increasing value? Would we both be disappointed if we could never have them again

Making your 1:1s even better over time

Your 1:1s shouldn't be static; they should evolve as your relationship with your report grows and their needs change. Periodically review your process. The best way to do this? Ask your team members directly for feedback on the 1:1s themselves. You could ask after a meeting, during a skip-level, or even use an anonymous survey. Ask: What's going well? What's not? What ideas do you have for improvement? Be open to trying new approaches based on their input.

Conclusion: Practice makes progress

Effective 1:1s are more than just meetings; they are a primary arena for practicing and honing essential management skills and for developing the relationship between you and your direct reports. They require consistent effort, but the payoff in trust, engagement, and performance is immense.

1. Commit to consistency: Schedule weekly 30-minute 1:1s and treat that time as sacred. Reschedule immediately if you absolutely must cancel.

2. Prepare and empower: Establish a pre-work routine (like a wrap-up email or shared agenda) that encourages your report to own their part of the conversation.

3. Structure for focus: Use a simple flow – check-in, priorities, blockers, broader topics, action items – to guide the discussion.

4. Be present and coach: Eliminate distractions, listen actively (aim for 80% listening), ask powerful open-ended questions, and guide rather than direct.

5. Follow through: Document and complete action items reliably.

6. Seek feedback: Regularly ask your report how the 1:1s can be improved.

Great 1:1s take ongoing practice. By focusing on these actionable steps, it’s more than just a procedural step; you're actively investing in your people, building stronger relationships, and becoming a more impactful leader, one conversation at a time.

Engineering Success in a Technical Startup (Gil Dibner)
Why deeply technical founders stall at $10 M ARR: most are “sleepwalkers” who underestimate GTM. Dibner maps the journey from sleepwalker → humble learner → all-rounder and says the unlock is a top-1 % sales-DNA transfusion. Treat GTM as just another engineering problem—then iterate, hire, and measure until it hums. (link)

The AI Quality Coup (Julie Zhuo)
AI is now table-stakes; when anyone can spin up a “Ghibli-fied” selfie, quality shifts to what’s still rare—story, craft, proprietary feedback loops, and first-mover use cases. Zhuo argues that teams who treat AI like oxygen—but chase freshness, not imitation—will keep the edge. A reminder that in 2025, differentiation starts after the model. (link)

Share

Demystifying Platform Product Management (Ibrahim Bashir & Waqas Sheikh)
Platform PMs rarely get the spotlight, yet every technical product runs on the plumbing they design. Bashir and Sheikh unpack the role—capabilities, experience, extensibility, economics—and explain why platform PMs must balance portfolio trade-offs, speak both code and commerce, and mediate org-wide priorities. In an AI-everywhere world, their behind-the-scenes craft is as critical as any outward-facing roadmap. (link)

Your Product Team Doesn’t Need a “North Star Metric” (Ravi Mehta)
I’ve been on a strategy kick lately, so Mehta’s take felt like validation: reducing strategy to one KPI is a trap. He proposes a North Star Strategy—a succinct narrative of the outcome you’re chasing, backed by a few context-specific metrics. From Apple’s iPhone leap to Tinder’s “good-match” dilemma, he shows vision > vanity numbers. (link)

Subscribe now

Make OKRs Drive Decisions, Not Spreadsheets (Tim Herbig)
If your team breathes a sigh of relief after quarterly OKR theater, you’ve got “Alibi Progress.” Herbig reframes OKRs as a product: a decision tool that links daily work to strategy in real time. That means teams author their own OKRs, favor leading metrics that surface risk fast, and check progress continually, not just at kickoff and post-mortem. When OKRs stop guiding prioritization, they’re noise. (link)

Most Consumer Software Doesn’t Fail on Product. It Fails on Monetization. (Monica Villar)
As I like to say, “Price is your most important product feature.” Villar flips the LTV obsession in consumer apps: there are no whales, so growth comes from converting the users you already have. Lower CAC by treating monetization as a first‑class product surface: strategic, iterative, and tested. She debunks the twin myths of “just raise LTV” and “optimize top‑funnel,” then offers a playbook for nudging more people from $0 → something more than $0 with regret‑free, loop‑reinforcing pricing paths. Breakout apps will win by iterating on monetization as relentlessly as on features or distribution. About 6 min. (link)

Stop messing up your Growth‑leader hiring (Adam Fishman)
Fishman dismantles the “hire a unicorn VP Growth right after Seed” trope. He maps the four failure modes (timing, expertise mismatch, miracle‑seeking, org alignment) and offers a stage‑by‑stage rubric: founder‑led → hands‑on architect → functional exec. FWIW, this closely mirrors what Peter Kazanjy recommends for sales leadership. If you’re between Seed and Series A, bookmark it. About 10 min. (link)

Share

AI Monetization: how to price what you’ve built (Janna Bastow)
A thorough menu of direct vs. indirect AI revenue plays—add‑ons, standalone SKUs, bundled lifts—and a candid warning that “bundling works now, but won’t forever.” Includes real‑world cost/usage benchmarks and a mini‑decision tree. 17 min. (link)

How Life360 nailed its ICP and 5×‑ed revenue (Kunal Thadani & Gaurav Hardikar)
Great case study of a consumer app pivoting from “location sharing” to “family safety.” Four tactical plays—tiered memberships, free crash‑detection hook, reframing competitors, and kid‑tracker hardware—show how tightening the ICP unlocked ARPU and a 2024 Nasdaq listing. About 12 min. (link)

Does every marketing channel actually suck right now? (Emily Kramer, MKT1)
This is the kind of back-and-forth we used to see on Twitter! Kramer’s spirited rebuttal to Andrew Chen’s “every channel sucks” rant. She walks channel‑by‑channel with what’s still working, argues that “little channels” scale when powered by community & creator ecosystems, and reminds us that product and differentiated marketing win together. 15 min. (link)

Bonus! A blast from last year that came up on a client call when discussing, what else, a PM deciding between multiple GTM opportunities:

The power of paper models in decision‑making (me)
A back‑of‑the‑napkin model beats analysis paralysis when you’re sizing a GTM bet. About 5 min. (link)

Engineering-Enabled Velocity (Aviv Ben-Yosef)
This dives into the idea that your engineering organization can significantly accelerate your product development when structured and nurtured correctly. The author emphasizes that things like well-defined ownership, streamlined processes, and a focus on continuous improvement aren't just about building software but also about building speed. He also introduces the idea of “tech capital,” the underlying engineering strength and efficiency that allows a company to innovate and iterate quickly. He proposes explicit permission to innovate, cross-company insights, deploying advanced tools, and being metrics-driven as four concrete steps to develop that capacity. Approximately 8 minutes. (link)

Steps to build an engineering strategy (Will Larson)
This piece provides a structured way to think about the often nebulous concept of engineering strategy. The author breaks it down into five key steps: explore, diagnose, refine, policy, and operation. It's a helpful framework for ensuring that your engineering efforts are aligned with your broader business goals and aren't just a collection of tactical decisions. Note that setting engineering strategy is very much like setting product and even company strategy. Your engineering team needs to be engaged with and aligned on company outcomes. Approximately 10 minutes. (link)

Subscribe now

There is no Vibe Engineering (Sergey Tselovalnikov)
This article draws a clear distinction between simply “coding” and the more comprehensive discipline of "engineering." It argues against the notion of "vibe engineering," suggesting that while coding might involve a degree of intuition or personal style, true engineering demands a more systematic and rigorous approach. The author emphasizes the need for well-defined processes, clear specifications, and a focus on building reliable and maintainable systems, which goes beyond just writing lines of code. This perspective highlights that while the act of coding is a component, the broader practice of engineering involves critical thinking, planning, and a commitment to quality and sustainability in the long run. Approximately 5 minutes. (link)

Vibe coding and the junior developer dilemma (Andreas Creten)
This article tackles a really interesting dynamic often seen in early-stage tech companies: the pressure for junior developers to contribute "production-ready" code at a rapid pace. It highlights the concept of “vibe coding,” where the emphasis on speed and output can sometimes overshadow the crucial aspects of learning, mentorship, and writing robust, maintainable code. The author argues that while velocity is important, creating an environment where junior engineers feel supported in their growth and aren't just chasing the “vibe” of constant output ultimately leads to a stronger and more sustainable engineering team in the long run. It’s a valuable perspective on balancing immediate needs with long-term team development. Approximately 2 minutes. (link)

The Tension of Early Product Communication (Adam Fishman)
This article provides a practical framework for managing internal communication at each stage of product development, strategically timing communication to stakeholders and gradually broadening from individual conversations to larger groups to control narratives and expectations. It addresses a common friction point many founders and product leaders encounter: keeping teams informed without overwhelming or misaligning them too soon. I particularly appreciated the recommendation to use smaller-scale interactions early on to gather focused feedback and refine your messaging before engaging the wider audience, sort of like an MVP. About 8 minutes. (link)

The definitive guide to mastering product sense interviews (Ben Erez)
It seems somewhere between silly and redundant to link to a post from Lenny’s Newsletter, but make sure you read this one. I don’t like product sense interviews (the fact that the author can teach a course that improves your ability to pass the interview is all you need to know), but if you’re planning to apply to top tech companies, this is a skill you need to master. The guide outlines five key areas: clear communication, product motivation, segmentation, problem identification, and solution development, providing actionable strategies for each. I even found some solid advice about communication that I’ll be bringing to my work. About 15 minutes. (link)

Subscribe now

Better Conversations over Perfect Docs (Josh Herzig-Marx, me!)
Is it ok to post something I wrote? PRDs in particular, and written documentation in general, are terrible ways to communicate with your engineers. What you need are better conversations earlier in the process. This article offers a few concrete tools for promoting these better conversations. About 5 minutes. (link)

How many times have you been caught in this cycle: write an amazing PRD, hand it off to engineering, but something mediocre ships? We shoot for the “perfect” requirements document, the flawless spec, thinking if we just nail the details, the right product will magically appear. But we’re wrong. Documents like specs and PRDs are terrible ways to communicate and build products.

I’m imagining a canonical product development process: Goal/strategy selection → Problem/opportunity identification → Opportunity selection → Solution identification → Solution selection → Design → Development → Deploy → Release.

I believe we need to prioritize conversations over documentation. What if we used artifacts not as replacements for talking but as springboards for it? Often, the most successful teams aren't the ones with the best docs but the best conversation at every stage.

Subscribe now

Almost 10 years ago, I was brought into a small tech company as their first PM and product leader. That’s right: no formal product management, but somehow, they’d amassed 10 million MAUs. The first time I visited the office, I saw them practicing what I’ve come to call “prairie dog product management.” Someone would have an idea, they’d stand up and just say it out loud. Another head would pop up over the cubicle wall, and they’d talk. Because everyone—engineers, QA, designers, and CSMs—understood the company goals and strategy and all knew the users well, they had a quick conversation. They poked holes in the idea, examined tradeoffs, and tossed around ideas for implementation. Sometimes they decided to build it and sometimes they didn’t but the process was easy and fast. If there was something to talk about, they’d just have a conversation.

While that particular model had plenty of flaws (they struggled to build big things, and when they did make big bets, they often were poorly tested in advance), that image has stuck with me as a model for deep engagement between Product and Engineering.

Let's take a step back and rethink the purpose of documentation, especially if you're a PM in tech. It's way too easy to fall into the trap of viewing our artifacts as the primary deliverables of product management. Common examples include:

• The classic Product Requirements Document (PRD), often trying to cram in everything from Problem/opportunity identification through Solution selection.

• Google Docs stuffed with specs and notes.

• Linear/Jira tickets detailing user stories and tasks.

• Miro/FigJam boards from brainstorming or mapping sessions.

• Clickable prototypes showing flows.

But the real goal shouldn't just be to dump information into these artifacts passively. Good artifacts provide affordances for better, earlier conversations between engineering, design, and other stakeholders. Discussing complex trade-offs during Opportunity selection or Solution selection – like hashing out different login options (username/password vs. 2FA vs. passwordless) – needs an honest back-and-forth, sparked by the PRD or spec, tapping into everyone's expertise. That doc, no matter how detailed, will fail if it’s seen as the final product.

Shooting for “perfect” docs before talking to engineers isn't just flawed, it can blow up in your face, especially at handoffs like between Solution selection and Design. Part of the problem is just the nature of written communication itself. As Jeff Patton frequently points out in his book User Story Mapping, documents stink at creating real shared understanding. Think about it:

• Written words are static; they lack the immediate give-and-take of conversation.

• You lose all the vital tone and body language cues.

• It's incredibly easy to misinterpret things, with different people walking away thinking completely different things.

Do you remember the first time you read Harry Potter? In your head, you pictured Harry, Hermione, Dumbledore, the cubby under the stairs, the sorting hat…all of it. Those books have incredibly vivid, descriptive, evocative writing. But I can guarantee the picture I saw inside of my head differed substantially from the one inside yours.

That spells trouble down the line during Development or Deploy. Writing more doesn't guarantee everyone’s on the same page. You risk falling into the trap of believing the artifact itself ensures alignment across the whole lifecycle, when it often fails to connect the dots between minds. Instead of endlessly polishing that doc in isolation, use it – warts and all – to spark the crucial, high-quality conversations needed to build actual shared understanding early and often, from Goal selection to Release planning.

Who needs to be in these talks? Your engineers, especially as the team dives into Design and Development. They usually have the deepest technical expertise in implementation. Instead of PMs dictating the tech specifics during these later phases, tap into their wisdom and experience. Get them directly involved in figuring out the best way to do it. Some teams might debate feature trade-offs when building a login system (security vs. performance vs. user acceptance) during the Design stage. At Google, I saw teams hiring designers to develop and film evocative product advertisements to clarify product vision before Development kicked off. One of my clients, a graphic designer, made a comic strip. There are countless ways to engage the entire team.

It pays enormous dividends to pull engineers “leftward” in the process, looping them in much earlier – starting from Problem/opportunity identification through Opportunity selection and Solution identification/selection. Looping them into talks about the company's vision (Goal/strategy selection), market needs, and user requirements during these formative stages lets you tap into their diverse experiences. Think about that login options example, but even earlier, during Solution identification, exploring choices like these together surfaces critical trade-offs only engineers might fully grasp before a direction is locked in:

• Username/password

• Two-factor authentication (2FA)

• Passwordless login (like magic links or SMS/email codes)

• Federated login (Apple, Google, Microsoft)

Using narrative tools like story mapping during Solution selection also helps engineers contribute to the “what” by questioning assumptions and shaping the MVP scope.

Subscribe now

Getting engineers involved early means facing a reality they live every day: managing complex trade-offs. And this isn't just one phase; senior devs do this constantly, from weighing different approaches during Solution identification to making tough calls in Development. Figuring out the right balance – maybe between a quick-and-dirty solution versus a 'military-grade' one during Solution selection, or dealing with tight timeline pressures during Design – doesn't happen in a vacuum. It takes real conversation, backed by solid technical understanding, to navigate these choices effectively throughout the middle stages of the lifecycle. Oftentimes, the result is a desperate DM on Slack and the realization that until you answer their question, engineering has slowed to a halt.

Naturally, none of this works, at any stage from Goal selection to Release, if people don't feel safe speaking up. If you're a leader, you've got to be hyper-aware of your impact. Your team reads your cues like kids read their parents' moods. Tiny things can instantly shut down valuable questions or pushback, whether you're brainstorming during Problem identification or debugging during Deploy. Watch out for things like:

• A thoughtless word that dismisses an idea.

• A tone suggesting impatience.

• Negative body language (eye-rolling, checking your watch, checking your email – we see you!).

Making an environment where people feel genuinely safe asking questions, challenging assumptions, and voicing concerns is absolutely non-negotiable for real collaboration across the entire product development process.

With a safe space established, how do you actually drive these discussions, particularly during Solution identification, Solution selection, and Design? My favorite model is user story mapping. Fantastic technique. Imagine your team is building a tool to help with “waking up and going to the office” – breaking down a process invites interaction as the team defines the solution. Consider steps like:

• Alarm goes off

• Stand up

• Shower

• Get dressed

And the clarifying questions that pop up:

• When does shaving happen?

• Breakfast at home or grab something on the way?

• How's coffee getting made?

You can actually represent this with stickies on a wall (or the equivalent online). And when an engineer jumps in with, “Wait, not everyone drives!” it sparks a crucial discussion. Maybe you refine the Ideal Customer Profile (ICP) or simplify the Minimum Viable Product (MVP) during Solution selection or early Design. That's collaboration in action.

Story mapping clicks partly because it leverages the power of stories, which are gold in early stages like Problem/opportunity identification through Solution selection. We're just wired for stories. Instead of dry requirements during Solution identification, framing the work with a narrative – detailing the user (hero), their world (setting), and their struggles (obstacles) – makes the “why” way more relatable. Picturing that person rushing out the door, trying to decide if they’ll get coffee at work or on the way, adds clarity to everyone’s thinking.

Stories are great, but relying only on words can lead to everyone having a different movie playing in their head – think back to the Harry Potter analogy. The moment we all saw the movies, we suddenly shared an identical picture of Voldemort. That's why adding visuals is so crucial, particularly from Solution identification through Design. A visual artifact, like that fake Google ad concept or hand-drawn comic strip, gives everyone a shared picture that:

• Clarifies the product vision during Solution selection.

• Gets everyone on the same page heading into Design.

• Sparks better, more specific questions before Development begins.

How do you bake this conversational approach into your process, especially bridging that critical gap between Design and Development? One powerful shift? Try engineer-led user story creation. Instead of the PM slaving over every detail after Solution selection or Design, the PM provides just a high-level epic (here’s my template):

• A user-centric narrative (Jobs-to-be-Done, hero/goal/obstacles, whatever works for you).

• Key non-functional requirements.

• Placeholders for or links to mockups and prototypes.

Then let the engineers break down that epic into specific user stories as they plan Development. They usually have the best gut feel for how to slice up the work logically, and this process inherently delivers key benefits:

• It forces questions to smoke out ambiguity.

• It creates natural feedback loops for alignment before coding starts.

The job isn’t writing PRDs. You don’t get credit for specs, and your company will never be acquired for its JIRA backlog. But I believe that if you replace written artifacts with better conversations, earlier, you’re much more likely to build a product and company that are truly valuable.

Want to learn more?

The best book on the topic is User Story Mapping, by Jeff Patton. You can find links to the book, presentations, and articles at https://jpattonassociates.com/story-mapping/.

My example product, something to help with getting up and getting to work, was taken from a presentation I give, “User Story Mapping or Partnering with your Devs," which you can find here.

The Cybernetic Teammate (Ethan Mollick)
This author argues that AI tools are best used as “cybernetic teammates”. It explores how these tools can amplify our abilities, boosting productivity and efficiency. It concludes that mastering the integration of AI into our workflows and teams is crucial for navigating the future of work. The conclusion result from academic research and an experiment at P&G. AI’s potential isn't just about automation; it's about forming a true partnership between humans and computers. About 7 minutes. (link)

What if an AI Was Your Best Customer? (Gil Dibner)
If you’ve been vibe coding (sigh), you’ve probably had your AI software engineer suggest integration with third-party products, and apparently, some companies are considering building products to be consumed by gen AI. This article asks three fundamental and unanswered questions: How widespread is this already? What does it mean to build a tool to optimize its selection by an AI? Is this a new business model or just a new target customer? About 9 minutes. (link)

Subscribe now

High Agency (George Mack)
I don’t agree with everything in this article, but it’s getting enough airtime, and you should read it. “High agency” is described as proactively shaping outcomes, which is vital for founders and product managers. The article concludes that success often hinges on rejecting default paths, actively questioning constraints, and resourcefully finding non-obvious solutions to achieve ambitious goals. A key insight is how frequently perceived hard limitations are merely untested assumptions or negotiable points within a system waiting to be understood and leveraged. About 35 minutes. (link)

Bonus! Here’s a piece of mine from last year that came up on a client call:

Building an effective employee referral program (me)
Referral programs directly impact the quality and speed of critical hires, and effective programs require more than just cash incentives. Clear processes, consistent communication, and meaningful recognition are what motivate participation. One key suggestion: treat the referring employee with thoughtfulness and respect throughout the process—e.g., providing timely updates and feedback—to ensure their continued engagement and the program's long-term success. About 4 minutes. (link)