Describe today before describing tomorrow
Start with how the work happens now. Explain what triggers the process, who participates and where time is lost. Share a sanitised example of the documents or screens involved. A developer can make better recommendations from a concrete workflow than from a list of technologies. You do not need to arrive with every feature decided, but you should be able to describe the outcome you want.
Name the audience and the main task
Separate the needs of customers, staff, managers and administrators. For each group, identify the most important action. A customer may want to track a booking while an administrator needs to correct it. Those are related but different journeys. Describe how often the task happens, whether it is mobile or desk-based, and what information users should be allowed to see.
Make constraints visible early
Share the deadline, budget range, existing systems and any approval process that affects delivery. State whether an integration is essential or simply desirable. If a launch date depends on another supplier, say so. These constraints help shape a realistic first release. They also make it easier to discuss trade-offs without quietly reducing quality in the areas that matter most.
Ask for a shared definition of done
A proposal should explain deliverables, assumptions, testing, ownership and support. Request a demonstration plan so progress can be reviewed before the end. Agree how changes to scope will be handled and how decisions are recorded. A short brief followed by a structured discovery conversation is often more productive than a long feature list with no priorities. The purpose is alignment, not technical vocabulary.
Have a workflow or product idea in mind?
Talk it through with Teras Core ↗