Product-Management

A recent Sequoia piece made an argument that immediately felt familiar to me. Not because it repeated the phrase “Judgment Driven Development” word for word. But because it pointed at the same shift from a different direction. The article is here: Services: The New Software. Its claim is simple: the next generation of great companies may not look like software vendors at all. They may look like software and AI powered service providers. Instead of selling tools to people who do the work, they will sell the work itself. Instead of selling accounting software, they will close the books. Instead of selling legal tooling, they will draft the NDA. Instead of helping a team perform a process faster, they will increasingly perform the process directly. ...

There is a version of Product Management work that AI can probably do. It can certainly summarize interviews, cluster feedback, draft PRDs and epics, answer questions about product data, and produce mockups. Do enough of that well enough, and the role starts to look like an information processing layer with some communication on top. But that is not what Product Management is all about. The center of the role was never the paperwork. It was always judgment: deciding what problem matters, interpreting incomplete and conflicting signals, making tradeoffs under uncertainty and pressure, defining success, and taking responsibility for the call. ...

In the previous post, I argued that defining decision boundaries is necessary if we want judgment to survive in an AI-accelerated development environment. When execution becomes cheap, the number of decisions explodes. Without clarity around who decides what, speed simply amplifies risk. But defining boundaries alone is not enough. The next question is more practical: how does work actually flow through those boundaries? How does an idea move from a conversation with a customer to something running in production, while AI accelerates the process without collapsing responsibility across roles? ...

In the previous posts, I argued that execution is no longer scarce and that judgment, not effort, has become the limiting factor. I also argued that judgment without memory slowly degrades into improvisation. But even if you solve memory, even if context is accessible and history is visible, something can still go wrong. You can have full information, experienced people, and AI assisting at every step, and still end up making decisions that gradually weaken the system. ...

Memory Is the Missing Layer in AI-Assisted Development In the previous posts, I argued that execution is no longer the bottleneck and that judgment isn’t intuition, it’s accountability. Those two shifts already change how we should think about building software. But there is a third layer that matters just as much and is far less visible. Memory. Not model memory. Not guardrails. Not rule engines. Institutional memory. The living history of why things exist. ...

The Stages of Judgment-Driven Development Most of the pain I’ve seen in software wasn’t caused by bad code. It was caused by bad decisions that were never treated explicitly as such. In the last two posts, I argued that execution is no longer the bottleneck. AI made building cheap. Judgment is now the scarce resource. If that’s true, the way we develop software must change, not in terminology or ceremonies, but in where and how we place judgment. ...

What “Human Judgment” Actually Means in the Age of AI We often talk about judgment as if it were intuition, taste, or seniority, something vague that people either have or don’t. That framing is wrong. Judgment is not intuition. It’s accountability. In real systems, judgment isn’t about gut feeling or instinct. It’s about being accountable for decisions made under uncertainty. Judgment shows up in moments like deciding something is good enough to ship, deciding not to ship even though it technically works, deciding to stop a direction after weeks of investment, or deciding that a shortcut today will become an unacceptable liability six months from now. ...

I didn’t start thinking about this because I’m excited about AI writing code. I started thinking about it because I kept seeing the same patterns repeat over the years. This time, they come under a new name: vibe coding, the habit of describing what you want in natural language and letting an AI scaffold the system for you, often without deeply understanding the code it produces. Vibe coding feels almost magical. You describe what you want, and something real starts to take shape. At first glance, it genuinely works. You get something running shockingly fast, faster than any team I’ve worked with could have done a few years ago, and it often looks surprisingly good. ...

I heard Satya Nadella describe this week on the All-In podcast how LinkedIn has been collapsing product management, UX, and engineering roles into a single “full-stack builder” role. The framing was optimistic: AI reduces construction costs and speeds up delivery. At a surface level, this makes sense. AI dramatically accelerates prototyping, implementation, and iteration. In many environments, the traditional separation between PM, design, and engineering really does introduce friction that slows learning and execution. ...

A Small Number, a Real Moment CV Match has been out in the world for a few months now. I almost didn’t notice when it crossed 100 installations. That number, by itself, is not impressive. It is small. Almost trivial. What made me stop was not the number, but the realization that this thing actually existed in the hands of people I did not know. Real users, not personas. Real decisions, not demos. ...