Getting Started · 5 min read

Every client I work with comes in slightly apologetic about not being technical. They say things like "I don't really know how this stuff works" or "you probably think this is a dumb question." They assume that because they can't write code or explain what an API does, they're somehow behind. Like they need to catch up before they're allowed to have an opinion.

But here's the thing. I don't need them to know how the tech works. I need them to know their industry. And they do. That's why they're in the room.

Your domain knowledge is the thing I can't Google

I can learn the basics of any industry in a week. I can read the regulations, study the competitors, and understand the general workflow. But I can't replicate fifteen years of lived experience. I can't replicate the intuition that comes from doing the work every day, from talking to real customers, from knowing which problems are annoying and which ones are genuinely costing people time, money, or safety.

A client in the trades knew exactly which exam questions tripped people up. They knew the study patterns that failed. They knew what the real gap in the market was, not from a report, but from years of watching colleagues struggle with the same certification process. That knowledge shaped every design decision we made.

Another client building a messaging app understood the emotional nuance of text communication better than any psychologist I've read. They could tell me exactly when a message feels supportive and when it feels dismissive, and why the difference matters to their users. No tech background required. That's domain expertise, and it's the most valuable input in the design process.

The research backs this up

Eric Von Hippel's research at MIT, published in Management Science back in 1986, found that 87% of successful product innovations came from lead users, people with deep domain expertise who understood the problem intimately. Not from technologists. Not from general users. From the people who lived the problem every day.

That's you. You're the lead user. You know the pain point because you've felt it. You know the workaround because you've been using it for years. You know the customer because you are the customer, or you serve them directly. That gives you an advantage that no amount of technical training can replace.

My job is to take that knowledge and translate it into something that works on a screen. Your job is to bring the knowledge. And you already have it.

Stop apologising and start leading

The next time you're in a design meeting and you feel the urge to say "I'm not sure if this is a stupid question," stop yourself. Ask the question. It's probably the most important thing that's been said in the meeting. The questions that come from genuine industry experience, the ones that start with "but in the real world, this wouldn't work because," those are the questions that save projects from building something technically impressive but practically useless.

You don't need a tech background to build a great app. You need a deep understanding of the problem and the people who have it. If you've got that, you're not the person who needs to catch up. You're the person everyone else in the room needs to listen to.

Sources
Lead Users: A Source of Novel Product Concepts (Von Hippel, 1986, Management Science) - 87% of innovations come from lead users with deep domain expertise, not from general users or technologists.

Related blog posts:

Why subject matter experts build the best apps

You don't need a technical co-founder

Don't forget to do your homework

Got deep industry knowledge and an app idea?

Book a free 20 minute call. Tell me about your idea. I'll be honest about whether this is the right fit. And if it is, we can start within the week.

Book a free 20 minute call