A product request is a useful starting point for a conversation, but it should be connected to the work the business needs to improve.

Consider a possible situation: a business asks for a specific server or website rebuild, and the supplier prepares a quote for that item. If neither side explores the underlying problem, the delivered work may meet the specification while leaving an important frustration unresolved. Discussing the intended outcome helps both sides test the fit before committing.

A useful starting point is to ask what you are trying to do, where things are getting stuck and what would make the day easier.

Three questions, and why they are hard

They sound like small talk. They are not, and they are surprisingly difficult to answer well.

What is your team trying to do? Not the department's mission statement — the actual work. Getting quotes out within a day. Knowing which jobs are running late without asking anyone. Closing the month without three evenings of reconciliation. Answering a customer's question in one call rather than three.

Where is it getting stuck? Look for specific steps, systems, or handoffs. “Our technology is outdated” may be a reasonable concern, but it helps to describe what happens in practice and which task it prevents.

What would make the day easier? This question can make it easier to discuss a small, practical improvement. People who would never propose a project will happily tell you that they wish they did not have to re-type the same address into two systems.

Between them, those three questions produce something a proposal should respond to: a description of the problem in the words of the people who have it.

Talk to the people doing the work

Include the perspectives of the people who perform the work, manage it and receive its output. Comparing their descriptions can reveal details that one role does not encounter.

Consider a hypothetical services firm convinced their scheduling software is the bottleneck. The people using it daily explain, without much prompting, that the software is fine — the delay is that job details arrive by voicemail and have to be transcribed before anything can be scheduled. Replacing the scheduling system would have been an expensive way to change nothing.

This is not a criticism of managers. It is simply that no single vantage point in a business sees the whole of a process, and a person who regularly performs the task can contribute details that another role may not encounter.

What a good discovery conversation looks like

  • It starts with the work, not with the systems.
  • It includes at least one person who performs the process daily.
  • It asks what people do when the normal path fails, because the exceptions carry the requirements.
  • It establishes what "better" would look like concretely enough to recognize later.
  • It surfaces constraints honestly: budget, timing, a system that cannot be touched until year end.
  • It ends with a shared written summary, so both sides can check whether they heard the same thing.

A written summary gives everyone a chance to correct an assumption while the discussion is still fresh. Record the desired outcome, open questions, and who owns the next action. A summary is useful only if people can review and update it.

How to prepare for one

If you are the client, a little preparation makes an enormous difference, and none of it is technical.

Bring the three or four things that most frequently go wrong, with real examples rather than categories. Bring a sense of what it costs when they do — in hours, in missed work, in customer irritation. Bring the constraint you have not mentioned yet, whether that is a budget ceiling, a contract that runs to a certain date, or a person who will resist a particular change. Bring someone who does the work.

And say what you have already tried. That history helps the provider avoid repeating an unsuccessful approach without understanding why it failed.

Keep checking the shared understanding

Discovery should leave a record that people can use when a new question appears. Before the work begins, read back the main requirement in ordinary language: what the person needs to do, what gets in the way, and how a useful result will be recognized. Invite corrections rather than asking only for a general yes or no.

As an option takes shape, use a small example or demonstration to check that interpretation. Ask the person doing the work to describe what they would do next and what information they would need. If the example exposes a missed requirement, record it and discuss its effect on scope, timing, and the intended outcome. This is an opportunity to refine the plan, not a reason to hide uncertainty.

Keep unresolved questions separate from agreed decisions. A named owner and a next action make an open question easier to finish. A decision log helps a later participant understand why an option was chosen without having to reconstruct every conversation.

What we cannot promise

We are not going to claim that a conversation solves anything by itself, or that every problem has a satisfying answer. Some constraints are real. Some fixes are expensive relative to the pain. Sometimes the honest advice is to leave a system alone for another year, or that the problem is not a technology problem at all — and saying that plainly is more valuable than a proposal.

A conversation grounded in the actual work gives both sides a way to evaluate options and explain their reasoning. It does not remove uncertainty, but it makes assumptions visible before they become part of a commitment. The resulting plan should identify what still needs testing, what would justify proceeding, and what would change the recommendation.

Your next step

Ask the three questions inside your own business first. Ask them of someone who does the work daily, and write down the answers exactly as given rather than translating them into technology.

If you would like to work through what you find with someone, that is what the conversation is for. ALCO USA Inc is here to listen and help you decide the next step, across managed hosting, development and IT support.

Sources and further reading

ALCO USA Inc: https://alcohq.com/
ALCO services: https://alcohq.com/services