If you have never commissioned software before, it is easy to imagine the first developer conversation as an exam you have not studied for.
You may feel you are supposed to know what framework to use, how the database should work, whether you need an API, or exactly how every screen should behave.
You are not.
A useful first conversation should begin with your knowledge, not with your ability to imitate a software engineer.
Know the problem better than the technology
If the product is for your business, your expertise is probably in the work itself.
You know where time gets wasted. You know what customers ask repeatedly. You know which spreadsheet everybody is afraid to touch. You know the workaround employees have quietly invented because the official process is too slow.
That information is valuable.
Instead of trying to specify a technical system, explain things such as:
- what happens today
- who is involved
- where the frustration is
- what information is needed
- what mistakes happen
- what "better" would look like
That is enough material to start shaping software.
Bring examples, even imperfect ones
Examples are often more useful than polished requirements.
You might bring:
- a spreadsheet you currently use
- screenshots of another app whose interaction you like
- a hand-drawn screen
- an email template
- a form your team fills in
- a competitor product
- a list of customer complaints
- a rough prototype
You are not saying "copy this."
You are giving context.
"I like how quickly this app lets me get to the important action" is useful information even if the final product looks completely different.
Say what you do not know
Uncertainty is not a problem if it is visible.
For example:
I know employees need to approve these requests, but I do not know whether customers should create accounts.
That is a much better starting point than confidently specifying an account system simply because most apps seem to have one.
Unknowns can be discussed, tested and deliberately postponed.
Hidden assumptions are harder.
Constraints matter
Some of the most useful information has nothing to do with features.
Tell the developer if:
- there is a fixed launch date
- the product needs to work with an existing system
- particular devices are used
- data is sensitive
- the first release is only for a small pilot group
- budget is tightly constrained
- someone else will maintain the system later
Constraints help shape good decisions. They are not inconveniences to hide until later.
You should still ask technical questions
Not needing to be technical does not mean technology should be mysterious.
You should feel comfortable asking:
- Why are you recommending this approach?
- What trade-off are we making?
- What happens if usage grows?
- What third-party services will we depend on?
- What will have ongoing costs?
- Who controls the code and accounts?
- What happens after launch?
You do not need to know the answer in advance. That is the point of asking.
A good explanation should help you understand the consequence of a technical decision without requiring you to become an engineer.
Avoid solving the implementation too early
Suppose you say:
We need a chatbot.
The more useful underlying need might be:
Customers keep asking the same ten questions and cannot find the answer.
Maybe a chatbot is the right solution. Maybe better search, clearer navigation or a guided flow would solve the problem more simply.
Starting with the need leaves room for better options.
The same applies to words such as AI, blockchain, native app, microservices, real-time and automation.
Technologies can be valuable. They should earn their place by solving the problem.
What a developer needs from you
At the beginning, a developer mainly needs enough context to make the next set of decisions intelligently.
That usually means understanding:
- the problem
- the users
- the important workflow
- the constraints
- the desired outcome
- what you already know and what remains uncertain
The details can become clearer as the product becomes real.
You can start with a sentence
A surprisingly good opening is:
Right now we do X, and I think software could make Y easier.
Or:
I have an idea for people who struggle with X, but I am not sure what the first version should be.
That is enough.
You do not need to turn your idea into developer language before talking to a developer.
Translation is part of the work.
Bring the messy version
A sketch, spreadsheet, note or half-formed idea is welcome. We can start from where the idea actually is.