Technology product specification: what should you decide before development?

A technology product specification connects a business problem, its users and a testable workflow. Define the first release, permissions, data and failure behavior before asking a development team to estimate delivery.

What turns an idea into a specification developers can use?

An idea describes a desired change: save time, connect people or make difficult information understandable. A technology product specification turns that ambition into actions. Who starts the workflow, what do they know at that moment, what information do they provide, and when is their task complete? Write one journey from beginning to end before listing screens. A homeowner with solar panels, for example, may need to know whether something requires attention rather than ask for another dashboard chart.

In the Solya specification, the starting point was the gap between system data and a homeowner’s understanding. It describes users who do not want to manage another complicated application and treats accessible communication as part of the proposed solution. That is evidence of a documented product requirement, not proof of measured savings. The Solya project provides context. Keep documented needs, assumptions and measured outcomes separate in your own specification too.

Which decisions belong in the document?

Identify the primary user and every other role that touches the workflow. An administrator might see several customers, while an ordinary user should see only their own information. Beside each action, record who may perform it, what earlier state allows it and what changes afterward. A button called approve is insufficient: who approves what, and can the decision be reversed? Concrete examples reduce expensive disagreements between the business, designer and development team.

The data map should explain where information comes from, who controls it and how it is used. When an external service supplies data, specify what the customer sees if it stops responding and who investigates the incident. Some technical choices can remain open. Uncertainty that affects the promise made to a customer, however, needs an owner and a way to test it before the project depends on it.

How do you limit the first release without losing its value?

Choose one outcome the first release must provide. For every proposed capability, ask whether that outcome is still possible without it or through a limited manual process. If so, consider deferring it. Prioritization is a decision about the business experiment you want to run, not a contest to use the fewest screens. Write down what is excluded so later additions become explicit scope decisions instead of quiet assumptions.

Assign an early test to each expensive uncertainty: a user conversation, a prototype, a small provider integration or a permission check. GOV.UK’s discovery guidance recommends understanding the problem and constraints before committing to a solution. Private businesses have different contexts, but the order of questions is useful. Read our prototype or MVP guide when choosing the next deliverable. A beautiful prototype does not establish whether a production integration will work.

How can you tell whether the specification is ready?

Pick a realistic scenario and ask someone who missed the meetings to explain it using only the document. Include an unsuccessful journey: missing information, a repeated submission, a revoked permission or an unavailable service. If the explanation repeatedly depends on something everyone supposedly understood in the meeting, the decision is not documented yet. The specification should make the team less dependent on any one person’s memory.

Before requesting a quote, ask the development team to mark assumptions, external dependencies and questions that still need investigation. Agree on what counts as delivery and how scope changes will be recorded. At Julius, a conversation about the business workflow can lead to a focused specification and then a decision about implementation. Bring an example of a task currently handled manually. It usually provides a stronger starting point than a long wish list of screens.