Turn “we need a better system” into a useful first conversation
A first development conversation should leave the problem clearer than it found it. You do not need to arrive with a chosen platform or a complete feature list. Bring a task, an example of the difficulty and the people who can explain the decisions behind it.
The most useful early question is often not “What should we build?” It is “What does this information mean to the person using it?” That question can expose an assumption a new interface would otherwise preserve.
Start with a recent type of question, without the private record
Imagine a fictional Australian equipment supplier receiving calls about products labelled “available” on its website. Some items are on the shelf. Others can be ordered from a supplier but have no confirmed arrival date. The owner asks for a customer app because staff keep explaining availability by phone.
For planning, two invented catalogue records are enough:
| Product | What the stock team knows | What the current page says |
|---|---|---|
| Item K-21 | No units on hand; supplier order possible; arrival unconfirmed | Available |
| Item K-22 | Four units on hand; ordinary order process applies | Available |
The repeated label is hiding a business distinction. Before discussing an app, establish what the supplier is prepared to tell a customer about K-21 and which person can approve that statement.
Do not export the whole customer database to demonstrate the issue. A blank product record, a public page and these invented values explain the question without disclosing orders or account details.
Identify the decision owner
The salesperson knows what customers ask. The stock controller knows what is physically present. The purchasing contact may know whether a supplier order can be placed. The owner or authorised commercial lead approves the promise made on the website.
Those roles should not be collapsed into “someone will send the content”. In this example, the first conversation establishes that an item with no confirmed arrival date must not display a definite dispatch date. The approved next step for K-21 is a stock enquiry, while K-22 retains the ordinary ordering route.
That is a useful decision even before technical feasibility has been established. It tells the developer what distinction the system must support and prevents a guessed date from becoming a design requirement.
Separate what is known from what needs inspection
The meeting can now record three different kinds of information:
- Confirmed: the two stock states have different customer meanings and approved next steps.
- Observed: the current public template displays the same availability label for both.
- Unresolved: whether the catalogue source exposes the required fields and whether the website can display them through a supported configuration.
A proposal should not turn the unresolved item into a promise. The immediate technical task may be a bounded inspection of the catalogue fields, template and update process. Access is arranged for that purpose rather than requested indiscriminately.
The distinction also helps compare suppliers. One estimate may include that investigation; another may assume the data already exists. They are not yet pricing the same work.
Agree what the next review should show
For this example, the next review would use demonstration versions of K-21 and K-22. It should show the different approved messages and routes, identify the source fields behind them and demonstrate how a stock change reaches the page through the proposed method.
If the current system cannot supply a reliable arrival value, the review should say so. The business can retain an enquiry route while investigating a broader connection. The developer should not create a field full of invented dates to make the preview appear complete.
Keep the ordinary K-22 ordering route in the check. Improving uncertain availability should not stop customers buying an item the business can actually fulfil.
Leave with a short record of decisions
A useful meeting note names the problem, the approved distinction, the investigation, the person supplying access and the evidence expected at the next review. It also records what has not been agreed: a customer app, a new stock platform or a guaranteed delivery date.
The note is not a transcript. It is a shared account of what each person will do next and why that work will help answer the original question.
Faith Forge Labs can begin with this kind of focused assessment. Use the project worksheet to organise the task, then send a project enquiry. Bring the uncertain part of the process as well as the hoped-for feature.