Same Question, New Tools: From Business Analyst to Presales to AI Solution Consultant

Every job I have held has asked me the same question: what does this business actually need, and what will it take to build it?

As a programmer, I answered it in code. As a business analyst, I answered it in requirements. In presales, I answered it in front of a customer, under deadline, against competitors. Today, with AI changing what software can do, the question is the same, but the answers are far more interesting.

This post is three things at once. It is an honest account of the roles I have held and the skills I added over the last ten years. It is the case for why that path leads to AI solution consulting and AI product management, the roles I am now applying for. And it is a map for any business analyst wondering whether the same move is open to them. It is.

The thread through my career

On paper my CV looks like a series of different jobs in different industries. In practice, each one taught me one more layer of the same craft: understanding a problem well enough to shape the solution.

Read top to bottom, the pattern is clear. I started inside the system, moved to the boundary between business and technology, then stepped right up to the customer, across healthcare, insurance, retail and credit cards. In the last decade I went back and learned to build, first with machine learning and then with large language models. Each step made me better at the one before it.

Why a business analyst makes a good presales consultant

People often treat presales as a sales job with technical knowledge bolted on. In my experience it is closer to business analysis performed live, in public, against a deadline and a competitor. Almost every core BA skill has a direct counterpart:

What changes is the posture. A BA documents a decision someone else will make. A presales consultant has to help the customer make it, and has to be persuasive without overselling. That shift, from describing to influencing, is the real learning curve. The analytical foundation is already there.

What changed: presales in the age of AI

Before writing this post, I read through current AI presales and solution consulting postings in Singapore, from AI vendors and systems integrators to a government agency hiring for its AI programmes. The same expectations came up again and again:

• Run discovery workshops and turn what you learn into tailored solution decks, demos and prototypes.
• Build working demos yourself, often with AI-assisted development tools, rather than waiting for an engineering team.
• Solution across the generative AI stack: large language models, retrieval-augmented generation (RAG), and agentic systems with multiple agents and tool use.
• Champion responsible AI: privacy, compliance, fairness and safety designed in, not bolted on.
• Explain complex technology clearly to audiences who range from engineers to executives.

Two of those five are new since my time at TIBCO, and both are things I have spent the past year doing.

Building demos myself. Ten years ago a presales consultant could design a solution and hand the demo to a specialist. Today the expectation is that you can stand up a working prototype. I built three, each solving a different problem with a different AI pattern. Attic is an AI agent that tidies a Gmail inbox. BeatKeeper is a multi-agent system that runs a weekly content campaign for busy professionals. MealPartner is a RAG meal assistant on WhatsApp for university students. I built them with AI coding tools, but with the discipline of a BA and a project manager: a written specification first, small test-first increments, and decisions recorded as I went. I wrote about that method in Agile, Waterfall and the Vibe.

Responsible AI by design. Every one of my builds treats trust as a requirement, not a feature. Attic cannot delete email, and its safety rules are enforced by the server whatever the AI suggests. BeatKeeper will not let a user approve any factual claim without a linked source, and it never posts on anyone's behalf. MealPartner never lets the language model write recipe content, which limits both hallucination and prompt injection. These are exactly the conversations an AI presales consultant has with a bank, an insurer or a hospital: what can go wrong, and how do we prove it won't.

The same path leads to AI product management

Business analysis and product management have always been close cousins. Both turn a messy business need into something a team can build. What makes AI product management different is that the thing being built doesn't behave the same way twice. You can't write a requirement that says "the answer must be correct" and test it once. You have to define what good looks like, measure it continuously, and decide what happens when it goes wrong.

The AI product manager postings I read in Singapore reflect this. They ask for people who can:

• Translate implicit business needs into AI specifications, including agent behaviour, tool definitions, guardrail requirements and acceptable error rates.
• Own the evaluation strategy: success metrics, evaluation datasets and benchmarks that show whether the product is getting better or worse as prompts and models change.
• Understand LLM concepts well enough to make technical trade-offs, without needing to be a software engineer.
• Align stakeholders across engineering, business, risk and compliance.

