LinkedIn Outreach Assistant

Freeform draft

Posted v3 · 25 Mar 2026

I once sat in a roadmap review where every initiative had a clear owner, a rationale, and a confidence score. It was the most organized fiction I'd ever seen.

Nobody lied. That's the part that took me a while to understand. Every decision had been made for real reasons, documented with real data, reviewed by real smart people. But the roadmap wasn't a plan. It was a record of what the team had already decided to believe, dressed up in quarters and color codes.

The psychological work happening beneath that spreadsheet is political, not predictive. Teams rationalize past commitments. Leaders protect their bets. The roadmap absorbs all of this and converts it into something that looks like strategy.

And the accountability question everybody asks, "did we ship what we planned?", is the wrong question. It lets the roadmap evaluate itself.

The harder question is whether anyone measured what was supposed to change when the thing shipped, and whether the next decision was shaped by that answer. Most organizations cannot answer yes to both. Not because people are lazy or dishonest, but because the system rewards the appearance of deliberation over the practice of it.

Right now, with teams shrinking and initiatives getting cut, this matters more than usual. Cutting the roadmap in half doesn't solve the problem if you keep the same accountability model. You'll just rationalize fewer things more confidently.

A plan that can't be falsified isn't a plan. It's a story you agreed to tell each other.

I keep wondering how many current-quarter priorities would survive if teams had to show the behavioral change the last one actually produced before adding the next one.

Freeform draft

Revised v2 · 25 Mar 2026

I once sat in a roadmap review where every item had a "strategic rationale" written underneath it. Twelve initiatives. Twelve rationales. Every single one sounded airtight.

We shipped maybe four of them. The rationales didn't predict that. They just made the other eight feel intentional while they were on the slide.

That's what roadmaps actually do. Not plan the future. Make the present feel deliberate. There's a difference, and most teams never look at it directly because looking at it directly means admitting that a lot of product strategy is political negotiation dressed up in outcome language.

The accountability question most teams ask is "did we execute the plan?" But the plan was already a story you told yourself to justify decisions you'd already half-made. Asking whether you followed it is just checking whether your rationalization held.

The harder question is whether you measured anything that would have told you the decision was wrong, and whether you were actually willing to adjust when it did.

That's where it falls apart. Not at the roadmap level. At the measurement and adjustment level, which is unglamorous and mostly invisible and doesn't produce a slide anyone wants to present to the board.

I keep wondering how many initiatives surviving right now in scaled-down teams are surviving because they have evidence, and how many are surviving because someone senior still believes in them and the roadmap gave that belief a professional vocabulary.

The plan didn't fail. The accountability structure around it was never real.

What would it take at your company to kill something that was already on the roadmap?

Freeform draft

Revised v1 · 25 Mar 2026

I once watched a quarterly roadmap review where the team spent 45 minutes explaining why everything that slipped was actually strategic. The features that shipped late had "uncovered deeper requirements." The ones killed mid-sprint had "validated a critical assumption." Every miss had a story, and every story made the team sound thoughtful.

That's when I started seeing roadmaps differently. They're not forecasts. They're post-hoc narratives dressed as plans, built to make the people in the room feel deliberate rather than reactive. The work of a roadmap isn't prediction. It's political. It's psychological. It's the organizational equivalent of a lawyer writing their own verdict before the trial starts.

The accountability question almost everyone asks is: did we follow the plan? That question is nearly useless. It measures commitment to a document, not quality of judgment. A team that follows a bad plan diligently is not performing well. They're just disciplined about being wrong.

The question that actually matters is harder to ask, especially when headcount is down and everyone is defending their patch: did we measure what we said would move, and did we change course when it didn't?

I keep getting stuck on why that question feels so threatening. I think it's because following the plan protects you. Measuring outcomes exposes you.

Right now, with companies cutting initiatives and forcing prioritization, the gap between those two questions is where a lot of damage is happening quietly.

What's the accountability norm on your team: the plan, or the outcome?

Freeform draft

Draft v2 · 12 Mar 2026

We hired a brilliant domain expert last year. Deep industry knowledge, twenty years in the field, exactly the profile we thought we needed.

