AI as a Thinking Partner

A partner, not a cheerleader

Chapters 5 and 6 treated AI as a drafting and analysis tool. That is only half of professional use. The other half is slower: you already have a proposal, and the question is what you are not seeing. A thinking partner is a model you brief to argue with you on purpose — to challenge assumptions, generate counterarguments, identify blind spots, compare competing strategies, simulate stakeholders, run a pre-mortem, conduct a risk analysis, and generate alternative solutions. None of that replaces a decision. Each of them improves the decision you still have to take.

Language models are trained to be helpful, and helpful often means agreeable. “What do you think?” usually returns a polished endorsement. Partnership starts when you treat your idea as a hypothesis under examination, not as a brief to be dressed up.

This chapter deepens those eight modes: steelmanning, pre-mortem, red team and blue team, decision quality versus outcome quality, prompts against sycophancy, and a worked pricing and launch example.

Eight working modes

The chart is a map of jobs. You do not need all eight on every problem. You do need to name which job you are hiring the model for. Mixing them in one prompt produces a vague essay. Sequencing them produces a file you can take into a meeting.

Read the chart as a sequence you can run: write the proposal yourself; challenge assumptions; generate serious counterarguments; name blind spots; then compare options including do nothing; then simulate stakeholders; then pre-mortem and risk; generate alternatives early and again after the pre-mortem. One mode per prompt unless you already have a template. Keep the human proposal in the window, or the model will invent a cleaner plan than the one you have and critique the invention.

Steelmanning versus strawmanning

A straw man restates an opponent’s view at its weakest. A steel man restates it so the person who holds it would say: yes, that is what I mean. Models compress, and compression prefers cartoons. A lecture about customer revolt after a 15 per cent price rise can be true and still a straw man if it ignores the theory of the case: under-pricing relative to value, low churn, a requested capability. A steelmanned objection grants those points and still argues that value sits in a small cohort, or that procurement will stall a mid-year increase.

Instruct the model to steelman before it critiques. If it critiques first, the critique anchors the conversation and the “fair restatement” becomes a polite summary of a view it has already dismissed. If it steelmans first, you can check whether it has understood the proposal. If it has not, stop and correct the brief. Do not let a misunderstanding harden into a risk register.

Steelman this proposal in 200 words so that I would recognise it as my own case at its strongest. Then, and only then, give the three strongest objections that still apply after that restatement. Label each objection as: (a) a fact we can check, (b) a judgement call, or (c) a value conflict. Do not invent customer quotes, market shares, or costs I have not supplied.

The labelling step is borrowed from Chapter 6: facts, interpretations and hypotheses should not share a sentence. An objection that depends on a missing number is a research task. One that depends on risk appetite is a decision for the people who own the P&L.

Pre-mortem versus post-mortem

A post-mortem asks why something already failed. It is necessary, and it arrives too late for the decision you are taking this week. A pre-mortem inverts the timeline. You say: it is twelve months from now, the plan has failed, and the failure is not small. Write the history of how that happened. Then you look at that history while you can still change the plan.

AI is useful here because it has no reputation in the room. Junior staff often stay polite. The model will generate failure modes a politically careful colleague will not. That is an advantage only if you then do the human part: decide which stories are plausible in your organisation, assign owners, and change the plan or accept the residual risk in writing.

The difference from “list the risks” is narrative. Risk lists invite clichés. A pre-mortem asks for a mechanism. “Sales missed quota” is not one. “Enterprise buyers froze because the new SKU required legal review of data-processing terms we had not drafted, and the Q3 campaign had already gone out” is. Mechanisms suggest prevention. Force it into the present tense: “Before we announce, legal drafts the DPA addendum and sales cannot book a webinar until it is on the website.” If the model’s preventions are all monitoring, ask again until each one has a named owner this month.

The last row is the limit. A model will generate cinematic failures involving journalists and board resignations. Often you fail more dully: a delayed integration, a mis-set commission plan, a forecast that assumed capacity you do not have. Paste two or three redacted internal post-mortems and say: prefer failure modes in this family. That is Chapter 3’s grounding rule applied to judgement.

