What devs need to know

The work we did yesterday — clearly specifying what you actually want — is often the hardest part of the development process. Congratulations, everything should be easy from here on out!

All joking aside, most development teams don’t get a clear understanding of what their task is and why it matters. Without that, they can’t move with direction or deliver with confidence. This is the communication gap that persists between developers and founders.

So, what should be done about it? Glad you asked. At a high level — and in non-technical terms — developers should be informed of:

1. The actual problem the customer is looking to solve: so they understand the “why” before jumping to a solution.
2. A high-level suggestion of how this might work from the user’s perspective: to give them a starting point without boxing them in.
3. An expectation, or upper limit, on how long this should take: to help scope the effort and surface misalignment early.
4. Any additional constraints to be aware of: so they don’t build something overly simple or overly complex.

Here’s what it looks like when all those inputs come together in a real-world task:

1. The customer needs to download historical reports.
2. The customer can click on the “Reports” menu and select any of the report types. In the actions section for a report, the user can click the download button. This will download the report as an Excel file using the current filters/date.
3. This should be completed within a week. Let me know if that isn’t attainable.
4. The report should download immediately. If that’s too slow, creating the report separately and emailing it is acceptable.

This gives the developer clear direction for the task — and enough space to suggest better ways of solving it. That’s why including the problem to be solved is so important.

By clearly specifying the task to be completed, the inputs into the development process are improved. Tomorrow, we’ll look at how TDD improves the outputs of that process.