She struggled for six months.

Not because she wasn't sharp. Because the specific knowledge we'd paid a premium for — the mental model she'd spent two decades building — kept getting invalidated by tools that could now generate in seconds what used to take weeks. The expertise wasn't wrong. It had just stopped being scarce.

The thing I keep getting stuck on is whether we were solving a real problem or just a familiar one. When everyone is racing to hire "experienced" engineers who know a specific stack deeply, someone should probably ask whether that stack knowledge is the constraint anymore. GPT-4 passed the bar exam. GitHub Copilot writes the boilerplate. The scarce thing now isn't knowing how to do something — it's knowing which thing is worth doing, and why, and what to kill when you're wrong.

I'm not saying domain expertise is worthless. I'm saying the shelf life has shortened in ways most hiring processes haven't caught up to yet. We're still writing job specs around knowledge that commoditizes faster than we can onboard.

What doesn't commoditize: judgment under ambiguity, the ability to question a brief before executing it, comfort operating without a playbook.

You can't prompt-engineer your way to those.

Hire for the skill that gets more valuable as AI gets better, not less.

Freeform draft

Revised v1 · 12 Mar 2026

We hired a domain expert last year. Deep background, credentialed, exactly the profile we'd spec'd out. Within six months it was clear we'd solved the wrong problem.

The expertise was real. The judgment about when to use it, less so.

I keep coming back to this because the market for specialized talent is heating up exactly when the tools that made specialization scarce are leveling it out. A senior buyer with fifteen years in JIT manufacturing is valuable, yes. But a significant chunk of what made that person hard to find, the pattern recognition, the supplier negotiation heuristics, the demand-signal interpretation, a well-configured AI layer handles competently now. Not perfectly. Competently.

So what actually remains scarce? I think it's something harder to interview for. The ability to know when a model is confidently wrong. The instinct to override good process because something feels off in a way that can't be articulated yet. You don't find that on a resume, and most hiring rubrics aren't built to surface it.

The thing I can't fully resolve is whether most companies know this yet. The job descriptions I see are still written like it's 2019, stacking domain credentials as if depth of expertise is automatically the same as quality of judgment.

It isn't, and it never was. Expertise was always a proxy. We just didn't have to think about it before because the proxy was cheap and mostly worked.

The mandate now is probably to hire for calibrated skepticism, not accumulated knowledge, and almost no one has figured out what that interview looks like.

What are you actually testing for when you interview senior domain hires right now?

Freeform draft

Draft v2 · 12 Mar 2026

We ran six weeks of discovery on a feature. Customer interviews, competitor teardown, usage data, the whole thing. The final deck was genuinely impressive. And while we were building that deck, a competitor shipped.

The thing I keep getting stuck on is how clean our hands felt. We had done the work. We had been thorough. If the feature had flopped, we could point to the process. And I think that's exactly the problem.

Discovery had become the thing we were accountable for, not the outcome. Rigor became a form of insurance. The more thorough the research, the more defensible the delay. Nobody could accuse you of being reckless if you had forty customer quotes and a journey map.

But your competitor doesn't care about your journey map.

I've watched this pattern metastasize in organizations that genuinely care about accountability. They build accountability cultures, then fill them with process artifacts instead of results. Teams get rewarded for documented diligence while the market moves. The accountability is real. It's just pointed at the wrong thing.

This is hard to fix because the discovery isn't fake. The research is often good. The issue is that thoroughness and decisiveness are in tension, not alignment, and most organizations pretend they aren't.

The question I can't fully answer: how do you build a team that treats an imperfect decision made fast as more valuable than a perfect recommendation made too late?

Freeform draft

Revised v1 · 12 Mar 2026

We ran six weeks of discovery on a feature. Surveys, interviews, synthesis sessions, a Miro board that could wallpaper a conference room. The team presented findings with real confidence. The process was genuinely rigorous.

We shipped eight months later. A competitor shipped in three. Their version wasn't better researched. It was just there first.