One posting put it plainly: shipped products matter more than credentials. Here is what I can show against each of those expectations.

AI specifications. MealPartner started as a requirements document, not code. It defines who the user is, how the conversation should feel, which decisions the code makes and which the model may make, and what the system does when nothing fits. That last one matters most. MealPartner says honestly when it has no good answer and logs the request, so the recipe library grows where demand actually is. That is a product feedback loop designed in from day one.

Evaluation. BeatKeeper measures quality against a golden dataset, versions its prompts for each agent role, and logs every model call through one client so behaviour can be audited. Its hard rules, such as never auto-posting, are enforced by automated tests.

Trade-offs. In MealPartner I chose a small local model and confined it to narrow, schema-constrained tasks, with confidence tiers that decide whether a match is shown, shown with a caveat, or not shown at all. That is a product decision about risk, cost and user trust, expressed as architecture.

Prioritisation and alignment. For the school's education technology working group, I led research that produced 37 recommendations and then distilled them into eight priorities for school leadership. Getting parents, teachers, students and board members to agree on eight things is product management without the title. I wrote about it in Not More Tech, Not Less Tech.

The skills I added in the last ten years

Here is the decade in one table, with evidence you can check for each line.

Put the two halves of my career side by side and they fit together. The first half gave me enterprise delivery, domain depth across healthcare payers and providers, insurance, retail and credit cards, and cross-industry presales. The second half gave me the technical fluency to work with AI hands-on. Most people come to AI solution consulting with one half or the other.

The roles I am going after, and why I fit

I looked at where my experience meets current demand, and ranked the roles honestly by fit.

Where I draw the line. I am not applying for forward deployed engineer roles, which are mostly production coding and own a customer's live system after the sale, or for pure data scientist roles. I can code, and I enjoy it, but my best value is at the point where a business problem becomes a solution design. That is where I want to work.

What I am not claiming

A post like this is only useful if it is honest, so here are the limits.

• My AI products are prototypes, not enterprise deployments. I designed them with production concerns in mind, such as audit logs, tests, guardrails and swap-ready architecture, but I have not yet run an LLM product at enterprise scale. My enterprise delivery experience comes from the years before generative AI.
• I have been away from a corporate role since 2019. I have spent the last year closing the technical gap deliberately and visibly, and I expect to spend my first months in a new role learning the employer's products and customers, as anyone would.

What I offer in return is a rare combination: enterprise delivery across four industries and cross-industry presales experience, plus the ability to build with AI myself. Hiring managers who need someone to explain AI to customers, or to define what an AI product should do, rarely find both in one person.

If you are a business analyst thinking about the same move

You are closer than you think. Most of what AI solution consulting and AI product management need is what you already do: understand the problem, define the solution, and get people to agree. Here is what I would do again.

• Build one thing end to end. Pick a small, real problem from your own life and solve it with an LLM. Nothing teaches you where AI fails like watching it fail on your own data.
• Learn to write requirements for systems that aren't deterministic. Practise defining evaluation sets, acceptable error rates and what the system must do when it is unsure. This is the single biggest new skill.
• Learn the vocabulary, not every tool. RAG, agents, tool use, guardrails, evals, prompt injection, hallucination. You need to hold a credible conversation, not master every framework.
• Practise discovery out loud. Presales is analysis in public. Volunteer to run a workshop, present to a group, or explain a design to someone outside tech.
• Treat trust as a requirement. Every customer will ask whether they can rely on the AI. Have an answer designed into your work.
• Publish what you learn. A short write-up of a build is better evidence than a certificate. It shows how you think.

The job hasn't changed. The tools have.

Twenty years ago I wrote COBOL so that insurance claims would pay out without a human touching them. Last year I built an AI agent that won't touch an email until a human says yes. The technology could not be more different. The question I was answering is exactly the same: what does this business need, and how do we build it so people can trust it?

That is the question at the heart of AI solution consulting and AI product management. I have been answering it my whole career, and I am ready to answer it again.