From mess to recommendation

The method is the job, whatever the title says

Strip away the airport lounges and the slide templates and a management consultant's core asset is one thing: a repeatable method for going from mess to recommendation. Not industry knowledge, which clients usually have more of. Not intelligence, which is evenly distributed across the room. A method: define the problem before solving it, break it apart so nothing hides, analyze with evidence instead of anecdote, and deliver a recommendation structured so it survives pushback.

Everyone in tax technology does this work, whether or not it appears in the job description. A vendor solution engineer scoping a determination engine deal is diagnosing a client's problem and recommending a fix. A product manager deciding which mandate to build for next is running a prioritization engagement with herself as the client. An in-house tax technologist arguing for integration budget is delivering a business case to a skeptical steering committee. Different seats, same fundamental activity: converting a messy situation into a defensible course of action.

The difference between these seats is incentive, not method. The vendor engineer is paid when the answer is 'buy my product.' The external consultant is paid when the answer requires more analysis. The in-house technologist is the only one who lives with the result. Knowing this does two things: it tells you how to discount the recommendations you receive, and it tells you why your own recommendations need visible structure. When your incentives are suspect (and everyone's are, to someone), the quality of your method is the only credibility you have.

What the method replaces

Most tax technology decisions are currently made by some combination of experience, vendor persuasion, and whoever argued longest in the meeting. Experience is genuinely valuable, but it fails silently the moment the problem falls outside it, and e-invoicing mandates, AI tooling, and ERP replatforms keep manufacturing problems outside everyone's experience. A method does not replace your 25 years of judgment. It gives that judgment a structure that others can inspect, challenge, and ultimately trust, which is what turns 'I think we should' into 'here is why we should.'

How to apply it

• Name the client in every piece of work. Even internal work has one: the person whose decision your output enables. If you cannot name them, you are producing analysis for its own sake.
• Separate diagnosis from prescription. The most common failure in tax technology is jumping from 'compliance is painful' to 'we need tool X' with no step in between. Parts I and II are the steps in between.
• Show your structure, not just your conclusion. A recommendation with visible reasoning invites productive challenge. One without invites suspicion, especially when it happens to align with your incentives.

The three habits that make the method work

Frameworks are downstream of habits. Give the best toolkit in this book to someone who starts with their conclusion, argues from anecdote, and writes for themselves instead of their audience, and the toolkit produces well-formatted bad advice. The consulting mindset is three habits, and each one runs against an instinct.

Structured: hypothesis first, answer first

Consultants form a day-one hypothesis: a best-guess answer written before the analysis starts. This feels backwards and is not. The hypothesis is not a commitment; it is a filter. With a hypothesis, every piece of analysis has a job (confirm or kill), and work that does neither gets skipped. Without one, teams boil the ocean: extract every report, interview every stakeholder, and arrive at week six with a pile of findings and no answer. In tax technology terms: 'I believe our audit assessments trace to manually maintained content, and a managed-content engine pays for itself' is a day-one hypothesis. Two weeks of targeted evidence either proves it or replaces it with something better. Either outcome is progress; the ocean-boiling alternative produces neither.

The second half of structured is answer-first communication, the pyramid principle from chapter 3. State the conclusion, then support it. Busy decision-makers read the first sentence and skim the rest; structure your writing so that behavior works in your favor.

Analytical: numbers before narratives

Every claim in a deliverable earns its place with evidence next to it. Not because narratives are worthless, but because in tax technology the narratives are supplied by parties with positions: vendors narrate urgency, IT narrates complexity, advisors narrate risk. The analytical habit is to ask, 'what number would make this claim true or false?' before accepting it. 'Compliance costs are out of control' becomes cost per return, trended over eight quarters, decomposed by country. Sometimes the number kills your own preferred story, which is precisely when the habit is worth having.

Stakeholder-centered: the WIFT test

Every deliverable passes through the question the receiver is silently asking: what's in it for them? The WIFT discipline makes that explicit. W: who exactly is receiving this, by name and role. I: identify what they need to know and inform accordingly, nothing more. F: focus on their goals and pressures, not your project's internal logic. T: tie the recommendation back to what they are measured on. A CFO does not care that the tax engine upgrade improves determination accuracy; she cares that it removes an audit reserve from the balance sheet. The same fact is tied back differently. Most rejected tax technology proposals were not wrong; they were written in the author's frame instead of the audience's frame.

A fast companion test comes from Stanford's Matt Abrahams: before sending anything upward, write one line each for what this audience should know, feel, and do after reading it. Know is the finding. Feel is usually confidence or urgency, and the draft either produces it, or it does not. Do is the specific next action, and if you cannot name one, the deliverable is information, not communication, and probably should not be sent yet.

How to apply it

• Write the day-one hypothesis down. An unwritten hypothesis quietly becomes a conclusion. A written one is a target you are allowed to destroy.
• Attach one number to every claim in your next deliverable. Claims that cannot attract a number get demoted to open questions, which is where they belonged.
• Run WIFT before sending anything upward. Ninety seconds: who is this for, what do they need, what are they measured on, and does my last paragraph tie back to it?