Writing requirements without being a technologist – fully possible
You can write requirements for an IT project without a technical background. Knowledge of the business matters more than technical jargon, if structured well. Describe the outcomes and flows you want to achieve instead of guessing at solutions, demand answers you actually understand from the vendor, and bring in independent client-side support when the project is large or complex.
Many clients think they need to understand technology to commission an IT project. That’s not true. Your knowledge of the business – how the work actually gets done, where it rubs, what would make a difference – is more valuable than any technical terminology. The art is structuring that knowledge correctly. Here’s how to do it.
Your domain knowledge is the raw material
A developer can build almost anything, but they can’t know how your particular business works. You know that. That knowledge is the raw material of good requirements, and no vendor can supply it for you.
So don’t try to pretend to be a technologist. Be the expert on your problem. The division of roles is simple: you own the what and the why, the vendor owns the how it gets built. As long as that boundary is clear, a technical background isn’t a requirement.
Describe outcomes and flows, not solutions
The single most important move is describing what you want to achieve, not how it should be built. As soon as a non-technical client starts specifying a technical solution, there’s a real risk of locking the project into a guess.
Compare these two ways of expressing the same need:
- As a solution: “We need a database with a button that sends an email.”
- As an outcome and flow: “When a customer places an order, the caseworker should automatically be notified, so no order gets left sitting.”
The second phrasing states what should happen and why, but leaves the technology to those who know it. Maybe an email is the right approach, maybe there’s a better path – the vendor can only decide that once they understand the outcome you’re after.
A good way to structure this is to start from flows: describe step by step what a person should be able to do, from start to finish. “The caseworker logs in, sees today’s new cases, opens a case, sees the customer’s history, and can reply directly.” That’s understandable to everyone and keeps the focus on the business.
Demand answers you understand
A stubborn misconception is that technical answers have to be hard to understand, and that you as the client just have to nod along. That’s wrong. A skilled vendor can explain the complex in plain language.
Make it a principle, then, to demand understandable answers on everything concerning what you get, what it costs, and what consequences a choice has. If someone can’t explain why something takes as long as it does, or what the difference between two options means for you, that’s a warning sign – not a sign that you’re too uninformed.
Better to ask once too often. “Can you explain that as if I don’t know technology?” is a completely reasonable request, and the answer says a lot about how the collaboration will go. That’s also how we see our role: making the technical understandable to whoever owns the business.
When and how to bring in client-side support
Sometimes structuring the needs yourself isn’t enough. When the project is large, business-critical, or when you feel you’re at a disadvantage against the vendor, independent client-side support can be worth the money.
Client-side support is someone on your side who knows the technology and helps you ask the right questions and interpret the answers. The difference from the vendor is that the support has no stake in the solution – only in you getting what you need.
A concrete way to think about it: if you’re facing an investment that matters to the business and you’re unsure whether the quotes are reasonable, a couple of hours with independent support is often cheap insurance. For a smaller project, though, it can be plenty to describe outcomes and flows clearly and demand answers you understand.
Writing requirements without a technical background is therefore not just possible – it’s done every day by clients whose strength is knowing their business. Want to talk through how best to describe your need? You’re welcome to get in touch with a short description.
Frequently asked questions
Can I write requirements without technical expertise?
Yes. Your domain knowledge of how the business works is often more valuable than technical terminology. What you need is a way to structure that knowledge so the vendor understands the need. The technology is their responsibility. Your responsibility is to clearly describe what should be achieved and why.
How do I describe a need without knowing the solution?
Describe the outcome you want and the flow that should improve, not the technology. State what someone should be able to do and why, for example that a caseworker should be able to see a case's status without calling. Leave how it gets built to the vendor. That way, you don't lock yourself into a solution you've only guessed at.
Which answers should I insist on understanding?
Every answer that concerns what you get, what it costs, and what consequences a choice has. If a vendor can't explain something so that you understand it, that's a warning sign, not a sign that you lack expertise. Demand answers you actually understand. A good partner can explain the difficult in plain language.
When should I bring in client-side support?
When the project is large, business-critical, or when you feel at a disadvantage against the vendor. Independent client-side support is someone on your side who knows the technology and helps you ask the right questions and interpret the answers. For smaller projects, structuring the needs yourself may be enough, but for high stakes the support is often worth the cost.
What's the most common mistake a non-technical client makes?
Ordering a solution instead of a need. When you spell out exactly how something should be built, without a technical foundation, you lock the project into a guess and miss better paths the vendor could have suggested. Describe the problem and the desired outcome instead, and let the experts propose how to solve it best.