What Happened When I Started Using AI Every Day

Writing faster revealed something about how I actually think.

One thing AI hasn’t changed is accountability. If a stakeholder asks why a requirement exists, why a recommendation was made, or why a particular decision appears in a document, the answer still belongs to me. AI can help me produce the work, but it can’t take ownership of it.

I thought I understood that when I started using AI tools in my daily product work. Then I wrote a requirements document that took 22 minutes to create and four weeks to align.

The 22 minutes were new. I had been using Claude in my daily product work for about six months and had the process down: rough context notes, a structured prompt, a reviewed draft. What used to take two hours took under half an hour.

The four weeks were not new. That was a familiar number for a stakeholder review on a CPQ pricing rule, the kind of work that crosses RevOps, engineering, and finance before anything gets signed off.

I had expected AI to help with that part too. Faster writing was supposed to mean faster alignment. After all, if everyone could get to the same document sooner, surely they could get to the same decision sooner as well. Looking back, that assumption reveals what I thought the problem was. I had assumed that the document itself was the bottleneck. It wasn’t.

The review dragged on because four different teams came back with four different readings of the same section. The document itself was clear and well organised.

The problem wasn’t the writing. The problem was a decision hiding in the middle of it: which pricing rule should win when two bundle conditions applied at the same time.

The catch was that nobody had actually settled that question. I had assumed it had already been decided because it looked settled from the outside. The teams had been working with these pricing rules for months, and I never stopped to ask whether the underlying decision had actually been made.

The document presented that assumption as if it were an agreed answer, and it looked convincing enough that I didn’t catch the difference. Four weeks of review was the price of discovering that the decision still hadn’t been made.

What writing slowly had been doing

When I wrote a requirements document without AI, the process took about two hours. Looking back, those two hours were doing more than helping me write.

I would start with a rough outline and begin filling in the details. Then I’d hit a point where I wasn’t sure who owned a decision. Or I’d realise I was relying on something I’d never actually confirmed. I’d leave myself a note, send a message, create a ticket, or schedule a conversation. Then I’d return to the document and keep going until I found the next gap.

The pauses were annoying, but they were useful. They forced questions and alignment conversations to happen before the document was finished, not after it had already been shared.

With AI, most of those pauses disappeared. I could give Claude a dump of notes, get back a well-structured document, review it, and send it. The document looked complete. It looked like everything had been thought through. But the unanswered questions hadn’t gone away. They were still there, just harder to see.

I’ve come to think of AI as a tool that can make unfinished thinking look finished. When I’m writing slowly and I’m unsure about something, I usually feel it. I hesitate. I stop. I rewrite a sentence three times because I can’t quite explain it clearly. That discomfort is often a signal that I need to dig deeper.

AI doesn’t feel that discomfort. It takes whatever I give it and turns it into clear, polished language. If my thinking is incomplete, the writing can still sound confident. The result is a document that reads as though the answers exist, even when some of the questions haven’t been resolved yet. This happened to me three times in two months before I recognised the pattern.

What I changed

I stopped using AI to write the first draft. Instead, I started using it to help me find what I hadn’t thought through yet.

Now, before I write anything that will be reviewed by stakeholders, I start with a page of rough notes. No structure. No formatting. Just a dump of what I know, what I’m assuming, and what I believe the decision is.

Then I give those notes to Claude and ask a simple question:

“What questions should I answer before I turn this into a document?”

I even built a custom “grill me” prompt for this purpose.

Most of the time, Claude comes back with six to eight questions. Some are obvious. Others make me stop and realise I’ve skipped over something important.

In the pricing-rule example, one of those questions might have been:

“You’ve said the enterprise-tier rule applies here. Is that a documented policy, or is it something the team has simply been assuming? And who is responsible for that decision?”

At the time, I wouldn’t have had a good answer. That was exactly the problem.

The question wasn’t exposing a gap in the document. It was exposing a gap in my understanding. I needed to resolve that before writing anything, not discover it three weeks later in a stakeholder thread involving four different teams.

Once I’ve answered the questions, I update my notes, fill in the gaps, and only then ask AI to help me create the document. The whole process now takes about 40 to 50 minutes instead of 22. On paper, that’s slower.

In practice, review cycles that used to take three or four weeks now take three to five days. When delays are caused by people interpreting things differently, spending an extra 20 minutes upfront is one of the cheapest investments you can make.

What I notice in other teams

I’ve noticed this pattern often enough that I now watch for it. A team adopts AI tools, and before long they’re producing more documents than ever. A PM who used to write five documents a week suddenly writes fifteen. At first, that looks like a productivity win.

Then the reviews start. Comments pile up. Stakeholders ask questions that should have been answered earlier. Documents come back for a second or third round of revisions. The writing is faster, but the conversations needed to reach agreement are not.

The teams that seem to get the most value from AI do something different. They don’t use it to produce more first drafts. They use it to challenge their thinking before the first draft exists.

They ask AI to point out assumptions, identify missing information, and surface questions they haven’t considered. Only after they’ve worked through those questions do they start creating the document.

Most AI demonstrations focus on the impressive part: turning a page of rough notes into a polished requirements document in three minutes. What’s missing is the part that matters most.

The useful work often happens before those three minutes. It’s the 30- or 40-minute conversation where assumptions get challenged, decisions get clarified, and unanswered questions get exposed. Skip that step, and the time savings can disappear later in the review process.

Three questions before any AI-assisted document

Over time, I found myself returning to the same three questions before asking AI to help me write anything that needed buy-in from other teams.

The first is simple: what decision am I actually asking people to agree to?

Most requirements documents, roadmap updates, and stakeholder summaries are really conversations about decisions. Sometimes that decision is obvious. Sometimes it’s hiding in the background. If I can’t explain it in a single sentence, there’s a good chance different people will read the document and come away with different conclusions.

The next question is usually the uncomfortable one: what am I assuming that I haven’t actually confirmed?

That’s often where the trouble starts. It’s also the part AI is most likely to make sound complete and convincing. If there’s a weak spot in my thinking, that’s usually where I’ll find it.

And then there’s the question that has saved me more time than any other: Who is likely to disagree with this, and why?

If I can already hear the objections in my head, I can address them before the document goes out. If I can’t, there’s a good chance I’m not ready to write yet. The disagreement will still show up eventually. It will just arrive later, in the review process, when changing course is slower and more expensive.

None of these questions are really about AI.

They’re the same questions good product managers have always had to answer. The difference is that writing used to force me to confront them. The slower pace of drafting gave uncertainty time to reveal itself. AI changes that.

When a polished document can appear in minutes, those questions don’t always surface on their own. I have to ask them deliberately before I start writing. AI can generate a document faster than I can develop an understanding of it. That’s the real risk.

If a stakeholder challenges an assumption, questions a decision, or asks why a recommendation was made, I need to be able to answer. Not because I wrote the document, but because I own the thinking behind it.

That’s what these questions help me do. They force me to engage with the ideas before they’re wrapped in polished language. Otherwise, the questions tend to reappear later in stakeholder reviews, project delays, and long comment threads.

I started using AI because I wanted to write faster. What I didn’t expect was that it would show me exactly where my thinking was still slow.

Eshaan Jain is Lead Product Owner for Salesforce/Vlocity CPQ at T-Mobile and a Forbes Tech Council member. He has 15+ years of experience building enterprise AI and CPQ systems at Amazon, T-Mobile, PwC, and Accenture.