The thing I keep getting stuck on is how cleanly "we followed the process" became the answer to "why didn't this land?" Nobody lied. The research happened. But somewhere in those six weeks, thoroughness became the deliverable, and the actual deliverable got treated like a downstream consequence that would take care of itself.

I've watched this pattern enough times to name it: discovery accountability and outcome accountability are not the same thing, and organizations that conflate them tend to reward the wrong behavior at exactly the wrong moment. A team that ships a flawed but testable product in six weeks learns something real. A team that presents polished research at week twelve has a very sophisticated way of not yet knowing anything.

None of this means skip the research. But there's a version of discovery culture that functions less like a path to decisions and more like a professionally acceptable way to delay them. Rigor becomes the alibi.

Accountability for process is not accountability for results.

The question I can't fully resolve: how do you build a culture where people feel genuinely responsible for outcomes, not just for having done the right steps before the outcome disappointed everyone?

Freeform draft

Draft v2 · 12 Mar 2026

We shipped everything on the roadmap one quarter. Every date hit, every ticket closed, every review filled with specific accomplishments with examples. My team looked great on paper.

The product barely moved.

What I'd built wasn't an accountability system. It was a documentation system. There's a difference, and the difference is expensive. Documented deliverables tell you what got done. They say almost nothing about whether the right decisions got made, or whether the people making them had the information they needed, or whether the gap between what leadership decided and what engineering actually built ever got surfaced and resolved. That gap is where execution actually lives. And it fits neatly inside a "completed" status.

The thing I keep getting stuck on is that most accountability frameworks are designed to answer one question: did the team do what they said they'd do? But that question assumes the thing they said they'd do was the right thing. It assumes the spec reflected the intent. It assumes the intent reflected the problem. Those assumptions are almost never examined, because everyone is too busy closing tickets.

So we add more rigor. More documented accomplishments. More performance requirements. And we get better and better at measuring effort while the outcomes stay murky.

I'm not sure there's a clean fix here. But I've started thinking that genuine accountability has to include visibility into where alignment broke down, not just confirmation that work got completed. Decisions, tradeoffs, moments where someone knew something and had nowhere to put it.

The frameworks we're doubling down on right now were built to measure the wrong variable.

What are you actually learning from your team's accountability structure that you wouldn't know otherwise?

Freeform draft

Revised v1 · 12 Mar 2026

We shipped everything on the roadmap that quarter. Every ticket closed, every date hit, every stakeholder update green. I walked into the board review genuinely proud.

The product hadn't moved. Retention was flat. The feature we'd spent three months building had single-digit adoption. We had executed perfectly against the wrong signal.

What bothered me afterward wasn't that we failed. It was that our accountability system had no way to see the failure coming. It was optimized to track completion, not consequence. Tasks closed. Dates met. Outcomes invisible.

This is the thing I keep getting stuck on when I watch teams add more rigor to their frameworks post-reorg: documented deliverables and real impact are not the same measurement, and treating them as substitutes doesn't close the gap. It just makes the gap harder to see. You end up with accountability theater, where the performance of execution substitutes for the fact of it.

Measuring output without outcome doesn't create accountability. It creates a very organized way to miss the point.

The harder question, and I don't have a clean answer to it, is what you'd have to change about your review structure to make impact visible in real time, not in the retrospective after the miss. Because most frameworks aren't built for that. They're built to document what happened, not to surface what's not working while there's still time to change it.

What does your current setup actually measure?

Freeform draft

Draft v2 · 10 Mar 2026

We shipped a feature no customer asked for. The team was proud of it. I was proud of it. It solved a real architectural problem that had been bothering us for eight months.

It got used by four people in the first quarter.

I've watched this pattern play out across a dozen companies now, and the part that bothers me is how rational it looks from the inside. The founder who keeps expanding scope isn't confused. The exec who hoards context isn't insecure. They're both following logic that worked before, in a different company, at a different stage. The mistake isn't a lapse. It's a system running the right program at the wrong time.

Feature creep doesn't start with bad judgment. It starts with a team that learned to equate shipping with progress, and nobody stopped to update that equation when the market shifted. Knowledge hoarding doesn't start with ego. It starts with a leader who got burned by delegation once and quietly recalibrated what trust means. These aren't character flaws. They're adaptations that calcified.

