How I use AI after a product review with senior executives

I capture the decisions and the options we rejected, and my AI won't let me quietly reopen them.

In March, I sat in a product review with my executive leaders and watched them take apart a product mock for a 0-1 product I had spent weeks on. They were not unkind about it. They just kept pointing at the screen and saying what they actually saw, which was not the value I thought I was delivering.

They said things like “the value didn’t jump out” and “I’m reading metric definitions instead of seeing the point.” Over about an hour they said a dozen specific things about what was wrong and what they’d want instead.

The old version of me would have walked out with a page of notes, written a tidy summary that afternoon, and let it slowly go stale. The summary would say what the meeting was about, but it would not change what we built two months later.

This time I did something different. I fed every sentence they said into Claude, close to verbatim, and asked it to help me turn the verbatim into a small set of decisions rather than a summary. Each decision was written the same way: here’s what we decided, here’s why, and here are the options we rejected and the reasons / principles on why we rejected them.

Those third and fourth fields, the rejected options and the reasons for rejection, ended up mattering most, though it took me a few weeks to see why.

The raw input is the executives’ actual words, not my paraphrase of them. In most cases, paraphrases are where the signal leaks out. When I write “they wanted the overview to be strategic,” I’ve already smoothed off the specific thing they said, which was that the highest-value view should lead the page and everything operational should sit under it. The verbatim version keeps the edge. So step one is just capturing what was said, precisely, and handing that to the AI as the source material.

During that hour-long product review, we collectively made four key product decisions. One of them was about what the product leads with: we decided to lead with the view the executives actually care about, and we rejected framing it as another analytics dashboard, because that puts us right next to the incumbent everyone already benchmarks against. The rejected option is written down with the same weight as the chosen one, and that turned out to matter a lot in my later decisions.

I’d initially kept the rejected-option field for the sake of completeness, the kind of thing you write but never read.

I then set up my Claude so that every future AI session I run on this product preloads this decisions file by default. It’s the first thing in the project’s context. So when I open a new session in June and start exploring a specific direction, and that direction happens to be something we already killed in March, the AI stops me right there. It tells me we rejected this option, on this date, for this reason.

Without the “alternatives rejected” field, that doesn’t happen. The AI only knows what we chose, so it cheerfully re-proposes the thing we already threw out, and I lose an afternoon rediscovering why it was a bad idea the first time. With the field, the closed questions stay closed. The meeting stops being a memory I have to defend in every new conversation and starts being a constraint the system enforces for me.

I initially built the decisions file as documentation, but now I use it as a way to keep me and the AI from reopening settled questions.

Six months on, nearly every decision in that product file traces back to that one hour in March. Not because the executives changed my mind in the room. They didn’t, entirely. I pushed back on a couple of things and still think I was right. It’s that the verbatim notes made their reasoning clear enough to build on, and the decisions log made it survive past the meeting.

So here’s what I’d suggest to anyone doing initial 0-1 product discovery work. After your next important meeting, don’t write a summary. Write the decisions as a numbered list, and for each one write down the option you chose or rejected and the reason or principle behind that decision. Then put that file somewhere your AI reads it at the start of every session, not in a doc you’ll open twice and forget.

The loop keeps running. Every executive review since March appends a few more numbered decisions with their rejected alternatives, and the next session loads all of them.

The next thing I’m testing right now is whether the same loop holds up for customer calls, where the signal is messier and the person doing the talking isn’t the one who sets the priorities. I’ll write that up once I’ve run it a few times.

I’m curious how other people are doing this. If you’ve changed how you work with AI, tell me what stuck.