What a good discovery conversation should cover (whoever you hire)

The first conversation tells you more than the proposal does. A vendor comes in to talk about the new system, the portal, the automation, whatever the job is, and somewhere around the third minute they start describing their platform. The features, the dashboard, the integrations. It sounds capable, and it is easy to be carried along by it. But the thing that most decides whether the project works has not been touched yet, and a buyer who knows what to listen for can hear, in that first conversation, whether the person opposite is doing the work that matters or just reaching for the thing they always sell.

This is a checklist for that conversation. It is deliberately vendor-neutral: it works on anyone brought in to build, automate, or replace something, whether that is hirevolution, a competitor, or a freelancer. The aim is to make the reader a sharper buyer of anyone’s services, because the questions a good first conversation asks are the same regardless of who is asking them.

The conversation that decides the project

The strongest single predictor of whether a software or automation project succeeds is not the tool chosen or the price agreed. It is whether the problem was understood, and written down, before the solution was picked. The most rigorous recent evidence for this comes from a 2024 survey of 600 software engineers, 250 of them in the UK, carried out by J.L. Partners for the engineering researcher Junade Ali. Projects that had clear requirements before any building started were 97% more likely to succeed 1. That is a large number, and it is worth being plain about where it comes from: this is software-engineering project data, not a study of small-business CRM or automation work specifically. It is the best rigorous evidence available that getting the problem clear first is the biggest lever, and the principle travels, but it was not measured on small UK firms, so it is offered as a strong signpost rather than a precise guarantee.

What follows from it is simple. The work that determines the outcome happens before the solution is chosen, in the conversation. So the conversation is worth judging carefully.

Why “what do you need it to do?” beats “here’s what we sell”

The same study found that when the requirements were grounded in a real-world problem rather than an assumption, projects were 54% more likely to succeed, and when there was a documented specification before development began, 50% more likely 1. The pattern is consistent: success tracks with understanding the problem, not with the cleverness of the solution.

The cost of skipping that step shows up later, and it is measurable. UK workplace research found that almost four in ten, 39%, of the software a business pays for goes unused 2. That is the classic signature of a solution bought ahead of a defined need: the tool arrived, the need was never pinned down, and so the tool sits there. Buying capability and then hoping a problem fits it is the expensive way round. Defining the problem and then buying the narrowest thing that solves it is the cheap one.

So the first test of a good discovery is the simplest one. Does the conversation start with what the business needs to be different, or with what the vendor happens to sell?

The questions a good discovery actually asks

A competent first conversation spends most of its time here, on the business, before any product is named. These are the questions to listen for, and to ask back if they do not come up.

What does “better” look like, as a number? A good discovery defines the outcome before the mechanism: the result wanted, and how it will be measured. Not “a better system”, but “quotes followed up within the day instead of the week”, or “two hours a week back”. The number comes first; the tool that delivers it comes much later.

Walk me through how this works today, step by step. The current process, told honestly, including the workarounds and the spreadsheet nobody likes to mention. A vendor who does not ask how the work is done now is proposing into the dark.

Who actually does this, and what do they make of the idea? The people who will live with the change, not just the person signing for it. Good discovery talks to multiple roles and levels, because the people doing the work know where the real friction is. There is a related finding worth carrying here: in the same study, projects where engineers felt able to raise problems early were 87% more likely to succeed 1. The same logic applies to the people whose process is being changed. If nobody asks them, the problems surface at the worst possible moment, after the build.

What happens if nothing changes? The cost of carrying on as is, so the spend can be weighed against it. A good discovery wants to know what the status quo costs, because that is the only honest benchmark for whether a project is worth doing at all.

What has already been tried, and why did it stop working? The history. The tools bought and abandoned, the previous attempt, the scar tissue. It saves everyone from proposing the thing that already failed.

What must this talk to? The existing systems and data the new thing cannot be allowed to break. The accounts package, the calendar, the records that already exist. This is where a great deal of quiet project pain hides.

What does “done” mean, and how will we know? Success criteria agreed at the start, in writing, rather than discovered at handover when it is too late to be cheap.

A weak first conversation spends its time on the product. A strong one spends it on these. The difference is audible.

How to tell a real discovery from a sales call wearing its coat

The questions above are what a real discovery asks. There are also some plainer tells, useful when there is no time to run the full checklist.

A real discovery asks more than it claims. Practitioners who do this well describe drawing out the requirements a client had not thought to mention, narrowing the scope and the end goal before proposing anything, and asking questions of people at several roles and levels of the business 3. A firm that has not done that work has nothing solid to price against, so the leap to a number, before the questions have been asked, is itself a tell.

Listen for the willingness to talk a buyer out of spending. A genuine discovery is willing to say “you might not need this”, or “fix the process first, then we will see whether you need software at all”. That is the opposite of a sales reflex, and it is a good sign.

And the counter-tell, the clearest one: a fixed-price quote offered before any of the questions above have been asked. A price that arrives before the problem has been understood is a price for a guess.

Fix the process before you automate it

There is a principle a good discovery surfaces almost by accident, and it is worth stating on its own, because it is the one buyers most often skip. Automating a broken process does not fix it. It just makes the mess happen faster, and now it is harder to see, because it is buried inside a system.

This is why the “walk me through how this works today” question matters more than it looks. Often the most valuable outcome of a good discovery is not a tool at all. It is the realisation that a step in the current process is unnecessary, or that two jobs are being done twice, or that the thing the business wanted to automate should simply stop being done. The tidying is the saving. The software, if it is still needed afterwards, is then automating something worth keeping. A conversation that goes straight from “here is the problem” to “here is the platform” never gives the process a chance to be fixed first, and the 39% of software that sits unused is partly built from exactly that leap 2.

The bar, and how to hold anyone to it

None of this requires the buyer to be technical. It only requires knowing what a serious first conversation sounds like: more questions than claims, the problem defined before the product, a willingness to speak to the people doing the work, and an honest answer about what happens if nothing changes. Hold whoever you bring in to that bar, hirevolution included.

That is the standard hirevolution runs its own discovery against, which is why it is published here rather than kept as a sales technique. The point is not that the bar is hard to clear. It is that clearing it, before a tool is named or a price is quoted, is what makes the difference between software that earns its keep and software that joins the 39%.

See how hirevolution runs a discovery, and the standard it holds itself to