The thing I keep getting stuck on is how hard these patterns are to see in real time, because they feel like wisdom. The accumulated instinct of someone who's been right before. I've been the person defending a decision I'd already privately started to doubt, and there was a part of me that felt completely justified doing it.

Treating these as individual mistakes is what keeps them expensive. When you locate the problem in the person, you miss the system that keeps producing the same person.

What pattern have you watched repeat inside an organization, even after leadership changed?

Freeform draft

Revised v1 · 10 Mar 2026

We called it "strategic alignment." What we had was three teams building toward three different versions of the same product, none of whom knew it.

I didn't figure that out from a retrospective. I figured it out when a customer asked me a question about our roadmap and I gave them an answer that contradicted what our head of product had said in the same meeting, twenty minutes earlier. Neither of us was lying. We just had completely different mental models of what we were building and why.

That's the part that still bothers me. We weren't confused because we lacked process. We had plenty of process. We were confused because each of us had quietly rationalized our own version of the product vision into something that made our past decisions look correct. Feature creep doesn't come from laziness. It comes from smart people protecting coherent but incompatible stories.

I've seen this in rooms with seasoned executives more often than in rooms with first-time founders. Which tells me it's not an experience problem. It's a system that rewards local coherence over shared truth. The person who sounds most certain wins the meeting. The misalignment goes underground.

The thing I keep getting stuck on is that most of the frameworks we reach for treat this as a communication failure. Send the memo. Run the alignment session. Cascade the strategy. But those tools work on the symptom, not the pattern underneath it. The pattern is that organizations select for people who appear to have it figured out, then act surprised when those people stop admitting they don't.

What's your version of that moment in the meeting? I'm curious whether others have found anything that actually interrupts the pattern before it compounds.

Freeform draft

Draft v2 · 5 Mar 2026

I've watched teams ship broken products and cite Reid Hoffman in the same breath.

I've done it myself. Not the shipping part — I was on the receiving end of the decision — but there was a moment where I remember feeling something close to relief when someone said "embarrassed by v1" in the meeting. It let us stop arguing.

That's the tell. When a quote becomes a permission structure, you've stopped using it as a check and started using it as cover.

The original logic is specific: release before you've over-engineered, before you've gold-plated something users haven't confirmed they want. It's an argument against the trap of internal perfectionism. It says nothing about shipping something that doesn't function. Those are not the same thing, and the distance between them is where a lot of bad product decisions live.

Permission structures are dangerous because they're selectively applied. Nobody invokes "embarrassed by v1" about the onboarding flow that worked. They invoke it about the checkout bug, the broken state, the feature that needed three more weeks. The quote absorbs the blame and the team moves on.

I'm not sure the misread is accidental either. That's the part I keep coming back to.

Wisdom survives because it's useful. It gets misread when being useful to the idea and being useful to the person quoting it start pointing in different directions.

What does your team actually mean when they say it?

Freeform draft

Revised v1 · 5 Mar 2026

Three days without sleep, a countdown timer, and a public commitment to ship Monday at 8 AM no matter what. I've seen this story before. There was a part of me, honestly, that felt a familiar pull reading it. The urgency feels heroic. The shipping feels brave.

But I keep getting stuck on the part nobody names.

When you build toward a fixed public deadline instead of a quality threshold, you've made the deadline the product. Your team isn't optimizing for the user. They're optimizing for 8 AM. Those two targets are related but they are not the same thing, and confusing them costs you later in ways that don't show up in a launch-day user count.

The "embarrassed by v1" framework is real. Reid Hoffman said it. It's survived because it contains truth. But it gets misread. The original logic is about releasing before you've over-engineered, not about releasing before the product works. The misread version is a permission structure, and permission structures attract justification.

Triple-digit users in a few hours is a number. What it doesn't tell you is how many of them will be there in 30 days, or what they actually needed that you didn't ship.

Speed matters. Constraint is legitimate. But artificial deadlines dressed as urgency aren't discipline. They're theater that your team has to perform and your users have to absorb.

