How Do You Talk About Apps With Non Tech People?

There is a particular kind of meeting that product teams know well. Someone from finance, or operations, or the board, sits down to hear about what the app does next. The team talks about API calls, interaction states, progressive disclosure, onboarding flows. The non-technical people nod. They ask a few questions about cost and timeline. Then the meeting ends and everyone assumes they are aligned.

The gap between what a product team means and what a non-technical stakeholder hears is wider than either side usually realises.

They are not aligned. The nodding was polite uncertainty, and the questions about cost were the only ones they felt confident asking. Everything else, what the product actually does, what users will feel when they open it, whether the proposed changes will make it better or just different, remained opaque.

We see this across every kind of product conversation, from pre-investment pitches to internal reviews to client workshops. The language that product people use is precise, but it is precise in a way that excludes the people who matter most to a product's direction. Getting this translation right is not a soft skill or a nice-to-have. It determines whether the right decisions get made, and whether the people with the authority to make them actually understand what they are deciding.

Why Non-Technical Stakeholders Struggle to Visualise App Decisions

An app, to someone who did not build it and does not use it daily, is largely invisible. They see the icon, maybe they have opened it once or twice, and they have a general sense of what it is for. But the decisions that shape how it works, what happens when a user taps a button, how data moves between screens, what the system does when something goes wrong, are completely abstract to them.

This is a failure of context. Product teams build up a mental model of their product over months or years. That model is rich and detailed, full of interdependencies and constraints they understand intuitively. A non-technical stakeholder has none of that scaffolding. When the team explains a proposed change, they are asking someone to add a room to a house they have never seen the floor plan of.

The insider bias problem runs deep here. People who know a product well will naturally find it intuitive because they already understand its logic. A new user, or a stakeholder who is functionally a new user, approaches the same product with no such frame. What the team considers obvious is not obvious to them, and the explanations that should help often assume the very knowledge they lack.

The Language Gap Between Product Teams and Everyone Else

Product language is full of terms that have precise technical meanings but sound like ordinary words to someone outside the discipline. "Flow" sounds like something simple. "State" sounds like a geography lesson. "Component" sounds like a spare part. When a designer says the onboarding flow needs to account for different user states, they mean something very specific. When a non-technical stakeholder hears it, they may nod while understanding very little of the actual decision being made.

The problem compounds when teams use shorthand that assumes shared experience. Referencing what a competitor's app does, or what a previous version of the product did, only works if the person in the room has used those things. Often they have not.

We have found that the language gap is rarely about complexity. Most of the concepts in product design are not inherently difficult. They become difficult when they arrive without the analogy or context that would make them land. A well-chosen everyday comparison, explaining a notification permission request as asking a guest if you can send them a letter before you write one, can make a governance conversation move faster than ten minutes of technical explanation.

What Happens When That Gap Goes Unaddressed

The most common outcome is false consensus. Stakeholders leave meetings believing they understood the decision. Teams leave believing they have sign-off. Neither is quite true, and the gap surfaces later, usually at a point where changing course costs real money.

We worked with a pre-investment client whose investor conversations covered technology, marketing, and market size without ever touching on how the product would feel or what user retention looked like. The silence was read as approval. What it actually indicated was that investors had not grasped the emotional dimension of the product at all. They had no framework for asking about it, so they did not. We had to go back and cover that ground explicitly, because accepting the absence of questions as alignment would have left a real gap in what investors understood they were backing.

When questions dry up, it does not mean everyone is fully on board.

A separate and more expensive version of the same problem happens inside teams. When stakeholders cannot visualise what a product does or why a design decision matters, they tend to fill the gap with feature requests. If they cannot evaluate what exists, they propose additions. We saw this clearly on a sports club app, where two co-founders were so embedded in the world the app served that scope control became genuinely difficult. Both founders pushed independently and consistently to add more features, each convinced their additions were obvious and already implied by the brief. The inability to hold a shared, concrete picture of the product made every conversation about scope feel like it was starting from scratch.

