This is the chapter's holding area: seven pieces that carry real weight but never settled into one of the other ten chapters — Deutsch's "good explanation" as an epistemic lens on building, Shreyas Doshi's account of clarity-creation as a product leader's core job, Tom Verrilli's T-shaped attention model, Dan Olsen's Kano model, John Cutler's subtraction question, the PRD-after-discovery discipline, and Cagan's one-line claim about which orgs transform most easily. Read in order they do cohere around a single thread: the difference between knowing that something works and knowing why, and what that difference costs a leader in attention, ritual, and documentation. Where the material is thin — and in places it is a single asserted claim with no worked case — this read says so rather than padding it out.
The deepest idea in this chapter is borrowed from outside product management entirely. David Deutsch's argument in The Beginning of Infinity, cited by Tomer Cohen as a personal lens, is that progress compounds without limit once you have a good explanation — a causal account of why something happens, not a correlation or a pattern that merely works. The test Deutsch offers is hardness-to-vary: a good explanation breaks if you change its parts, which is exactly what makes it a stable foundation to iterate on. Correlational or trial-and-error knowledge is brittle by comparison and doesn't compound the same way; you can pile a hundred experiments on top of it and still be no closer to knowing what you have. See The Beginning of Infinity (Explanatory Knowledge).
Cohen's application to building is direct: understand root causes before layering iteration on top of them, rather than optimizing a black box. It is also, in the body's own framing, consistent with his critique of blanket-access AI agents — systems that pattern-match across everything available instead of reasoning from a curated ground truth. Worth saying plainly: this is a personal lens one practitioner names, not a product framework, and the chapter carries no worked example of someone applying the hard-to-vary test to a product decision. It is a stance about what counts as knowledge, offered as such.
It happens to be the right opening for a chapter of orphans, because most of what follows turns on the same distinction. Doshi separates status tracking from clarity-creation — knowing the project is red from knowing why and what to do about it. Verrilli's deep-dive replaces a summarized readout with the tickets, the code, and the underlying data. Olsen's Kano model is a causal account of how satisfaction responds to need-fulfilment rather than a feature checklist. The kickoff meeting exists because a document carries the conclusion but not the reasoning. None of these were written to illustrate Deutsch, and reading them as a system would be overclaiming. But the family resemblance is real, and it's the most honest spine an unsorted chapter is going to get.
Shreyas Doshi's claim is compact: the main job of anyone responsible for a product is to create clarity, at both the macro and the micro level, on what to build, how to build it, and how to expand it. In his words, "their main job is to create clarity and it's to create clarity at the macro level and the micro level." The framing holds whether the person is a product leader in the broad sense or, more narrowly, a leader of PMs — the chapter's material distinguishes those two vocabularies, and the wider taxonomy of leadership roles belongs to Product Leadership and Career Craft. See Create Clarity: The Core Job of a Product/PM Leader (Strategy, Editing, Meta Execution, Coaching).
He breaks the job into four tasks, and the pattern across all four is that the leader's leverage sits in shaping what others produce, not in producing it:
The sharpest part of the argument is the hierarchy Doshi draws underneath it. Status tracking — spreadsheets, red/yellow/green updates, escalating delays — is "table stakes... any smart human being can do." What justifies a product leader's compensation is the higher-order work: creating clarity on prioritization, translating executive and company thinking into something the team can act on, doing product strategy (which he flags as especially load-bearing when managing across multiple features and PMs), and coaching PMs on communication and stakeholder management. Clarity also runs outward — helping PMs present well to executives, and helping the rest of the company understand what's being built.
He caps AI's contribution here explicitly: "if AI tools help with clarity... they will help to a 5% or 10% marginal degree" — the rest has to come from the manager. That is a quantified instance of the general caution against outsourcing judgment work to tooling, and it sits in useful tension with everything in AI and the Changing Shape of Product Work, which is where the argument about what AI is actually displacing gets worked out.
What makes the claim more than a slogan is that Doshi anchors it in his own before/after arc rather than in theory. He was, by his account, "so bad" at managing PMs that he told employers he didn't want to manage people, was pushed into the role anyway, and only improved once he reframed the job as clarity-creation — later rating among the highest-quality managers at his company. His stated pedagogy for smart audiences — "tell them what not to do, because smart people can figure out what to do" — is offered as itself an example of clarity-creation.
If clarity is the job, the next question is where a leader spends attention to produce it, and Tom Verrilli's answer is a shape. The T-shaped operating model is a leadership posture: stay broad across the org by default — macro oversight, light touch — but periodically go deep, firsthand and line-by-line, with one specific team when a decision demands it. Depth is earned by need, not applied uniformly. See T-Shaped Operating Model.
The concrete mechanism is the founder deep-dive review. When a decision or a metric feels wrong, the leader clears the calendar and goes through the tickets, the code, and the underlying data directly with the team, rather than relying on a summarized readout. Verrilli cites diving into Whatnot's fraud-invalidation logic this way. Note what the mechanism is actually for: a readout is a compressed, secondhand account, and the deep-dive exists because the compression is exactly where the causal detail goes missing — the same instinct as The Beginning of Infinity (Explanatory Knowledge)'s preference for understanding the mechanism over optimizing a black box.
The reason the model needs stating at all is that depth of this kind is easily mistaken for micromanagement, and often is micromanagement. The body is precise about the legitimacy conditions: founder-style depth counts as leadership, not interference, only when it is occasional, need-triggered, and grounded in real data — rather than constant and reflexive. That is a narrow gate, and it is the whole distinction. A leader who deep-dives every team every week has not adopted a T shape; they have simply moved down a level and taken the team's decisions with them.
Read against Doshi's four tasks, this sits slightly awkwardly with meta execution — the principle that the leader owns the structure while day-to-day sub-team execution is delegated. Going through tickets line by line is, on its face, day-to-day. The two accounts are not obviously incompatible, since Verrilli's trigger is a decision that feels wrong rather than a standing routine, but neither body reconciles them, and the boundary is left to judgment.
The one full framework parked in this chapter is Dan Olsen's use of the Kano model, which plots how fully a product meets a need (X-axis, 0–100%) against the resulting customer satisfaction or dissatisfaction (Y-axis). Needs sort into three categories, and the point of the model is that they behave differently along those axes. See Kano Model.
The strategically consequential part is that the categories migrate. "Yesterday's delighters become today's performance, become tomorrow's must-haves — and the pace with which that evolution happens just depends on the level of innovation and competition in your space." A delighter that gets copied slides down into a performance dimension and eventually into table stakes. Instagram's filters were a genuine delighter in 2010; by the mid-2020s their absence would get an app laughed out of the store.
That migration is why a delighter-based strategy has a shelf life by design — it is meant to be copied — and therefore why product strategy has to be revisited rather than set once. Olsen uses this categorization as the row axis of his product strategy grid, to identify which single performance dimension a team can plausibly own and which delighter is currently unique to it; the same pattern is what he reads out of the Instagram and Uber cases. The grid itself and the surrounding strategy method live in Strategy, Vision, and the Decision Stack, and the question of how any of this becomes a plan of work belongs to Roadmaps, Prioritization, and Outcomes. What the model contributes on its own is the causal claim: satisfaction is not a linear function of effort, and which curve you are on determines whether shipping more of something buys you anything at all.
Two of the chapter's smaller entries are both about the gap between a process existing and a process working, from opposite ends.
John Cutler's observation is that teams and orgs routinely add new practices, rituals, and tools without ever asking what should be stopped in exchange. The result is cognitive overload: everyone is nominally following more processes, but nobody has the bandwidth to do any of them well. The counter is a forced-tradeoff question he puts to teams — what are you going to stop doing? — asked before anything new is adopted, so that subtraction becomes a required step rather than an afterthought. The body notes the asymmetry that makes this necessary: work-in-progress limits give teams a mechanism for capping concurrent work items, but no equivalent discipline is applied to the practices themselves. See Practice Accumulation Without Subtraction (Cognitive Overload).
From the other end, the PRD-after-discovery discipline is about sequencing and delivery of a single document. Write the PRD after discovery concludes, as a record of what was learned and decided, rather than before it as a speculative spec — and then always walk the team through it live, in a kickoff meeting, instead of posting it to a channel and treating silence as agreement. See PRD-After-Discovery / Kickoff Meeting.
The failure mode being corrected is the context gap between the people who did the reasoning and the people who receive the conclusion. A document dropped into Slack carries none of the context, tone, or nuance of the thinking behind it, and nobody objecting is not the same as everybody agreeing. A live kickoff — Zoom or in-person — surfaces objections and questions while they are still cheap to address. This is the same problem Doshi's clarity-creation names at the leader level, arriving here at the level of a single artifact: the artifact holds the decision, and the meeting is what transmits the why.
There is an obvious unresolved edge between these two entries, and it is worth naming rather than smoothing over. The kickoff meeting is itself a new ritual, added to the calendar; Cutler's question would ask what it displaces. Neither body answers that.
The last substantive item is a single claim of Cagan's about where transformations begin. Organizations already led by engineering are the easiest to move toward the product model, because engineering already commands organizational attention and investment. The contrast case is the organization that outsources engineering entirely: it has no internal foothold of that kind, and has to build credibility for the function from scratch before the model has anything to stand on. See Engineering-Led Orgs Are the Easiest Transformation Path.
The practical use is diagnostic rather than prescriptive. When assessing how hard a transformation will be, check whether engineering is in-house and already influential — the body's framing is that this is a head start, not a coincidence. What the claim does not come with, in this chapter, is a worked case, a measure of what "already influential" means concretely, or any discussion of what an engineering-led org might be worse at. The antipatterns, the trust mechanics, and the company narratives that would test it are in Transformation in Practice; the definition of the model this is a transformation toward is in The Product Operating Model. Read alone, it is one asserted mechanism, and that is all it is.
Which is a fair note on which to close the chapter as a whole. This is a holding area, and what's in it varies in maturity: Doshi's clarity thesis and Olsen's Kano model are complete arguments that could carry a chapter of their own, Verrilli's T-shape and the PRD/kickoff discipline are practices stated at working length, and the Deutsch lens and the engineering-led claim are single positions cited without elaboration. None of them are filler — but only some of them are finished, and the reader should know which is which going in.
2026-08-28
On 2026-08-24, Salesforce launched Slack Code, betting that AI coding should happen as a visible, multiplayer activity inside a team's existing chat workspace — letting anyone tag Claude Code, Devin, GitHub Copilot, ChatGPT, or a Vercel agent into a project channel with a plan view, line-by-line diff view, and live preview, with a human still signing off before anything ships — rather than as a faster single-developer tool, the model Cursor, Replit, and GitHub Copilot Workspace are mostly built around; GitHub's own CPO conceded the workspace, not the editor, may end up deciding this. Just three days later, Salesforce and Anthropic announced 'Claude Force,' making Claude the default model across the Slack/Salesforce stack (powering Slackbot and Claude tag, plus 37 pre-built sales skills), undercutting Slack Code's framing as a neutral multi-agent platform even though Copilot and ChatGPT remain nominally supported — suggesting the competitive question has shifted in about six months from 'which model do I call from the terminal' to 'which platform owns the shared workspace where a team works with agents.' The launch lands against Salesforce's rough year (stock down 5% YTD, OpenAI hiring away Slack CEO Denise Dresser) and a security picture that complicates the pitch: Veracode's 2026 report found roughly 44% of AI code-generation tasks introduced a real exploitable vulnerability despite commit velocity rising three to four times, the 'illusion of correctness' problem where AI code looks too finished to double-check, and Cognition's own prediction that mandatory human approval on every merge will likely disappear within a year — casting doubt on how durable Slack Code's 'a human still signs off' safeguard actually is.
2026-08-24
Simonetta Batteiger's talk "Don't be an a**hole!" argues that as agentic AI takes over more of product creation, teams can no longer just avoid harm — they must explicitly codify what trustworthiness means, pairing character (integrity, intent) with capability (delivered results), because left unspecified, agents default to "the average," producing slop, hallucinations, and sycophancy. She anchors the argument in Starbucks South Korea's AI-assisted "Tank Day" marketing failure, which referenced a violent historical crackdown and coincided with a 26% one-week revenue drop (~$580M annualized against $2.1B in regional revenue) — reframing trust as a quantifiable business risk, not just an ethical one. She draws on Stephen Covey's Speed of Trust (character + capabilities), Martin Eriksson's decision stack (vision, strategy, goals, principles), Akshay Kore's five-dimension trustworthy-AI framework (explicable, transparent, non-biased, privacy-centered, beneficial to society), and the EU AI Act's four dimensions (human autonomy, harm prevention, fairness, explicability) as governance references, proposing "trust over short-term gain" as a foundational principle for agentic co-creators. Concrete design patterns illustrate the point: a radiologist workflow where AI only flags disagreement with the doctor's own diagnosis (preserving skill rather than replacing it), a hiring system (talent.com) that treats excluding bias-proxy data like zip codes and commute time as a sellable product feature rather than a constraint, and Ecosia's choice not to force AI summaries — which reportedly grew its US user base 40% while Google pushed AI-forward defaults. She also flags emerging needs — agent identity verification (citing early government work in Estonia and Saudi Arabia), rate limiting and supply-chain transparency for agentic buyers, and a full-stack trust-by-design framework (attributed to "Prompt Ledger") spanning authorization, identity, consent, recourse/kill-switches, and logging — though some of these references are named without elaboration, more pointer than fully worked-out source.
2026-08-24
A widely-discussed keynote from the Lenny & Friends Summit 2024, 'Product Management Is Dead, So What Are We Doing Instead?', argues that product management as a separate discipline is ending, with AI collapsing product, design, and engineering into a single generalist role — the 'AI-powered Triple Threat' — that is displacing the traditional Product Triad by leading a team whose other members are AI tools and agents rather than human specialists. The speaker frames this as already underway rather than speculative, citing her own before/after story (dictating a 10-page product strategy to ChatGPT voice mode in a minivan, matching what once took weeks) and an anecdote about 'Cody,' an engineer/marketer who used AI to move fluidly from PM to designer to frontend engineer whenever blocked by a handoff. She prescribes a three-part model for individual PMs — automate yourself, add adjacent skills, then multiply impact by teaching the team — anchored by an 'anti-to-do list' of tasks (drafting docs, status updates, meeting summaries, OKR/competitor tracking, interview prep, etc.) that should be automated rather than done by hand, a personal heuristic of spending 4–7 minutes attempting to automate any recurring task, and a reframe from 'reach 100%' to 'get to 75% faster than starting from zero.' She argues product leaders aren't exempt: team topology should be built around unusually broad individuals rather than a fixed Triad template, R&D budgets need to blend headcount with AI agents/tools, and leaders themselves face commoditization — citing a Lenny's Newsletter test where evaluators preferred an AI-generated product strategy over a human one even knowing its source — so leaders need to build a differentiated 'moat,' such as mastering how to run AI-powered teams, and to proactively identify and empower the AI-powered triple threats already inside their organizations.
2026-08-24
In a quick-take video responding to a viewer question about disagreements with Marty Cagan's comments on Lenny's Podcast, Dan Olsen (author of The Playbook, which he frames as a how-to complement to Cagan's principles-focused Inspired/Empowered/Transformed) argues that the common 'pipe dream' reaction to Cagan's best-practice descriptions of product teams is less a factual disagreement than a discouragement effect caused by the size of the gap between an aspirational ideal and someone's lived 'feature factory' experience; positioning himself as a realist and pragmatist from his own time as an interim VP of product 'in the trenches' fighting to convert dev teams and stakeholders to the right way of working, Olsen grants 'a little bit of legitimacy' to the deeper critique that a CPO has far more capital to change an org than an individual PM, APM, or senior PM does, for whom trying to steer the whole organization is 'like steering the Titanic' — but he ultimately defends Cagan's actual position as already accounting for this, since Cagan's real advice is to try to change the org and, if you can't, 'maybe you need to go somewhere else,' a stance Olsen endorses by adding 'Life's too short' to stay somewhere you can't practice your craft properly.
2026-08-24
In a 2026-08 conference-recap interview ('A deep dive into the state of product in 2026'), Emily Tate (VP Product) argues that the AI inflection point has flipped the historic product bottleneck: building is now cheap and fast enough (Lovable, 'cloud code') that anyone can clone a product's surface in a weekend, so deciding what to build — and possessing customer-grounded, cross-market experience — is now the scarcer, more defensible asset than 'having AI' itself ('AI is not a product in itself'; positioning as 'AI first' can even be a liability outside tech, where AI reads as decades-old automation people already dislike). She's skeptical that the do-it-yourself narrative (everyone building their own tools) threatens packaged SaaS, since most buyers — her 'mom' example — don't want to manage their own integrations regardless of technical feasibility, and warns that productivity gains from AI tend to get reinvested into higher output expectations (build 2-3x more) rather than reclaimed as time or creative space. She predicts roughly 12-18 months more of AI experimentation before team ratios and workflows settle, and separately flags Eric Ries's book 'Uncorruptible,' which argues standard governance and IPO mechanics strip the 'special' quality out of once-loved companies (citing REI, Patagonia, and John Lewis as resistant ownership models). A recurring secondary theme is protecting the human, joyful side of work — she attributes rising day-to-day team friction partly to remote work removing informal in-between-meeting moments, offers conference/speaking advice (pick one or two resonant talks; start at a local Product Tank meetup and 'be yourself' rather than imitate other speakers), and notes that in legacy non-AI-native organizations, product people often get more traction by dropping product jargon and just doing the work than by 'teaching' methodology.
2026-08-24
Rags Vadali (founder, Floto), interviewed in 'The document that can replace PRDs' (https://www.youtube.com/watch?v=wMwrPT4rHDA), argues that once you're building an agent, the real product to define is the experience layer on top of it rather than the UI, and because AI-accelerated engineering has outpaced PM planning ('I don't know what I don't know'), Floto has inverted the classic flow: engineers now prototype straight from a problem statement using parallel Claude Code agents (a 3-person team can run 2-3 products in parallel, discarding 50-60% of what gets built), and only after a prototype exists does Rags craft a Product Experience Document (PXD) — Why → Success Criteria → Experience Principles → Critical Moments → Conversation Closing → Success Metrics — whose 'Experience Principles' section is fed straight into Claude to generate the build/tuning prompts engineers use. Because agent behavior is non-deterministic, the PXD specifies ranges of good/bad/unwanted answers rather than fixed requirements, defines explicit 'breakpoints' where the agent abandons its current goal-pursuit to dig deeper on something serious, and treats conversation-closing design as a habituation lever even though it can't affect the current session. Discovery fundamentals haven't shifted — Rags still traces every resonant feature back to talking to real users, via Perplexity-mined Reddit/G2 threads and Floto's own feedback-agent product used on its own users — but he's found synthetic personas trustworthy only for early-stage, negatively-framed questions (positive framing triggers the model's please-the-user bias, and personas hallucinate 'on the edges'). He flags this PXD-first approach as a poor fit for UI-heavy products (where he still prefers a Figma-first design session), expects a coming 'reckoning' back toward deliberateness as AI-built feature bloat accelerates industry-wide, and plans to make product sense a required interview component for every hire since specialization boundaries are being short-circuited.