The thing I can't fully resolve is where the line sits. Because sometimes shipping rough is right. I just don't think a self-imposed public timer is how you find it.

What's your read on where the discipline ends and the performance begins?

Freeform draft

Draft v1 · 3 Mar 2026

We rebuilt our product planning process around what the AI agent could do well. Cleaner handoffs, faster synthesis, fewer meetings. On paper it looked like a real operational improvement.

Six months later we had a system that was genuinely excellent at things that didn't actually drive decisions.

The thing I keep getting stuck on is how invisible that trade-off is in the moment. When you restructure around agent capability, you're optimizing for throughput on the tasks the tool handles cleanly. What degrades quietly is the judgment infrastructure around the edges — the places where someone used to have to think hard enough to notice something was wrong. We didn't lose a process. We lost the friction that was doing real work.

I've watched teams call this AI-native architecture. What it actually is, most of the time, is efficiency theater with better tooling. The agents perform. The decisions get softer.

This isn't an argument against agentic systems. It's an argument for being honest about what you're actually trading when you restructure around capability instead of around the decisions that matter. The PM trade-off that nobody wants to name: you can have a system that moves faster or a system where it's clear who's responsible for being wrong. Getting both requires design discipline that most implementations skip because vendors don't sell it.

Actually, that's not quite right either. Some teams get this right. I just haven't seen many who got it right on the first pass.

What did you actually lose clarity on when you went deeper into agentic workflows?

Freeform draft

Draft v2 · 3 Mar 2026

Freeform draft

Revised v1 · 3 Mar 2026

Last week I watched a team demo something they'd spent six weeks building with AI. It was genuinely impressive. Polished UI, clever logic, shipped faster than anything they'd done before.

Then someone asked: "Who asked for this?"

Silence.

Here's what I think is happening. AI has collapsed the cost of building to near zero for things that used to require serious engineering talent. That's real. That's remarkable. But we've conflated "I can build this in a weekend" with "this is worth building." Those are completely different questions, and we used to know that.

The old constraint wasn't just inefficiency. It was a forcing function. When something was hard to build, you had to justify it before you started. You had to answer the customer problem, the market timing, the opportunity cost. The difficulty created a natural gate for product judgment.

AI removed the gate. It did not remove the need for the judgment.

I've sat in enough product reviews to know that most bad products aren't bad because of poor execution. They're bad because someone got excited and skipped the part where you ask whether the thing should exist at all. Now we have a tool that makes it easier than ever to skip that part faster than ever.

Velocity without judgment isn't progress. It's just expensive mistakes delivered on time.

The fundamentals haven't changed: is this the right problem, is now the right moment, are we the right people to solve it, and what are we not building because we built this instead. AI doesn't answer any of those. It just makes it cheaper to avoid asking them.

What have you seen teams stop asking since building got easier?

Freeform draft

Draft v4 · 3 Mar 2026

We shipped an AI-powered recommendation engine and celebrated. Engagement was up. The team felt like we'd cracked something. Three months later, the model had quietly learned to optimize for a metric that made our numbers look good and our product worse. Nobody caught it because nobody thought they needed to.

That's the trap. AI integration looks like it removes judgment from the equation. You hand decisions to the algorithm, the algorithm scales, and the hard product thinking becomes someone else's problem. But the judgment doesn't disappear. It relocates.

Now it lives in decisions most teams aren't equipped to make: which user outcomes are too consequential to delegate to a model, where explainability matters more than accuracy, when a feature that tests well is still the wrong thing to build. These aren't engineering questions. They're not even traditional product questions. They require a kind of meta-discernment that most discovery processes were never designed to surface.

The teams I watch struggle most with AI implementation aren't the ones with bad data or weak models. They're the ones who treated AI as a shortcut past hard product thinking rather than a reason to do more of it. The brittle implementations, the unmaintainable architectures, the stakeholder misalignments that blow up six months post-launch: almost all of it traces back to the same root cause.

You can't hand the algorithm a decision you haven't fully understood yourself.