Red team and blue team

A blue team defends a plan. A red team attacks it. The value is that attack and defence use different success criteria, and those criteria should not be mixed in one head on the first pass. If the same person is told to make the case and then find holes, they usually make a case with pre-drilled holes they already know how to patch.

Run this with one model and two prompts, or with two chats. The blue team prompt should be loyal to the proposal: strongest version, implementation path, what would have to be true, early evidence of success. The red team prompt should be loyal to failure: assume the blue team is competent and still find the paths around their controls. A third pass should not average the two. It should produce a decision memo: keep, modify, or stop, with modifications listed as changes to the plan rather than as “risks to monitor.”

You are the red team. You do not work for the product organisation. The attached plan is the blue team’s brief. Assume they are competent and that their stated controls will be attempted in good faith. Find five ways the plan still fails. For each way: the path around the control, the first observable signal, and whether the failure is reversible in 30 days. You may not recommend “better communication” or “more training” unless you specify the exact artefact, owner and date. Do not helpfully balance the critique with praise.

Separate the teams in time. If you paste red team output into the blue team chat immediately, the blue team will patch on paper — sometimes useful, sometimes an unrecognisable and still untested plan. Better: red team overnight, human owners in the morning, then a short revision that may reject a finding as residual risk. Rejection is allowed. Unacknowledged rejection is not.

Decision quality is not outcome quality

A good decision can have a bad outcome. A bad decision can have a good outcome. This is the reason thinking-partner work is worth doing even when the quarter still goes wrong, and the reason a lucky quarter should not be treated as proof of method.

Decision quality is about whether you framed the problem, considered alternatives, used information that was available at the time, were honest about uncertainty, and chose in line with the organisation’s stated risk appetite. Outcome quality is what the world then did: demand, competitors, a key person leaving. AI can help with the first. It cannot be graded on the second. If you use a model to decorate a plan that had no real alternatives, you did not improve decision quality. You improved the prose.

Write down, before you know the outcome, what you knew, what you chose, and what would count as the decision having been sound. The model can help write that memo. It should not be asked, after the fact, to produce a narrative in which you were wise. When you compare strategies, include wait, and include reversibility. A public price list needs a higher standard than a two-week test in one segment. Models flatten that distinction unless you put it in the brief.

Multi-perspective analysis

Ask for the CFO’s view, the customer’s view, the engineer’s view, the legal view, the operations view, the risk view, and the CEO’s view. Then ask: “Where do these perspectives disagree?” That disagreement is where the real decision sits. Agreement across all seven is either a small decision or a brief that has been sanitised until nothing remains.

The method only works if each perspective is allowed to want different things. The CFO wants margin, cash timing, and a story that survives the forecast. The customer wants a price they can defend and a product that does not punish them for being early. The engineer wants a scope that will not rot the platform. Legal wants representations you can stand behind. Operations wants a launch that does not break implementation capacity. Risk wants concentration, conduct and resilience named rather than implied. The CEO has to choose. If you instruct the model that all stakeholders should be aligned, you have forbidden the only useful output.

Run the perspectives as separate memos of similar length, not as a round-table transcript. Transcripts drift into compromise language. Memos create artefacts you can put side by side. Then run the disagreement pass as its own prompt. You are looking for clashes of the form: finance needs the revenue in Q3; legal cannot clear the claims until Q4; operations can implement forty accounts, not the hundred in the forecast. Those are decisions. “Everyone is excited but cautious” is not.

These are role sketches, not your actual CFO. The model does not know that your finance lead is sceptical of usage-based pricing because of a write-down two years ago, unless you say so. Do not skip the customer, and do not treat “the customer” as a single grateful person. Split them if the decision depends on it: the buyer, the user, and the person who has to implement. Those three disagree more often than finance and engineering.

When partnership becomes sycophancy

Sycophancy is the model agreeing with you because agreement is the path of least resistance. It is a predictable result of training: systems are rewarded for answers people mark as helpful, and people often mark agreement as help. In a thinking-partner setting, that reward model is the enemy of the work.

