AI as a Thought Partner

I picked up “The AI-Driven Leader” by Geoff Woods expecting another book about how AI is going to revolutionize everything and we should all be terrified or excited or both. Instead, I got something practical: a framework for treating AI not as a fancy autocomplete, but as a thought partner that can push your thinking further than you’d get on your own.

As someone who leads technical decisions and writes product specs regularly, the ideas in this book didn’t just make sense theoretically. They clicked because I’ve been living some of them without realizing it. Here’s what stood out.

[image: book cover of “The AI-Driven Leader” by Geoff Woods]

The core idea: you’re the thought leader, AI is the thought partner

The biggest concept Woods drives home is the relationship between what he calls the Thought Leader (you) and the Thought Partner (AI). This isn’t about AI replacing your judgment or doing your thinking for you. It’s about having something available 24/7 that can process your ideas, challenge your assumptions, and surface things you didn’t see.

Think about how you work with the best people on your team. You bounce ideas off each other. One person says “what about this edge case?” and suddenly you’re rethinking an entire approach. Woods is describing that same dynamic, except the other person is AI, and it can consider angles you simply don’t have the bandwidth for at 23:00.

The distinction he makes is that the moment you abdicate the Thought Leader role and just let AI drive, you end up with mediocre output. AI-generated content might be 50-60% of where you need it to be. That’s the starting line. Your experience, your context, your judgment is what gets it across.

What AI actually gives you

Woods outlines five use cases where AI shines as a thought partner. He frames them for business leaders broadly, but they translate directly to technical leadership:

Strategic Thinking — You throw an idea, AI returns it with angles you hadn’t considered. When you’re defining the technical direction for a project, AI can help you pressure-test your architecture decisions, question your assumptions about scalability, or surface alternative approaches you’ve dismissed too quickly.

Decision-Making — Instead of spending days gathering data and running scenarios in your head, you can feed AI the context and get structured analysis back in minutes. Not to make the decision for you, but to give you better inputs faster.

Content Creation — Drafting specs, writing technical proposals, putting together architectural decision records. AI doesn’t write the final version. You do. But it gets you from a blank page to a solid draft faster than staring at a cursor.

Idea Generation — When you hit a mental wall while working through a complex problem, instead of losing momentum, you can use AI to generate alternatives and non-obvious solutions you haven’t considered.

Analysis — Upload a dataset, a competitor’s API docs, a user feedback spreadsheet. AI can spot patterns that would take you hours to find manually.

[image: illustration showing the five AI use cases — strategic thinking, decision-making, content creation, idea generation, analysis]

The interview technique

Here’s the part of the book that resonated with me the most, because I’ve experienced this firsthand. Woods describes an approach where instead of just dumping a task on AI, you ask it to interview you — one question at a time — to gather the context it needs before producing output.

I’ve done this while writing product specs and technical documents. Every single time, AI asked me questions I hadn’t thought about. Not because the questions were brilliant in isolation, but because when you’re deep in a problem, you develop blind spots. You assume things are obvious because they’re obvious to you. The interview approach forces you to articulate assumptions you didn’t even know you were making.

Woods shares a story about a CFO at Bayer Indonesia who had been trying to develop an upskilling program for weeks, constantly hitting mental walls. Using the interview technique with AI, he collapsed weeks of scattered thinking into a clear decision in under thirty minutes. Not because AI gave him the answer, but because it asked the right questions to pull the answer out of his own head.

That’s the useful part. AI doesn’t know more than you about your domain. What it can do is compute across all the context you give it and ask the question you forgot to ask yourself. For anyone writing specs, defining features, or planning technical work, this matters.

Three personas

Woods introduces three AI personas you can use depending on what you need. I found these useful as mental models for framing prompts:

The Interviewer — Asks questions to uncover ideas you didn’t know you had. Good for when you’re starting a new feature spec and need to think through requirements. Ask AI to interview you about the problem space before you start writing.

The Communicator — Takes complex ideas and structures them into clear messages. Useful when you need to explain a technical decision to stakeholders who don’t share your context. You provide the substance, AI helps with the structure.

The Challenger — Plays devil’s advocate and pressure-tests your thinking. This is the one I reach for most. Before presenting a technical proposal, having AI poke holes in your plan from different perspectives is like having a preview of every tough question you’ll get in the room.

[image: diagram showing the three personas — Interviewer, Communicator, Challenger — and when to use each]

Prompt ingredients

One of the most practical parts of the book is what Woods calls the “ingredients” of a good prompt. He compares building a prompt to writing a recipe: the ingredients you include and how you combine them directly impact the quality of what you get back.

Describe the Task — Clearly state what you want AI to do, just like delegating to a team member. “I want you to evaluate this architecture proposal” is better than “look at this.”

Give Context — AI doesn’t have your human context. The more you provide, the better it can put itself in your shoes. Upload documents, describe the situation, explain the constraints.