How to Explain Core App Concepts Without Jargon

The starting point is to identify what the person in front of you actually needs to understand in order to make a good decision, and then find the shortest path to that understanding. That path almost never runs through technical explanation.

Translate decisions, not features

When explaining what a proposed change involves, frame it as a decision with consequences rather than a technical implementation. A stakeholder does not need to know what progressive disclosure is. They do need to know that there is a choice between showing users everything at once, which can feel overwhelming, and revealing information in layers as users are ready for it. Frame it that way and the conversation becomes one they can participate in meaningfully.

Use comparisons that already exist in their world

Good translation uses things the stakeholder already understands as scaffolding. A notification that appears at the wrong moment in a user's journey is like a salesperson approaching you the second you walk through the door before you have had a chance to look around. That comparison is immediately accessible. It carries the emotional stakes of the decision without requiring any technical context.

Before any meeting with non-technical stakeholders, write down the three decisions you need them to make and the single most important thing they need to understand about each one. If you cannot explain it in one sentence using no product terms, you are not ready to present it.

When Silence in the Room Does Not Mean Agreement

Non-technical stakeholders often go quiet not because they agree but because they do not know what question to ask. Product decisions sit in a domain they have not mapped. They can sense that something matters without being able to articulate why, and in a room full of people who clearly know more about the technical side, the socially easy move is to stay quiet and hope the experts have it covered.

This is worth surfacing directly rather than reading the room wrong. The most useful thing a product team can do is give non-technical stakeholders a vocabulary for the thing they are sensing. If someone looks uncertain but says nothing, asking them what feels off to them, rather than whether they have any questions, is a completely different invitation. One asks them to generate a question from nothing. The other asks them to name a feeling they already have.

Support requests and stakeholder feedback carry the same signal at a different scale. When the same confusion surfaces repeatedly in different forms, that pattern points to a specific problem in the product. The specifics of what people ask for help with are often more honest than anything said in a formal review. Reading those patterns is a different kind of listening, but it is listening to the same underlying uncertainty.

After presenting a significant product decision, ask the room: "What would make you feel less confident about this?" It surfaces doubt without asking people to admit they did not follow the explanation.

How Honest Conversations Prevent Expensive Mistakes

Honest product conversations are uncomfortable in the short term and cheap in the long term. The reverse, comfortable conversations that paper over real uncertainty, tend to produce expensive surprises.

A founder in the football industry came to us early in their build with a colour-coded spreadsheet mapping competitor products, with the ambition of merging several of them into one. They were visibly excited. We started asking questions about prospective users: why would someone choose an all-in-one product over a specialist app they already trusted? Would consolidation mean every feature did its job less well? The founder became deflated. But those questions were the right ones to ask before a build started, not after one had been paid for and shipped.

Being honest about what will make a product succeed is the job. The discouragement comes from letting momentum carry a flawed brief forward until the costs of changing it are real. The conversation that surfaces a problem in a meeting room is always less expensive than the one that surfaces it in a live product.

When stakeholders understand enough to push back, when they can point at a decision and say that it does not feel right even if they cannot explain exactly why, that is a sign the translation is working. A stakeholder who can do that is genuinely engaged, not just present.

Applying a New Design Layer to Existing Code: Why Context Matters

One area where translation breaks down particularly badly is the conversation about redesigning or improving a product that is already built. Non-technical stakeholders often assume that if the app works, changing how it looks or feels is a matter of visual adjustment. The underlying code stays the same, and the new design sits on top of it. The reality is usually more complicated, and explaining why matters before work starts.

We were brought in to improve the emotional layer of a wellness genetics product, a data-heavy product for a premium wellness brand that had been built in a functional way that did not match the brand's feel. When our designs moved to the development team, a third-party designer had produced something visually luxurious, but the development team struggled to understand how to implement it on top of their existing codebase. What followed was a period of back and forth that took time and budget to resolve. The designs were right. The translation between what the designs asked for and what the existing code structure could accommodate had not been managed carefully enough from the start.