You can see it without special tooling. You state a strategy. The model praises the strategic clarity. You mention a doubt. It shares the concern and restates the original plan with softer adjectives. You say you are leaning towards delay; it produces a case for delay. You say you are leaning towards speed; it produces a case for speed. If both cases arrived after you revealed the preference, you have not tested the idea. You have watched a mirror.

Prompt against it. “Be critical” is not enough. Critical, to a sycophantic system, means two caveats and a compliment. Make agreement expensive: forbid praise in the first response; require a score that cannot hide in the middle of the scale; require the model to pick against your stated preference on at least one criterion; hide your preferred option until after the criteria exist.

Do not agree with me. Do not praise the plan. Do not use “great”, “solid”, “smart”, or “makes sense”.

Score each criterion from 1 to 10. You may not give a 6, 7 or 8 on more than two criteria. If uncertain, score lower and say what evidence would move the score by two points.

Name the one criterion where you disagree with my implied preference and argue that side for 150 words. If you have no disagreement, you have failed: construct the disagreement a competent sceptic would hold, and label it as constructed.

End with: what would have to be true for this proposal to be a mistake, and how we would notice in 30 days.

Even these prompts are not a cure. If you keep re-rolling until you get a warmer answer, you are the sycophant. Keep the first cold response, then run a second pass that may update in light of evidence you then supply. Watch also for sycophancy towards slogans. If the prompt is soaked in “customer obsession,” the model will baptise almost any plan in those phrases. Forbid the slogans. Argue in operations, money, legal exposure and customer behaviour. Chapter 4’s RTCCOQ still applies: sceptical partner; attack and compare; the real plan; no praise and no invented numbers; tables and named disagreements; facts labelled separately from judgements.

Prompt templates

Copy these, then fill them with your actual plan. They follow professional prompting: role, task, context, constraints, output, quality. Do not delete the constraints about invention. A thinking partner that invents a market-share figure is not thinking. It is hallucinating with better posture.

Pre-mortem

Role: Pre-mortem facilitator, not a supporter of the plan.
Task: It is [12 months] from now. The plan has failed in a way [the board / customer / regulator] would call a failure. Write the five most likely histories.

Context:
- Plan: [paste]
- How we actually fail: [3 bullets from real incidents]
- Constraints we cannot change: [regulation, contract, headcount, date]

Constraints: Do not invent statistics, names, or legal conclusions. Prefer dull operational failures. Each history needs a mechanism, not a slogan.

Output for each of five: (1) story in 120 words, (2) first signal we could have seen, (3) one action this month with a suggested owner role, (4) residual risk if we take it.

Quality: List assumptions I did not supply. If prevention is only “monitor”, rewrite it as an action this month.

Stakeholder simulation

Role: You simulate seven stakeholders. You are not mediating yet.
Task: Seven memos of 180–220 words: CFO, customer (split buyer vs user if needed), engineer, legal, operations, risk, CEO. Each must state wants, fears, what they would block, and what evidence would change their mind.

Context: [plan, numbers, dates, known organisational constraints]

Constraints: They may disagree; do not align them. Do not invent margin, capacity, or legal advice — say “blocked on missing fact: …”. No empty phrases such as “cross-functional alignment”.

Output: Seven memos, then a disagreement table (who vs who, issue, why it matters, decision only a named executive can take).

Quality: The CEO memo may not average the others. It must choose what to escalate.

Strategy comparison

Role: Decision analyst. Do not recommend until the table exists.
Task: Compare Option A, Option B, and Do nothing on the same criteria.

Context:
- Goal: [one sentence]
- Option A / B / Do nothing: [paste]
- Criteria (must use): [e.g. 12-month contribution, reversibility in 90 days, operational load, legal exposure, customer trust]
- Hard constraints: [paste]

Constraints: No new options until the table is complete. No 7/10 as a hiding place — use high / medium / low plus a one-line reason, or a range. Separate facts I supplied from judgements.

Output: (1) criteria table, (2) where the options actually disagree, (3) evidence that would change the ranking, (4) only then a recommendation with residual risks.