Assign a Persona — Tell AI what role to play. “Act as a senior backend engineer reviewing this for scalability concerns” focuses the output compared to a generic request.

Specify Requirements — How do you want the output? Structured as a numbered list in order of priority? In a table? Concise or detailed? Tell it.

Establish Limits — Set boundaries. “Challenge the technical approach but don’t suggest rewriting in a different language” keeps things productive.

Ask It to Interview You — When you’re not sure where to start, ask AI to gather what it needs by asking you one question at a time. This works particularly well for complex, ambiguous tasks.

Two practical examples

Let me show you what this looks like in practice with two scenarios you’ve probably faced.

Example 1: Preparing for a technical lead interview

Let’s say you’re interviewing for a tech lead position and want to prepare thoroughly.

Context: I’m a frontend developer with 6 years of experience, primarily working with Vue.js 3 and Laravel. I’ve been leading a team of 4 developers for the past 2 years. I have an interview next week for a tech lead position at a product company that builds project management software. The role involves leading a team of 8 and making architecture decisions for their frontend migration from Angular to React.

Your Role: Act as a senior engineering director who has conducted over 100 tech lead interviews at product companies.

Task: I want you to interview me by asking one question at a time to understand my experience, strengths, and potential gaps. Based on what you learn, generate the 10 most likely interview questions I’ll face and explain what the interviewer is really trying to assess with each one. Also identify areas where my experience might be seen as a weakness and suggest how to address them honestly without underselling myself.

Requirements: Rank the questions in order of likelihood. For each one, include what a strong answer would cover. Be direct about my gaps — I’d rather know now than be surprised in the room.

Notice what’s happening here: you’re giving AI enough context about your background and the specific role that it can tailor the preparation. The interview technique means it’ll dig deeper before generating output. The requirements keep the output actionable.

Example 2: Presenting a complex technical decision

You’ve done the research, you’ve made the call on a significant refactor, and now you need to present it to stakeholders who will have questions.

Context: I’m a tech lead proposing a migration of our state management from Vuex to Pinia across a large application with 200+ components. The migration will take approximately 3 sprints and will temporarily slow feature delivery. Our VP of Product is concerned about the timeline impact, and our CTO wants to understand the long-term technical benefits. The app currently has performance issues in complex views with deeply nested reactive state.

Your Role: First, act as a skeptical VP of Product who cares about delivery timelines and customer impact. Then, act as a CTO who cares about technical debt and long-term maintainability.

Task: Review the proposal I’m about to share and for each persona, tell me: what would concern you most, what questions would you ask, and what would convince you this is the right call. Then help me structure a 10-minute presentation that addresses both perspectives without getting too deep into implementation details.

Requirements: Structure the output so I can clearly see each persona’s concerns separately. Be blunt — I need to anticipate the hardest questions, not hear that my plan sounds great.

Limits: Don’t suggest alternative state management solutions. The decision is made. I need help selling it, not revisiting it.

This is where AI as a Challenger is useful. It simulates the room before you walk into it. Woods shares a similar story in the book where a team used AI to simulate board member reactions to a presentation — and AI accurately predicted which slides would cause problems and which stakeholders would push back on specific metrics.

[image: side-by-side comparison of a vague prompt vs a structured prompt using the ingredients approach]

The mindset shift

The most useful takeaway from the book isn’t any single technique. It’s the shift from asking “How might I do this?” to “How might AI help me do this?”

Applied consistently, that question changes how you approach writing specs, preparing for difficult conversations, and evaluating technical trade-offs. It doesn’t mean leaning on AI for everything. It means not leaving a useful tool on the shelf when it could be saving you hours.

Woods uses the Blockbuster vs. Netflix story to open the book. The comparison is a bit tired, but the underlying point holds: leaders who fail aren’t necessarily the ones who lack intelligence. They’re the ones who stick with familiar patterns when better tools are available, and who don’t seek outside perspectives on their own thinking.

As tech leads, we already do this with code reviews, architecture discussions, and design critiques. Using AI as a thought partner is just extending that practice to spaces where we usually think alone — writing specs, making strategic calls, preparing for high-stakes conversations.

Worth your time?

If you’re a tech lead or anyone making product and technical decisions, I’d recommend picking up “The AI-Driven Leader.” Not because it’ll teach you prompt engineering tricks, but because it reframes how you think about AI in your daily work. The stories from real leaders — from CFOs to heads of investor relations — show practical applications that translate to technical leadership.

The book won’t teach you anything about code. But it might change how you think about the decisions around the code, and those decisions are where most of the value and most of the risk actually live.

Give it a read. Next time you’re staring at a blank spec doc or preparing for a tough technical review, try asking AI to interview you first.

[image: the book next to a laptop with a spec document open — representing AI-assisted technical leadership]

---

Resources:

• The AI-Driven Leader by Geoff Woods: https://aileadership.com

---

Petar 🥃