Aidan Pilgrim

More revenue impact. Less bullshit.

GTM Engineering

02Highlights

01

AI for customer insight

Used AI on conversational intelligence to generate about 100 new leads a month, scanning call transcripts for future customer opportunities. Tens of thousands of calls go through a multi-stage pipeline: cheap models screen first, and only the interesting calls are rerun on more expensive models to pull out the detail.

02

Customer obsession

As head of the customer funding circle, delivered customer insight that became product roadmap items and drove immediate customer experience improvements.

03

Outbound

Founded the outbound sales channel — data intake, messaging, go-to-market flows, outbound agencies — and took it from zero to $91 million a year.

04

Leadership

Servant leadership. Leaders eat last. Team engagement of 4.5 out of 5.

03Writing

Make No Mistakes

Why others get near-prescient insight from AI while you can barely get a straight answer.

You never forget your worst. Some managers exist only as an example of what not to do. Zero structure. Confusing instructions. No guidance. That’s not how great work is produced. “Would never be me. Could never be me,” we tell ourselves. Claude begs to differ. You’ve taken on the role of the Bad Manager. Your model, as desperate to please as ever, will say anything it thinks you want to hear.

How to flip it? How do you become a good manager for your models and agents? How do you get to the point where they’re working for you, handling complex analysis and building output that’s right for your business?

What’s in a question?

“What’s the impact of bad customer experience on future revenue? Make no mistakes.”

It looks like a simple enough question and most people would have a hypothesis. But traps and dead-ends abound in a request like this. Not that the Bad Manager cares. The core of the issue is that this is a poorly posed question. The responder has much to nail down before they can even start:

  • Over what time frame?
  • What qualifies as a bad experience?
  • What revenue matters here? ARR? NRR? In-year?
  • What sort of output is required?
  • Who is the audience?

This is hard enough for a human to unpick. Vivienne Ming writes in Robot-Proof that AI is very, very bad at solving these problems. Writing a huge prompt that covers every eventuality takes almost as long as doing it yourself.

I can ask Claude the same question and get a good result in a tenth of the time because I’ve built out the systems to enable it.

Once you’ve coached it, it becomes immensely powerful. Once you teach it to find the answers to these questions, then it can answer them again and again without having to have the basics rehashed. This is the power of linking Claude up to your data analytics, and here’s a setup that works. Being the good manager it needs.

How do we start?

The first thing the LLM needs to know here is “How do I solve problems like this?” Much like a new employee, the model needs to be shown its tools. The specifics will depend on your setup, but to be effective, they must be repeatable. Examples include:

  • API or boto3 scripts that already identify the systems you want accessed. You can include specific rate limiting and error handling too.
  • Links to data libraries.
  • Direct references to knowledge banks or context libraries that the model should reference in its query.

Now we are cutting away at the ambiguity of the Bad Manager. We have given our model a map of the territory, but only a vague destination to work with.

Where are we going?

The second failing of the Bad Manager is unclear requirements. Tasks are handed out on a whim, with little detail and less opportunity to follow up. This is an even bigger problem for Claude than it would be for a junior employee, because from Claude’s point of view you could be asking anything at all.

Take three pictures of a king. A monarch. A playing card. A piece on a chessboard. What connects them is the word, and almost nothing else.

Suppose we ask a question that hinges on this distinction. For example, “how powerful is the king?” This question has three possible dimensions and the LLM could follow any of them. Does it look into the constitutional power of the British monarch? The desirability of a king in a hand of poker? The game of chess? To give Claude a fighting chance to provide a good answer, a good manager must provide more context.

This same uncertainty lives in our initial query. Give Claude “negative customer experience” as its brief and it has hundreds of dimensions to consider. Do you mean speed to contact? Number of complaints? Issue tickets? KPI impact? The Bad Manager asks Claude to fill in the blanks of a poorly posed question and they get AI slop in return.

So we must give Claude a clear destination for its analysis. And the only way to do that is with more context. The things that are implicit or assumed in your head must be made explicit and chosen. The Good Manager never rushes this step, as they understand that everything hinges on it.

  1. Put it in Plan mode. This mode exists for our exact use case: getting Claude in sync with our thinking. Use it.
  2. Use voice dictation to brief your idea. Most people speak about three times faster than they type. When you type you automatically filter your thoughts to avoid typing more than you must. There is no such limitation with voice. Additionally, Claude can handle your messy, unstructured output and organise it into something usable. I regularly talk for five or six minutes to get all of my ideas and edge cases in.
  3. Use an adversarial or interrogation skill to refine Claude’s understanding of the idea. Matt Pocock’s /grill-me is the most famous of these, but you can create your own if you wish. The key is that it must continue to question you until it is confident that it understands your intent.
  4. Read the plan. The Bad Manager is lazy. Having made it this far, they assume that the plan is good. After all, the instructions were clear. Never make this mistake. Read, critique, and send the plan back for revisions.

The Good Manager spends an outsized amount of time here because they know that it is key to all of the work that follows.

Make a guess

The Bad Manager hands off work without thinking. An elaborate meat-proxy, they just want it done and back in their hands so that they can start taking credit. Make no mistakes. The Good Manager cares about the process. They have a point of view and a theory about the work before it starts, and they can measure against and update this theory as the work progresses. If you come back and tell them that the sky is red and up means down, they will have thought long enough to question it.

So before you send Claude off on its merry way, make a private guess. “If we expect 20% of customers to cross-sell within 12 months of their first purchase, I would expect that to be 15% lower among customers who raised a complaint in the first 6 months of their contract.”

Now if the model comes back and says conversion is 90% lower, you have a point of view to push back with, rather than a blind acceptance of the results. The Good Manager has thought hard enough to bring a point of view and a challenge, so you walk away with a better result.

Read the output

The Bad Manager doesn’t read the output. They already specified: “Make no mistakes.” In any case, they will sidestep any blowback for inaccuracies.

You are no slop-artist. Put as much effort into reviewing the output as you would ask your audience to put into reading it.

Make something reusable

And finally, the Good Manager creates a flywheel to compound great performance. Anything reusable in the requirements mapping, such as the data, should be kept. What counts as a bad experience. Which revenue you mean. Who the answer is for. The scripts, the libraries, the context the model is supposed to open. Write them once, where the model can find them next time, and you stop paying the full cost of the basics on every question.

The next run of that customer-experience question should not start with a blank page and a Bad Manager. It should start with a system that already knows the tools and the destination, and that still stops to plan when the question is actually new.

That is the job. Pose the question properly. Show the tools. Name the destination. Bring a point of view. Read the work. Then leave the path in place, so the next answer is faster and no less careful.

Make no mistakes. Not as a line you paste onto a bad prompt. As the standard you keep before the model starts.