How to Communicate with Your Development Team (If You're Not Technical)

You don't need to learn to code. But you do need to learn how to describe what you want in terms your developers can act on.

The biggest source of waste in software projects isn't bad code or slow developers. It's miscommunication. A feature gets built, the client looks at it and says "that's not what I meant," and a week of work gets thrown away. This happens because developers and non-technical stakeholders think about problems differently.

Describe the problem, not the solution

"I need a dropdown with checkboxes" is a solution. "Users need to filter the list by multiple categories at once" is a problem. Developers are good at finding solutions - but only if they understand the problem. When you specify the UI, you cut off better options the developer might have suggested.

Use examples

Screenshots, sketches, and links to existing products that do something similar are worth more than paragraphs of description. "I want it to work like Stripe's billing page" gives a developer more information in six words than a page of requirements.

Good feedback vs. bad feedback

• Bad: "This doesn't feel right." Good: "The checkout button is hard to find - can we make it more prominent?"
• Bad: "Can you make it pop more?" Good: "The headline and body text look the same weight - can we make the headline bigger or bolder?"
• Bad: "This is too slow." Good: "This page takes 4 seconds to load. Our competitors load in under 1."
• Bad: "Add some AI to it." Good: "Can we auto-categorize incoming tickets based on their content?"

Ben Arledge

CEO & CTO, CloudOwl