The lesson is that the conversation about what a new design layer requires, technically, in terms of time, and in terms of the constraints imposed by existing code, needs to happen before everyone has agreed on what the end result will look like. Stakeholders who understand that constraint early make better decisions than those who discover it halfway through.

When presenting a design improvement on an existing product, include a brief explanation of what the current code structure allows and what it does not. Frame it as the starting conditions, not as a problem, it gives stakeholders a realistic picture of what change costs.

When Stakeholders Are Too Close to the Product

A different kind of communication failure happens not when stakeholders are too far from the product but when they are too close to it. Founders and senior product owners who use the product daily, who built the category it sits in, and who are deeply invested in its success can be some of the hardest people to have honest product conversations with, not because they are difficult, but because their familiarity creates blind spots that are hard to name.

The sports club app is a clear example of this. The two co-founders lived in the environment the app was built for. The app was the business, not a marketing layer on top of one, which meant every design decision felt personal. Both founders pushed to add more features throughout the build, each convinced that what they were suggesting was obviously needed. Holding scope in that context required constant, explicit conversation about what the product was for and what adding a feature would cost, in build time and in the user experience of someone coming to the domain fresh.

Closeness to a product is genuinely valuable. Founders often know things about their users that no amount of research would surface. The problem is when that closeness becomes a substitute for the user's perspective rather than a supplement to it. Creating space for an outside view, and making that space feel safe rather than critical, is one of the things a good product conversation does.

Making Translation a Habit, Not a Crisis Response

Teams typically treat translation as something they do when a misunderstanding has already surfaced. A stakeholder says something that reveals a gap in their understanding, and the team pivots to explain it. That works in the moment, but it means the gap existed undetected for however long it took to surface, and decisions made in that period were made on incomplete understanding.

Building translation into the regular rhythm of how a team communicates is a different approach, and a more reliable one. This means choosing one framing for each significant product concept and using it consistently across documents, meetings, and conversations. It means checking, before any formal review, whether the people in the room have the context they need to engage meaningfully, and providing it in advance rather than on the spot.

It also means developing a short set of reference points that non-technical stakeholders can hold onto across multiple conversations. When those reference points are stable, when "the layer between the data and the user" always means the same thing, stakeholders can build a working mental model of the product over time rather than starting from scratch at each meeting.

• Agree on a small shared vocabulary before projects begin and use it consistently
• Send a one-paragraph context note before meetings where decisions will be made
• After each significant review, confirm what was decided in plain language and circulate it
• Build in a standing five minutes at the start of stakeholder meetings to orient everyone to where the product currently is

None of this is particularly complicated. It requires discipline more than skill, and the return on that discipline is a set of stakeholders who can genuinely contribute to product decisions rather than approve things they do not fully understand.

Conclusion

Talking about apps with non-technical people is a skill that product teams underinvest in, partly because it looks like communication rather than design, and partly because the gaps in understanding are often invisible until they cause a problem. But the decisions that shape a product are made in rooms where not everyone has the same mental model, and the quality of those decisions depends on how well the people in them understand what they are actually deciding.

The wellness genetics project, the sports club app, the pre-investment investor conversations, what runs through all of them is the same underlying problem. When the people with the authority to make decisions do not fully understand the thing they are deciding about, the outcomes are worse than they need to be. The fix is to build the kind of ongoing, honest conversation that gives non-technical stakeholders a genuine picture of what they are looking at.

That kind of conversation starts with recognising that silence in a room is information, that familiarity with a product is not the same as understanding it as a user would, and that the most useful thing a product team can do is make its thinking legible to the people who need to act on it. Doing this well is a practice that runs through every meeting, every document, and every decision.

If the conversations around your product are producing nodding rather than genuine engagement, let's talk about how to change that.

Frequently Asked Questions