The tools got easier. The judgment bar got higher. That's the part most product leaders haven't fully reckoned with yet.

Where are you seeing teams get this wrong most often?

Freeform draft

Revised v3 · 3 Mar 2026

We shipped an AI-powered feature that worked beautifully in testing and became unmaintainable within a quarter.

The model was doing exactly what we asked. That was the problem. We had instrumented the wrong decisions — the ones that felt risky to us as humans — and left the algorithm in charge of the ones that felt routine. Turns out we had it exactly backwards.

Here is what I learned from that: AI integration doesn't reduce the product judgment required. It raises the stakes on it. You are no longer deciding what the feature does. You are deciding which decisions belong to the system and which belong to a human, and that boundary is where most implementations quietly fall apart.

The teams I watch struggle most are the ones who treated AI as a feature to ship rather than a delegation architecture to design. They got the model working and skipped the harder question of what the model should never be allowed to decide alone.

In martial arts, shuhari describes the progression from following rules, to breaking them, to transcending them. Most product teams are trying to skip straight to transcendence. They want the AI to just figure it out. But you cannot delegate judgment you haven't developed yourself. The algorithm inherits your product thinking, including the gaps.

Knowing when to let the system decide and when to hold the line is not a technical skill. It is a product skill. One that takes longer to build than the feature itself.

What's the hardest boundary you've had to draw between human and algorithmic decision-making in something you've shipped?

Freeform draft

Revised v2 · 3 Mar 2026

We shipped an AI-powered recommendation engine and celebrated like we'd done something smart. Retention ticked up. Leadership was pleased. We moved on.

Six months later, the model was quietly recommending things that made no business sense, and nobody could explain why. Not the engineers. Not the data team. Certainly not me. We'd handed over a decision and forgotten to understand which decision we'd actually handed over.

That's the trap. Teams assume that deploying AI reduces the cognitive load on product judgment. It doesn't. It relocates it, and usually to a place you weren't watching.

Before AI, a bad product decision was visible. Someone owned it, defended it in a review, and got questioned on it. With AI in the loop, bad judgment gets laundered through model behavior. It becomes harder to see, harder to attribute, and much harder to reverse.

The Shuhari framework describes mastery as knowing when rules apply, when to bend them, and when to transcend them entirely. Most teams deploying AI are operating at step one while pretending they're at step three. They're letting the algorithm decide without having first understood what the algorithm is actually deciding.

Knowing when to let the model drive and when to override it is not a technical skill. It's a product judgment call, and it requires sharper discernment than most analog feature decisions ever did.

The teams getting this right aren't the ones with the best models. They're the ones who stayed curious about what they were delegating.

If you're mid-implementation on something AI-powered right now, what's the decision your model is making that nobody on your team has explicitly signed off on?

Freeform draft

Revised v1 · 3 Mar 2026

Here's a pattern I've noticed in teams shipping AI-powered features for the first time: they assume the hard part is the model. It isn't. The hard part is knowing when not to trust it.

I watched a capable team spend three months building an AI-driven prioritization layer into their core workflow. It worked. The model's recommendations were genuinely good. And they shipped it without ever settling the question of which decisions should remain human-owned, which should be surfaced and confirmed, and which could run autonomously without anyone watching. Six months later, the feature was technically live and operationally abandoned. Nobody trusted the outputs because nobody had agreed on what trust was supposed to look like.

This is where the Shuhari framing gets uncomfortable. The "follow the rules" stage of AI integration isn't about prompts or APIs. It's about earning the right to let the algorithm decide by first understanding, precisely and specifically, what it means for the algorithm to be wrong. Teams that skip that don't end up with less process. They end up with more — retrofitted, reactive, and expensive.

AI doesn't reduce the need for product judgment. It raises the stakes on it. Every boundary you fail to draw explicitly, the system will draw implicitly, and usually at the worst possible moment.

The teams getting this right aren't the ones moving fastest. They're the ones who can articulate, before launch, exactly where human discernment is load-bearing and where it isn't.

What's the hardest boundary your team has had to draw between algorithm-owned and human-owned decisions?

Freeform draft

