← All work

Product practice

Using AI Without Outsourcing Product Judgment

AI can make an answer look finished before the thinking is finished. Product judgment is the work of knowing when to keep questioning it.

2026 · AI-assisted product leadership

A product professional works at a laptop while other professionals in different settings view similar AI-assisted diagrams, framing the question of how judgment makes the work one's own.

The first time I used AI seriously on a senior product take-home assignment, the unsettling part was not that it performed badly. It was how quickly it performed well.

I was entering an unfamiliar cybersecurity domain, and within a relatively short time I could map terminology, identify useful sources, explore different interpretations of the problem, simulate conversations with relevant stakeholders, and start turning all of that into a coherent product story.

That was clearly useful. It was also a little uncomfortable.

If I could get to something this polished this quickly, how could I be sure I was actually on the right track? What was I missing? Would other candidates using the same tools arrive at roughly the same conclusions? And which parts of the answer were genuinely mine?

Those questions stayed with me. Over several assignments, they gradually changed the way I use AI. I became more willing to use it aggressively for research, exploration, critique, and presentation, while becoming more disciplined about the parts I would not hand over.

The principle I arrived at is simple:

AI can make an answer look finished before the thinking is finished. Product judgment is the work of knowing when to keep questioning it.

When a complete answer is not complete

That first assignment gave me an early warning.

I was using AI to understand a technical framework, map it against existing product capabilities, and identify possible opportunities. An early pass looked reassuringly complete. Whole areas appeared to be covered.

Then I started checking the conclusions capability by capability.

The picture became less tidy.

In some cases, underlying functionality existed, but that did not mean the product fully satisfied what the framework actually required. Areas that had looked complete were really partial. Some claims were stronger than the evidence supporting them. And even when a gap was real, that did not automatically mean it belonged on a product roadmap.

Nothing in the initial analysis looked obviously wrong. That was precisely what made it dangerous. It used the right language, had a convincing structure, and looked like something I could build a recommendation around.

But when I changed the question slightly, went back to the underlying sources, or asked exactly what evidence supported a conclusion, some of that certainty stopped holding together.

The lesson was not that AI was unreliable and therefore unhelpful. Quite the opposite: it had accelerated a difficult piece of work substantially.

The lesson was that fluency is not the same as robustness.

An initial capability map that appears complete is challenged by partial support, capability not equaling requirement, and insufficient evidence; closer scrutiny produces a more nuanced view and a verified gap still does not automatically become a roadmap priority.
Source-derived reconstruction: closer scrutiny turned an apparently complete view into a more nuanced one; a verified gap still did not automatically become a roadmap priority.

That distinction felt familiar from product work long before AI entered the picture.

Over the years I have worked with customers who were absolutely certain about what they wanted. Sometimes they were right. Sometimes they were describing a symptom rather than the underlying problem, or were so close to the way things worked today that another interpretation was difficult to see.

Good discovery does not mean recording the first confident answer and turning it into a roadmap. You ask differently. You test the framing. You look for contradictions. You bring in another perspective and try to understand the outcome behind the requested solution.

I found myself applying the same instinct to AI.

A confident answer can be useful input. It is not the end of discovery.

Turning the instinct into a method

After that assignment, I started recording what had worked instead of rebuilding the process from scratch every time.

That is partly just how I work. I tend to bring structure to messy problems. But AI made the need for that discipline much more visible.

A model can move away from an earlier decision, reopen something already settled, forget why a constraint mattered, or offer a new plausible direction without preserving the reasoning that led me to reject it the first time. The faster the work became, the easier it was for those shifts to disappear inside the flow of the conversation.

My response was not simply to write better prompts. I started making the reasoning more explicit.

Over repeated assignments, I eventually compressed the working process into five useful phases:

Learn → Frame → Decide → Challenge → Defend

I use AI broadly across all five. It helps me enter unfamiliar domains, navigate sources, compare interpretations, role-play stakeholders, generate alternatives, attack assumptions, improve the story, and rehearse the eventual discussion.

But the important boundary runs through the whole process.

I still decide which sources deserve trust, what problem is actually worth solving, which customer or use case matters most, what belongs in scope, what should explicitly be left out, and which recommendation I am prepared to defend.

Simulated stakeholders can help me discover better questions, but they are not customer evidence. A technical framework can reveal gaps, but it is not a roadmap. A plausible recommendation can survive several rounds of critique and still remain an assumption until the evidence is strong enough.

