How to work with developers when you're not technical

Before we get into process, questions, and collaboration, it’s worth grounding this in something important. You are the expert in:

• Your business model
• Your customers and users
• The problem you’re trying to solve
• The commercial outcomes you need

Developers are the experts in:

• How to build scalable, maintainable solutions
• What’s technically feasible (and what isn’t)
• The trade-offs between speed, cost, and complexity
• How to bring an idea to life in the real world

When those two perspectives come together properly, that’s where great products happen. Where things go wrong is when one side tries to do the other’s job. Either partners feel like they need to dictate technical solutions, or development teams build in isolation without enough context.

Good collaboration sits right in the middle.

You don’t need to know how the code works, but you do need to understand how the work flows. A typical app development process looks something like this:

1. Discovery & definition – understanding the problem, users, and goals
2. Design & prototyping – shaping the experience and validating ideas
3. Development – building the product in structured iterations
4. Testing & refinement – identifying issues and improving quality
5. Launch & iteration – releasing, learning, and evolving

That’s the simplified version, but the key thing to understand is this:

It’s not linear. It’s iterative.

Things will be explored, tested, challenged, and sometimes changed. And that’s not a sign that says something’s gone wrong, it’s a sign the team is doing their job properly. In fact, research from the Standish Group’s CHAOS Report consistently shows that iterative, agile approaches significantly improve project success rates compared to rigid, fixed-scope delivery models.

So instead of expecting a straight line from idea to launch, expect a process of refinement.

One of the biggest shifts for non-technical partners is realising that you don’t need to provide solutions, all we need from you is to provide clarity. And that comes through the questions you ask.

Instead of:

• “Can we build it this way?”

Try:

• “What’s the simplest way to achieve this outcome?”
• “What are the trade-offs if we do it like this?”
• “How might this scale if usage grows?”
• “Is this solving the user’s problem, or just adding complexity?”

These questions do two things:

1. They give the development team room to bring their expertise
2. They keep the focus on outcomes, not assumptions

And that’s where better decisions come from.

There’s a middle ground here that’s worth aiming for.

You don’t need to go deep into technical detail, but having a basic understanding of a few key concepts makes collaboration smoother. It means conversations don’t stall, and you’re not constantly feeling like things are going over your head.

Think of things like MVPs, scalability, APIs, or technical debt. You don’t need to explain them in detail, just recognise what they mean and why they matter.

It’s a bit like learning the rules of a game before you watch it. You’re not playing professionally, but you can follow what’s happening and understand the decisions being made.

This is where balance really matters. If you completely step back and leave everything to the development team, you risk ending up with something that works technically but misses the mark commercially. But if you try to control every decision, you slow things down and limit the value the team can bring.

The sweet spot sits somewhere in the middle. A good team will explain their thinking, flag risks early, and be open about trade-offs. You should feel comfortable asking questions when something doesn’t make sense, but you don’t need to challenge the technical details for the sake of it.

Stay involved, stay curious, but let the team do what they’re there to do.

If there’s one role that makes this whole process feel easier, it’s the Product Manager. They sit right in the middle of everything. Translating what you need into something the team can build, and translating technical decisions back into something that makes sense from a business perspective.

More importantly, they keep things aligned. They’re the one making sure the project doesn’t drift, that priorities stay clear, and that decisions are made with the bigger picture in mind. They’re also there to challenge you when needed, not just agree with everything.

The more open you are with your PM, the better this works. Do things such as sharing context early, being honest about constraints and letting them in on the pressures you’re dealing with internally. That’s what allows them to guide the project properly, rather than just manage it.

Every decision in development comes with a trade-off.

• Faster delivery vs. long-term scalability
• Lower cost vs. flexibility
• Simplicity vs. feature richness

There is no “perfect” solution, only the right solution for your goals. According to McKinsey, 70% of digital transformation projects fail to meet their objectives, often due to poor alignment between business goals and execution decisions.

That misalignment often shows up in decisions where trade-offs weren’t fully understood or agreed on. The best way to handle this is to:

• Be clear on what matters most (speed, cost, quality, scale)
• Ask what you’re giving up with each decision
• Align on priorities early

When everyone understands the trade-offs, decisions become much easier.

If you’d like to learn more about the truth about cost, quality and time in app development, read our blog.

At some point, you’ll start seeing designs, prototypes, or working features. This is where your input really starts to influence the outcome. And this is where the quality of feedback matters.

Saying something doesn’t feel right is fine, but it’s much more useful to explain why. What feels confusing? What doesn’t match how your customers behave? Where does it feel like the journey breaks down?

The more you can tie feedback back to real user behaviour or business goals, the more actionable it becomes. That’s what helps the team make meaningful improvements, rather than surface-level changes.

If there’s one thing that consistently makes projects successful, it’s not technical brilliance: it’s communication. We will be having regular check-ins, honest conversations, clear expectations and early problem-solving.

Research from PMI shows that poor communication is a primary contributor to project failure in nearly one-third of cases. So if you’re ever unsure where to focus your energy, focus here:

• Are we aligned on goals?
• Are we raising issues early?
• Are we making decisions together?

That’s what keeps things on track.

It’s worth repeating, because this is the part people tend to overcomplicate. You don’t need to understand the code to build a successful product.

You need to be clear on the problem. Stay engaged in the process. Ask good questions. Communicate openly. Trust the team around you. That’s what moves things forward.

When this works properly, it stops feeling like a handover between “partner” and “developer.” It feels like a shared effort because there’s trust in the room, there’s space to challenge ideas and there’s a sense that everyone’s working towards the same outcome, not just ticking off tasks.

And that’s usually the difference. Not how technical anyone is, but how well they work together.

You don’t need to be technical to create a great product, you just need the right team around you. We’ll help you shape the thinking, guide the process, and build something that delivers real results.