The most useful starting point for a software conversation is often a walkthrough of an ordinary job. Ask someone to show how they get from the request to the result, including the spreadsheet, messages, and extra steps that sit outside the official system.
A workaround contains knowledge. It may exist because the work has an exception the software cannot express, because two systems do not share information, or because a person has found a simpler way to get something done. Understanding why it exists is more valuable than immediately deciding to replace it.
Follow one piece of work
Choose a real task with a beginning and an end. Watch it move between people and tools. Record what information each person needs, where they get it, and what tells them the job is complete. Avoid starting with a feature wish list; first establish the behavior the team needs.
Look for repeated entry
Which details are copied between tools? What happens when the copies disagree, and who has to reconcile them?
Look for hidden decisions
Which step depends on one person knowing what to do? Ask them to explain the exception and the evidence behind the decision.
Look for unclear status
Where does someone have to send a message to discover whether the previous step is finished?
Look for work after the work
Which spreadsheets and reports are assembled once the main task is supposedly complete? What question are they answering?
Separate the problem from the proposed screen
Someone may ask for a dashboard when the underlying need is to know which records need attention. Another person may ask for an export because a calculation is missing. The request is useful evidence, but the first proposed interface is only one possible answer.
Write the need in terms of the work: who needs what information, what they do with it, and how they know the result is right. That description can guide configuration, an integration, a custom build, or a new product.
Ask whether the problem belongs to one business or a market
A process unique to one company may be a good custom-software engagement. The company owns the source and gets a system shaped to its operation. A problem shared by many businesses in an industry may be a better candidate for a product.
Our design-partner approach is for that second situation. We look for people who understand a market, can explain the gaps in existing tools, and have time to work with the engineers. We fund development and bring the product to the wider market. The partner helps shape the result and uses working versions early.
Give intelligence a place only after the task is clear
Once the workflow is understood, ask where intelligence could reduce effort. Could it help find supporting information, prepare a draft, or identify something for a person to review? Define the result and the review before deciding that a model belongs in the process.
Some tasks need a reliable form or a better connection between records. Others may benefit from inference. Knowing the difference keeps the product focused on useful work.
Bring an example you can walk through
A useful first conversation can start with one task, the existing tools, and what your team does when those tools fall short. Show the normal case and an exception. Explain who else in your industry has the same problem.
That gives the engineers something concrete to investigate. The aim is to understand which part of the work should change and what a useful first version would allow someone to finish.