Draft v2 · 3 Mar 2026

Last quarter, our team shipped more product than in any six-month stretch I can remember. Clean specs, groomed backlogs, meeting notes that practically wrote themselves. Everyone looked busy. Everyone looked productive. We celebrated the velocity.

Then we did a customer review and realized almost none of it had moved the metrics we actually cared about.

Here's what I think happened. AI genuinely compressed the work that was always easy to point to: the artifacts, the documentation, the roadmap slides that made leadership feel informed. That work became nearly frictionless, so we did more of it. More specs reviewed. More roadmap updates. More tickets with beautifully written acceptance criteria. And because all of that was visible and fast, it crowded out the work that doesn't look like work from the outside: sitting in an uncomfortable conversation with a founder about whether the whole bet is wrong, holding a hard tradeoff that no framework resolves, staying in discovery long enough to actually be surprised.

The AI didn't eliminate the bottleneck. It just made the bottleneck invisible by filling the calendar with its more photogenic cousin.

I don't think most teams made a cynical choice here. The incentive gradient just tilted, quietly, and everyone followed it rationally. Speed rewarded. Ambiguity penalized. Artifacts valued over judgment.

Faster shipping without better thinking is just a more efficient way to build the wrong thing.

I'm curious whether others are seeing this in their orgs, and more specifically, whether you think it's a tooling problem, a measurement problem, or something deeper in how leadership evaluates PM performance.

Freeform draft

Revised v1 · 3 Mar 2026

Here's a pattern I've seen play out at three companies in the last eighteen months.

The team adopts AI tooling. PRDs get written in minutes. Roadmaps look cleaner than they ever have. Meeting notes are summarized automatically. The Notion wiki is, for the first time, actually current.

And then, six months later, nothing meaningful shipped.

I lived through a version of this. We had gotten genuinely good at the visible surface of product work. The artifacts were crisp. The processes were legible. Leadership loved the demos of our process. I let myself feel good about it.

What we had quietly stopped doing was harder to name at the time. The uncomfortable customer conversation that rewrites your assumptions. The negotiation with the founder where you have to say the roadmap is wrong and have a real answer for why. The judgment call where the data says one thing and every experienced person in the room feels something different.

None of that work shows up in your Notion. None of it gets faster with AI.

What AI actually did was make the theatrical half of PM work nearly frictionless. So organizations, rationally, invested in it. Better templates. Faster outputs. More artifacts, produced more quickly, reviewed in better-run meetings.

The invisible half, the part where actual product sense lives, got relatively more expensive and relatively less rewarded.

Velocity went up. Value didn't follow.

The bottleneck was never the spec. It was always the thinking behind it.

I'm curious whether others are seeing this split widen, or whether you've found ways to protect the discovery work when the pressure to produce artifacts keeps increasing.

Freeform draft

Draft v4 · 3 Mar 2026

A junior dev on one of my teams shipped a feature in three days that would have taken a senior six weeks. Everyone celebrated. I celebrated.

Six months later, the feature was unmaintainable. The junior couldn't explain why it worked, only that it did. When edge cases appeared that the AI hadn't seen before, she froze. Not because she wasn't smart. Because she had never actually learned the thing she shipped.

There's a concept in martial arts called Shuhari. You master the fundamentals before you adapt them, and you adapt them before you transcend them. Most AI-accelerated development is skipping straight to the third stage and calling it progress.

I've watched this pattern repeat. A team builds fast, looks competent, gets promoted or hired on that velocity. Then something breaks in a way no prompt can diagnose. The tool-user either bluffs badly or leaves. And the team discovers they don't have a codebase. They have accumulated outputs they can't reason about.

The fragility isn't obvious until it is. And by then, the architectural debt is structural.

I'm not arguing against AI tooling. I'm noticing something about what we're measuring. Shipping speed is visible. Understanding is not. And when we optimize exclusively for what we can see, we tend to build teams that look strong until the moment they need to actually be strong.

Speed isn't competence. Output isn't understanding. We keep confusing the two because the gap doesn't show up on a sprint board.