Quality: If two options tie, do not break the tie with adjectives. Name the executive judgement required.

These templates refuse a free-form essay, invented numbers, and a recommendation before the structure exists. That is Chapter 4 applied to judgement. The first output is a draft of the thinking, not the decision.

Worked example: a price rise with a product launch

A mid-market B2B analytics company sells a professional plan at £89 per user per month. Support costs have grown faster than usage. A new “Signals” add-on has been in private beta with twelve design partners. The proposal: launch Signals on 1 September, raise the professional plan to £99, and include Signals for accounts above fifty seats as a retention investment. Marketing has a campaign slot. Sales wants the higher ASP in the second-half forecast. Write the proposal yourself first, including churn, the design-partner comments, support cost per seat, and the fact that legal has not finished the wording on how Signals uses customer data.

Steelman: the plan is under-priced relative to value in larger accounts; Signals is what those accounts already treat as the product; a clean September date beats a messy January because procurement calendars will push everything into the next fiscal year; the bundle above fifty seats is retention, not a giveaway. Strong counterarguments: the price rise and the launch are two decisions taped together; customers who do not get Signals still pay £10 more; twelve flattered design partners are not demand at scale; unfinished data wording is a claims delay; operations can implement the beta twelve, not the forecast volume; if legal slips, sales will already have quoted £99.

The seven perspectives disagree where the decision sits. The CFO likes the £10 if it sticks and dislikes a giveaway missing from the cohort model. The forty-seat customer feels punished; the hundred-seat customer may like the bundle and still stall on data terms. Engineering wants a slower rollout. Legal wants the DPA annex before the campaign. Operations asks about September capacity. Risk asks whether Signals reopens old questionnaires. The CEO can have a coherent story or a September date, but perhaps not both. Pre-mortem: campaign ships; renewals freeze; discounts leak; list price becomes theoretical. Prevention now: annex on the site before the campaign is booked; separate price from SKU; cap onboarding; write the discount policy first. Compare (A) the current proposal, (B) Signals as a separate price, (C) a January rise with notice, (D) do nothing. A public £99 is hard to reverse. The model fills the table. The CEO still chooses.

Limits of a thinking partner

The model does not know your organisation’s politics, the informal veto held by a particular executive, the customer who must not be upset this quarter, or the unpublished constraint that hiring is frozen even though the plan assumes implementation capacity. Unless you provide those things, it will analyse a company that does not exist. It also does not know unpublished facts: tomorrow’s pipeline, real margin by cohort, an outage you have not disclosed. Chapter 3 still applies. Treat every crisp sentence as a hypothesis until a person with the relevant job accepts or rejects it.

Confidentiality is a further limit. A pre-mortem on a redundancy programme, an unpublished price change, or a merger does not belong in a consumer chatbot. Classify before you paste; Chapter 9 will make the colour codes precise. Finally, a thinking partner cannot own the decision. You should leave with better questions, a disagreement map, and preventions you can take this month — not with a model that “validates” a strategy. These systems provide pressure, structure and speed. You provide judgement, context and accountability.

How to practise this week

Take one live decision already written down. Run steelman, a pre-mortem with present-tense preventions, and the seven-perspective disagreement table. Spend more time on the meeting than on the prompts. If nothing in the plan changes and residual risk is not accepted in writing, the exercise was theatre. Save what worked; Chapter 12 is the library. Next: RAG, agents, and tools.

Key takeaways

• Hire the model to pressure a proposal, not to polish it. Name the mode.
• Steelman before you critique. Straw men are easy for models and useless for decisions.
• A pre-mortem needs a mechanism and a prevention this month, not a monitoring slogan.
• Red team and blue team should not be the same prompt. Integration is a decision memo.
• Judge decision quality at the time you chose. Do not let the outcome rewrite the method.
• Simulate CFO, customer, engineer, legal, operations, risk and CEO, then ask where they disagree.
• Sycophancy is the default. Forbid praise, hide your preference, keep the first cold response.
• The model does not know your politics or unpublished constraints. You still own the call.