AI can widen the search space dramatically.

The narrowing is still mine.

AI broadens exploration across sources, framings, perspectives, options, and critique; product judgment uses evidence, experience, and context to decide what matters, what not to do, and what can be defended.

The next assignment was different

By the next substantial assignment, I was no longer discovering this way of working as I went. I was deliberately reusing it.

The problem itself was different, but I began with a process I already trusted: learn the domain, test competing framings, make assumptions visible, use simulated perspectives to challenge the work, choose a direction, and prepare to defend it.

The process had also become more disciplined. I was preserving decisions instead of allowing every new iteration to renegotiate them from scratch.

What surprised me was that this discipline did not make the work less creative. In practice, it made me more comfortable using AI creatively because I had clearer control over what that creativity was allowed to change.

One example came from the presentation itself.

I wanted a memorable way to explain a product idea about helping users orient themselves before the system had complete information. We explored possible names and metaphors until we found a direction that reinforced the product idea rather than simply decorating it.

The hook worked because the metaphor carried the same logic as the product: incomplete visibility did not mean there was no useful action to take. It gave the audience a simple way to remember a more complicated product argument.

That was deliberate product communication. A presentation is not only a container for correct analysis; it also has to make the important idea clear enough to survive after the slide is gone.

But the same creative process exposed another boundary. As we developed the visual language, there were moments when the metaphor started becoming too literal and risked suggesting behavior that was not actually part of the product concept.

At that point I pulled it back.

AI had helped amplify the idea. Product judgment still determined what the idea was allowed to mean.

That assignment was important because the method proved reusable. More than that, it showed me that the goal was not simply to get good answers from AI. I needed a way to govern a complex piece of work with AI inside it without losing control of the reasoning underneath.

Building an AI Canon

Over time, that decision discipline became what I now call an AI Canon: a persistent record of the assumptions, evidence boundaries, accepted decisions, constraints, rejected directions, and things that should not silently change.

The underlying habits are not new. Product work has always relied on source-of-truth documents, decision logs, explicit assumptions, retrospectives, and recorded trade-offs.

What changed for me with AI was the reason to use those habits more deliberately.

A model can produce another plausible version of almost anything. Without some persistence outside the immediate conversation, it is surprisingly easy to revisit a question without remembering why the previous answer was rejected, or to change one part of the work without noticing which earlier decision it depended on.

AI Canon gives the work memory.

It is not intended to freeze thinking. New evidence should change a decision when it deserves to. The point is to make that change deliberate: know what changed, why it changed, and what else the new decision affects.

That has become useful well beyond take-home assignments. The more complicated the AI-assisted work, the more valuable I find it to separate the model’s ability to generate another possibility from my responsibility to decide whether that possibility should replace what came before.

What makes the work mine

That brings me back to the question that bothered me in the first assignment.

If increasingly capable models are available to everyone, how do I make sure the work is actually mine?

I no longer think the answer has much to do with whether I manually wrote every sentence, drew every diagram, or generated every alternative myself. That is becoming a less useful distinction.

For me, ownership sits in the judgment applied to the material.

What question did I decide was worth answering? Which evidence did I trust, and why? What did I reject? What did I choose not to build? Which trade-off did I accept? Where did I leave uncertainty visible instead of smoothing it into false confidence? What would make me change my recommendation?

And ultimately, can I still defend the reasoning when the model is no longer part of the conversation?

That is also where I think distinctiveness survives.

Several candidates can use the same models and produce competent-looking research, frameworks, slides, and feature ideas. They do not necessarily ask the same questions, notice the same weak assumptions, reject the same attractive distractions, or make the same product call.

AI lets me explore more territory and challenge my thinking harder than I could before.

It does not decide which answer I am willing to own.

From method to product

After repeating this process enough times, another pattern became visible. The reasoning itself was becoming increasingly structured, while the working environment around it was still fragmented.

That eventually led me to build Takehome Studio, a separate product experiment around parts of this workflow. That is a different story.

The important point here is that the product came after the method had already proved reusable.

AI made the work faster, broader, and in some ways more creative. It did not remove the need for product judgment.

It made the places where judgment matters much harder to ignore.

Deeper resource

Explore the deeper case study and evidence

Open case study on GitHub

Continue the conversation.

For a conversation about a product, a system, the work here, or a selected leadership opportunity.

Expanded article figure