Curious whether others are seeing this play out on their teams, or whether I'm pattern-matching something that isn't as widespread as it feels from where I sit.

Freeform draft

Revised v3 · 3 Mar 2026

A junior engineer on my team once shipped a feature that passed every test and broke production in three hours.

When I sat down with him to debug it, I watched something I hadn't expected. He opened the AI tool. Typed the error. Waited. The suggestion didn't work. He typed the error again, slightly rephrased. Still nothing useful. He looked at me with genuine helplessness. Not because he was lazy. Because he had never actually learned to read the system.

He could generate code faster than anyone I'd managed in ten years. He just couldn't see it.

There's a model from martial arts called Shuhari. You follow the rules until they become instinct, then you bend them, then you transcend them. Most AI-assisted engineering right now is skipping straight to transcendence. Junior engineers shipping production code without ever building the mental model that makes debugging possible when the tool runs out of ideas.

The tool runs out of ideas more often than anyone is admitting right now.

What I've noticed isn't that AI is making engineers worse. It's that it's making a specific failure mode invisible until it's expensive. Competent output. Fragile understanding. The gap only shows up under pressure, when the error is novel, when the architecture decision has downstream consequences, when the engineer who knew how to prompt for it has already left.

We're calling this productivity. Some of it is. Some of it is technical debt we're agreeing to pay later, with interest, without knowing we signed.

I don't have a clean answer here. I'm still working through what good AI-assisted mentorship even looks like.

What are you seeing in your teams?

Freeform draft

Revised v2 · 3 Mar 2026

Here's a pattern I've noticed playing out quietly across engineering teams right now.

A junior dev ships something impressive. Fast. Clean-looking. The manager promotes them. Six months later, the system starts doing weird things under load, and nobody can explain why. The dev who built it can't debug it. They can describe what the code does. They cannot tell you why it's doing that.

I watched this happen twice in PM roles before I understood what I was actually seeing.

There's a concept in martial arts called Shuhari. You start by following the rules exactly (shu), then you break them deliberately (ha), then you transcend them (ri). The point is that you cannot skip shu. You have to do the boring repetitive thing long enough to build the intuition that lets you break rules intelligently later.

AI-assisted coding lets junior engineers live almost entirely in ri. They're executing at a level that looks like mastery. It isn't. It's pattern-matched output they can't interrogate when something goes wrong.

I'm not blaming the engineers. I probably would have done the same thing at 24.

The fragility shows up when the tool can't help anymore. When the bug is architectural. When the question isn't "how do I write this" but "why is the whole thing wrong." That's the ceiling. And a lot of teams are about to hit it at the same time.

The engineers who survive this wave won't be the fastest prompt writers. They'll be the ones who were made to do things the slow way first.

What are you seeing on your teams right now?

Freeform draft

Revised v1 · 3 Mar 2026

Here's a pattern I've noticed playing out across engineering teams right now.

Junior dev ships a feature in two days that would have taken two weeks. Manager celebrates. Velocity metrics look great. Everyone feels like they've unlocked something.

Then the feature breaks in production. In a way the AI didn't anticipate. And the engineer who shipped it has no idea where to start.

I watched a version of this unfold on a product I was embedded with last year. The engineer wasn't incompetent. They were competent in exactly the shape of the tool they used. Outside that shape, they were lost.

There's a learning model called Shuhari. The idea is that mastery requires moving through three stages: rigidly following the rules, breaking them consciously, then transcending them. AI-assisted coding lets you skip straight to stage three. Except you haven't earned the intuition that makes stage three work. You've just borrowed someone else's.

What you get is engineers who can build but can't read. Who can ship but can't debug. Who perform confidence until the moment the tool can't help them anymore.

And here's the part that doesn't show up in your velocity dashboard: when that engineer leaves, they take nothing with them. Because they never really understood what they built. The knowledge lived in the model, not in them.

Companies are calling this democratization. I keep thinking it looks more like a confidence loan with a variable interest rate.

The debt doesn't show until it does.

If you're managing engineers right now, I'm curious: how are you actually distinguishing between understanding and fluency?

Posts Pipeline

Draft New Post