Most conversations about artificial intelligence and the product manager begin by asking whether the role survives. This one begins somewhere more useful: by asking what the role was ever actually for.
In this episode of On the Subject of Leadership, I speak with Ken Sandy—author of The Influential Product Manager, a longtime executive coach to founders and chief product officers, and an adviser to boards.
His argument is not the consoling one. The documents, specifications, and roadmaps that product managers are most often judged by, he contends, were never the work. They were the residue of the work. The work was always the influence—the grounding in evidence, the advocacy for the customer, the patient assembly of agreement among people who do not report to you. If that is right, then the arrival of tools that can draft a specification in seconds is not so much a threat to the discipline as a solvent applied to it: it dissolves everything that was never essential, and leaves the essential in plain view. The discomfort, of course, is that a good deal of what the profession has spent twenty years rewarding turns out to be residue.
What follows are the ideas from the conversation I have continued to think about since.
The Inversion at the Centre
The Influential Product Manager began, Ken explains, with a throwaway phrase that everyone in product repeats and no one examines: the role is all responsibility and no authority. Rather than accept it as a complaint, he treated it as a question. What is influence, exactly, and where does it actually operate?
The answer he arrived at inverts the usual reading. The absence of authority is not a handicap the product manager must work around. It is the very thing that disciplines their judgement. A leader who can compel compliance can afford to be wrong, lazy, or self-interested; the directive will be followed regardless. A leader who can only persuade can afford none of those things. They must be grounded in the data, genuinely close to the customer, and visibly free of private agenda, because persuasion is the only instrument available, and persuasion collapses the moment its audience suspects manipulation. Having no authority, in other words, forces a higher standard of reasoning than having authority ever would.
This is more than a motivational reframe. It maps precisely onto the oldest taxonomy in the study of power. In their 1959 analysis of the bases of social power, John French (1913–1995) and Bertram Raven (1926–2020) distinguished the power that flows from position—legitimate, reward, and coercive power—from the power that flows from the person: expert power, referent power, and what Raven later termed informational power. Formal authority draws on the first set. Influence, in Ken's sense, draws entirely on the second. The product manager, denied the positional levers, is compelled to build a base of expert and informational power instead—which is to say, compelled to actually know what they are talking about. A refreshing capability in a corporate landscape in which talking and gnosis are rarely linked.
The Discipline of Constraint
The same logic runs through Ken's treatment of constraint more generally. The reflexive posture of the frustrated manager is that progress is gated by scarcity—of budget, of headcount, of time—and that the task of leadership is to unlock more of it. Ken calls this learned helplessness, and he is right to. Every request for more resource is a demand that resource be taken from somewhere else; the executive who appears to dispense it freely is simply making a prioritisation decision the requester cannot see. Constraints, in this context, are not an obstacle to the work; they are the condition of it.
What constraint produces, taken seriously, is the obligation to prioritise—and prioritisation, honestly done, is the core managerial act. Herbert Simon (1916–2001) made the point more than half a century ago, in 1971, and it has only sharpened since: in a world rich in information, the scarce resource is not information but the attention required to act on it. The manager who understands their boundaries need not refuse the stakeholder's request outright; they need only be able to say, with evidence, that something else is the more valuable use of a fixed quantity of attention right now. The articulate management of limits, Ken argues, is more effective than the fantasy of their removal. It is also, not incidentally, more honest.
Renewal Is Subtraction
It was this conviction that lay behind the deliberately binary question Ken once put to a conference audience, and which prompted our conversation: name one skill product managers must master for the future, and one that will become irrelevant. The binary, he explains, was not a rhetorical trick but a coaching technique. Forced-choice exercises are uncomfortable precisely because they prohibit the evasion that open questions permit. Ask people what skills matter and they will cheerfully add to an already impossible list. Require them to name what they will give up, and you learn what they actually believe.
Understood this way, renewal and growth are not always a matter of learning new things, but of forgetting the right ones. The organisational theorist Bo Hedberg gave this idea a name in 1981—unlearning—and argued that organisations are often prevented from adapting no so much because of sheer ignorance of the new—technology, process, product—than they are by their attachment to the old. Ken's view is that product management in particular has over-invested in documentation and elaborate frameworks, on the mistaken assumption that complication signals value. In operating reality, it rarely does. Simplicity, as he puts it, is hard, and usually enough.
There is now experimental support for the suspicion that we are systematically poor at this. In a 2021 paper in Nature, Gabrielle Adams and colleagues demonstrated that when people are asked to improve something, they overwhelmingly reach for additions and overlook subtractions, even where removing an element would plainly serve the situation better. We are, in Ken's phrase, an additive society—and AI, by making it trivially easy to add, has made the bias more dangerous, not less. The discipline that will distinguish good product work from bad, he suggests, is increasingly the discipline of removal: killing the feature that is not earning its place, and resisting the deployment that is possible merely because it is now easy.
The Ceremony of the Artifact
If the artifacts were always residue, why do managers cling to them so fiercely? Ken offers a diagnosis drawn from direct observation. Working with a client whose every initiative had to pass through an exhaustive twenty-page document, he asked the obvious question: who reads these? The answer, from almost everyone—including the leaders demanding them—was that virtually no one did. Only the risk team read them, and only in part, skimming for evidence that the right issues had been considered.
This is not irrationality; it is something more durable. In their foundational 1977 paper, John Meyer and Brian Rowan described the way organisations adopt formal structures and procedures not because those procedures improve the work but because they confer legitimacy—they signal that things are being done properly. The structure becomes ceremony, decoupled from the actual production of value. The twenty-page document is precisely this: a rite that reassures, performed long after anyone believes in its contents.
Ken's cartoon captures the AI-era version exactly. A product manager, delighted, uses AI to generate an entire stakeholder deck in half an hour; the stakeholder, equally delighted, uses AI to summarise it back down in thirty seconds. The ceremony has been fully automated, and its emptiness fully exposed. The opportunity, as Ken sees it, is not to perform the ritual faster but to abandon the parts of it that were only ever ritual—and to protect the part that was never the artifact at all. As Eisenhower is supposed to have said, plans are worthless, but planning is everything. The value was never the document. It was the thinking the document recorded.
Knowing When the Machine Is Wrong
This is where Ken locates the central risk of the moment, and he names two anti-behaviours. The first is using AI to produce the deliverable while skipping the thinking the deliverable was meant to represent. The output looks the same; the reasoning behind it has evaporated. The second he calls feeding the beast: the product manager, newly able to race ahead alone—drafting, prototyping, even deploying—does so in isolation, severing the collaboration with engineering and design through which problems were genuinely understood.
The first of these has a distinguished pedigree. In her 1983 essay Ironies of Automation—written about cockpits and control rooms, but eerily apt for the present—Lisanne Bainbridge observed that automating the routine elements of a task leaves the human in the loop responsible for exactly the things the automation cannot handle: the novel situation, the exception, the judgement call, the true act of creation. However, this freedom is often bought at a heavy price because automation erodes the very activities the human in the loop needs needs to exercise that judgement, and to recognise when the machine has gone wrong. Ken's warning is the same one, albeit transposed to an organisational setting. AI is increasingly reliable on what already exists in its context and unreliable at the edges—the new customer, the unfamiliar segment, the genuinely differentiating solution. If you have outsourced the thinking, you will not notice when it fails, because you will have surrendered the capacity that noticing requires.
The Questions Boards Are Not Asking
On boards and NEDS, Ken's observation, drawn from advising directors in Australia and the United States, is that boards are largely asking the wrong question about AI. They ask how the data is being locked down and the risk contained—a reasonable question, asked in an unreasonably narrow spirit. The better question, he argues, is how the organisation is using the technology to get more from its data and its decisions while managing the risk. The difference is between a posture of defence and a posture of opportunity.
This is, at root, the oldest tension in corporate governance. Bob Tricker—whose framework Australian directors meet in their own institute's training—distinguishes the board's conformance role, concerned with compliance, monitoring, and accountability, from its performance role, concerned with strategy and forward direction. The research tradition associated with Amy Hillman and Thomas Dalziel makes the same point in different language: boards both monitor management and supply it with resources and counsel. A board that has collapsed entirely into conformance has abandoned half its purpose. Ken's complaint is that, on AI, too many boards have done exactly that.
The remedy he proposes is bracing and personal. Directors should be able to speak credibly to a use of the tools in their own working lives—even something as modest as using AI to interrogate the papers they are sent and surface the questions they ought to be pressing. A board, he suggests, has historically been able to count a meeting a success if it escaped without hard questions. In the age of AI, that approach is precisely what a board should not do.. The board's job is to ask the dangerously hard question—if this capability exists, why are we not using it?—and a director who has never touched the technology cannot ask it, because they do not know it is there to be asked.
Risk, Uncertainty, and the Probabilistic Product
Beneath the governance discussion sits a distinction Ken draws with unusual clarity, and which deserves to be understood in every boardroom. Traditional software is deterministic: complicated, perhaps, but predictable, such that a given input yields a knowable, and consistent, output and a defect can be reproduced and fixed. AI-based products are probabilistic. The same customer, returning to the same product, may travel an entirely different path, because the system's context has changed and it is making fresh determinations as it goes. The behaviour cannot always be repeated, and a fault cannot always be reproduced.
The economist Frank Knight (1885–1972) drew the relevant line more than a century ago, in 1921, between risk—which is measurable, with a knowable distribution of outcomes—and uncertainty, which is not. Deterministic systems are, in this sense, governable as risk. Probabilistic systems introduce something closer to genuine Knightian uncertainty into the product itself, and this is why, as Ken notes, so many AI initiatives stall between pilot and scale. What worked acceptably across a small cohort carries unknowable consequences across a million users, and the usual machinery of testing cannot fully retire the doubt. His prescription for boards is correspondingly specific: ask not only how the risk is being contained, but what evaluation is in place—before deployment and continuously after it—to catch the adverse outcomes that a probabilistic system will inevitably, if unpredictably, produce.
Intent, Not Permission
The conversation's most quietly radical idea arrived in the lightning round, by way of the underrated book Ken nominates: David Marquet's Turn the Ship Around! and its doctrine of intent-based leadership. Ken's discomfort, long-standing, was with the two conventional options available to someone acting without authority. One can ask forgiveness rather than permission—but this burns trust asymmetrically, and the cowboy is tolerated only until they are not. Or one can route every decision up the chain—but this is not merely slow; it corrodes accountability, because the person who escalates has quietly surrendered ownership of the outcome.
Marquet's resolution, which Ken has adopted, is to communicate intent. One neither asks permission nor acts unilaterally; one states clearly what one intends to do and when, gives the rationale, and leaves a genuine window for anyone with a real objection to raise it. Momentum is preserved without trust being spent. This is, in the language of Robert Simons' work on control, the operation of a boundary system: the leader does not specify the action but defines the limits within which action is free. Ken's finest illustration is a story from his time as interim chief product officer of a fearful, stalled social network. Rather than litigate every feature with an anxious chief executive, he negotiated three measurable thresholds—on revenue, engagement, and retention—within which the team would be left entirely alone, and beyond which it would stop, roll back, and investigate. The product, blocked for nearly two years, shipped in three months. The thresholds were never breached.
The deepest point in that story is a refusal of outcome bias. Ken declines to claim, as his best decision, a feature that drove revenue, because success one cannot explain is not success but luck—and luck is not a repeatable mechanism. The psychologists Jonathan Baron and John Hershey named this failure in 1988: the tendency to judge a decision by how it turned out rather than by whether it was sound. The decision Ken is proud of is the one that was defensible in advance—that converted a leader's diffuse fears into measurable objectives, and in doing so freed a paralysed team to move. That is what good judgement looks like when it is working, and it has nothing to do with whether the result was fortunate.
A Practical Account of Leadership
Ken Sandy is not selling a methodology, and this is not, in the end, a conversation about product management. It is an account of what leadership requires when the scaffolding is removed—when you cannot compel, when the artifacts no longer prove anything, and when the tools meant to save you can as easily think for you, badly, without your noticing.
What he offers is not a method but a set of dispositions. Treat the absence of authority as a discipline rather than a grievance. Take constraint as the condition of good work, not the enemy of it. Practise subtraction; renewal is as much forgetting as learning. Protect the thinking that the artifact was only ever a record of. Keep the capacity to know when the machine is wrong. Ask, of any technology, where the opportunity lies before asking where the risk hides—and never govern what you have not personally touched. Define the boundaries, and let the team run inside them. And judge your decisions by whether you can explain them, not by whether they happened to work.
If you lead a product organisation, sit on a board contemplating its AI posture, or simply want to hear the discipline of product leadership discussed without slogans, this is a conversation worth your full attention.
Good night, and good luck.