Explaining Technical Concepts to Non-Technical Audiences Questions

Direct answer

The number doesn't change across audiences, but what it's evidence for does: to a CEO it's a business outcome (conversion, retention, cost), to external developers it's a reliability guarantee they can build on, to internal engineering managers it's a load and capacity signal. Same 30% improvement, three different "so what," each with the one metric that audience should actually track next.

Structured elaboration

The technique is picking, per audience, which consequence of the number they actually own:

1. Translate the metric into the currency that audience is measured on before stating it. A CEO is measured on revenue and retention; an external developer is measured on their own app's reliability; an internal engineering manager is measured on system load and incident risk.
2. Give exactly one metric to track next, not a dashboard's worth. Too many numbers reads as "we're not sure which one matters"; one number reads as a clear owner and a clear signal.
3. State the baseline and direction explicitly, down from 500ms to 350ms, not just "faster," so nobody has to ask what the improvement actually was.
   This same three-move pattern is what you would reuse for a different metric to the same or different audiences: messaging a lazy-loading improvement to executives, sales, and developers, an API deprecation to engineering, customers, and executives, or a throughput doubling to a CTO, operations, and sales. The technique is constant; only which consequence you lead with changes per audience.

Worked example

p95 latency means the response time that 95% of requests are faster than, so it's a measure of how slow the worst-but-common cases are, not the average case.

To the CEO: "We cut the time it takes customers to sign in from half a second to a third of a second, 500ms to 350ms, a 30% improvement, on the slowest 5% of requests, the ones customers actually notice as lag. Faster sign-in means fewer people abandoning at login and less friction on every visit. Metric to track: conversion rate on the sign-up-to-first-action flow over the next two weeks, to see if that translates into fewer drop-offs."

To external developer customers: "Our authentication endpoint's p95 latency, the response time 95% of your calls beat, dropped from 500ms to 350ms. You should see fewer client-side timeouts and retries against this endpoint. Metric to track: your own timeout and retry rate against our auth endpoint, it should trend down."

To internal engineering managers: "We cut auth p95 from 500ms to 350ms through caching and query tuning, which lowers tail latency for every downstream service that calls auth before doing its own work. Metric to track: queue length and tail latency on the services immediately downstream of auth, to confirm the improvement is propagating rather than just moving the bottleneck."

Trade-offs and pitfalls

Reusing the same "30% faster" framing for every audience without a metric attached invites the follow-up "compared to what, and how would I know it's working," which is exactly what the per-audience metric answers in advance. It's also a mistake to promise a business outcome, like "this will increase conversion," as a fact rather than a hypothesis. Latency and conversion correlate but aren't guaranteed to move together for every product, so the honest version says "we would expect to see," not "this will." And if a later measurement shows a segment of customers saw no improvement, say a region or client version, that needs its own honest message rather than folding it quietly into the aggregate number.

Direct answer

CAP theorem (Consistency, Availability, Partition tolerance) says that when a distributed system's network partitions, some nodes cannot talk to others, you must choose between staying available (keep answering requests) or staying consistent (guarantee every reader sees the latest write); you cannot fully guarantee both during that partition. For a product manager, the useful frame is not the three-letter acronym, it is the trade-off it forces: during a network problem, do we serve possibly-stale data, or do we go silent until we're sure the data is correct? Two analogies below make that concrete, plus where each one starts to mislead.

How to build and stress-test an analogy like this

• Start from something the audience already manages themselves so the coordination problem is intuitive without teaching new vocabulary.
• Map only the DECISION the concept forces (here, what happens when parts can't talk), not every mechanism. If you find yourself trying to represent quorum writes or version numbers in the analogy, you've picked the wrong analogy or gone too deep.
• Stress-test it before using it: ask yourself what a sharp follow-up question would reveal is wrong with it. If it has no honest breaking point, you haven't tested it hard enough, you've only used it once.
• Name the breaking point out loud, before they find it. That's the senior move: it turns a limitation into evidence you understand the real system, instead of a gotcha that undermines the analogy later.
• The same loop, familiar system, one decision, explicit breaking point, works for any concept in this family: explaining algorithmic complexity (Big-O) to a PM, a model's bias/variance trade-off to a stakeholder, why a prediction leans on certain inputs (SHAP values), or why Raft consensus needs a leader election before it can make progress.

Worked example

Analogy 1: bank branches during a network outage. A bank has several branches connected by a private network. A customer withdraws money at Branch A. If the network to Branch B is up, Branch B's ledger updates immediately, every branch shows the correct new balance (Consistency). If a cable gets cut between the branches (a partition), Branch B has two choices: let customers keep withdrawing using its last-known balance (Availability, but the balance might be wrong), or refuse withdrawals until the network is fixed and balances can be confirmed (Consistency, but Branch B is unavailable). What it captures well: the forced, binary choice under a partition, and that it's a business decision, not a bug to fix. Where it breaks: real banks resolve most of this with human reconciliation and legal recourse, an incorrect balance gets corrected by staff, with clear liability rules. Distributed databases usually make this choice automatically, in milliseconds, with no human in the loop, so the "someone will sort it out later" comfort the analogy implies isn't actually available.

Analogy 2: two people, one shared paper shopping list, two different stores. You and a partner keep a shared shopping list at home but each take a photo before heading to a different grocery store. While your phones have signal, any item one of you crosses off can be relayed to the other, so the list stays in sync (Consistency). If both phones lose signal at once (a partition), you each keep shopping off your own photo, you stay productive (Availability), but you risk both buying milk, or neither of you buying it, because neither photo reflects the other's crossed-off items. What it captures well: a partition doesn't stop work, it stops coordination, and the resulting inconsistency is a direct, visible consequence of choosing to stay available. Where it breaks: reconciling two shopping lists is cheap and forgiving, worst case you return the extra milk. Reconciling two halves of a financial ledger or an inventory count is not cheap or forgiving in the same way, so the analogy understates how expensive real clean-up can be.

Trade-offs and pitfalls

Don't let either analogy imply CAP is a permanent, top-level architecture choice; it applies at the moment of a partition, and most systems are both consistent and available the rest of the time. That's the single most common misunderstanding a PM walks away with if you aren't explicit about it. Also resist collapsing CAP into "consistency vs speed," that conflates it with the separate latency/consistency trade-offs many systems make even without a partition. And don't use the analogy to make the decision for the PM, the job here is to make the trade-off legible so they can weigh it against the product's actual tolerance for stale data.

Direct answer
In fifteen minutes, spend the first couple of minutes stating the proposal and the outcome it changes, then work through the two or three concerns you believe the PM actually has, each translated into a before/after consequence rather than a technical justification, and close with one concrete ask. Credibility here comes from showing you understand their worry and can explain it in their terms, not from a persuasion pitch.

Structured elaboration
Agenda for the fifteen minutes:

• 0-2 min: name the change and the outcome it targets, one sentence each ("we're proposing X so that Y improves").
• 2-4 min: name their likely skepticism before they raise it ("you're probably wondering if this breaks Z"). Saying their own concern out loud, correctly, builds more trust in two minutes than a slide deck does.
• 4-11 min: two or three points, each translated from a technical justification into a plain consequence.
• 11-13 min: the caveat, stated plainly, not buried.
• 13-15 min: the concrete ask (a decision, a number they want to see, a follow-up).

Three concrete moves for building credibility without jargon:

1. Show your reasoning, not just your conclusion, in plain language. "We tested this against last month's real traffic and it held" reads as credible; a method name does not, it's just harder for them to check.
2. Anchor every point to something they already track: a KPI, a complaint they've heard, a number already on their dashboard.
3. Volunteer the weakness before they find it. Naming a real limitation up front reads as more credible than a flawless pitch, because it signals you're not hiding anything.

Worked example
Technical approach: adding a cache in front of a recommendation service.

• Jargon: "We'll add a Redis cache layer with a five-minute TTL in front of the recommendation microservice to cut p95 latency."
• Plain: "Right now, every time someone opens the app we recompute their recommendations from scratch. We're going to start reusing that answer for five minutes before recomputing."
• Analogy: like a barista who doesn't remake your usual order from scratch if you order it twice in a row within a few minutes, they just pour the one they already made.
• Where it breaks: if the PM asks "so I might see stale recommendations," the honest answer is yes, for up to five minutes after something changes, like adding an item to a cart. Naming that boundary before they ask is the actual credibility move, not the analogy itself.

Two variants of the same fifteen minutes:

• Defending a claimed 40% throughput number live: don't re-explain the benchmark methodology. Translate the number into a consequence and offer the receipt: "40% more requests per second means, at our busiest hour, this service stops being the bottleneck. I can show you the load test afterward if you want the detail." State the number, translate it, offer to verify, and stop there unless asked for more.
• Keeping a mixed audience engaged in a live demo: pause after each new idea and ask a specific question ("does that match what you're seeing?") rather than "any questions?"; narrate what you're about to click before you click it, so non-technical viewers don't lose the thread mid-action; keep one screen in reserve for anyone who wants to go deeper afterward, so you're not tempted to over-explain to the whole room.

Trade-offs and pitfalls
Skipping the caveat to sound more confident backfires the moment the limitation surfaces later, and it will. Loading up on technical proof to seem credible can read as defensive; a skeptical PM usually wants evidence you understand their risk, not evidence you're smart. Keeping it non-technical shouldn't tip into vagueness, a specific "five minutes" beats a vague "briefly cached." And ending without a concrete ask wastes the fifteen minutes; always close with what you want them to do next.

Direct answer

A legend that actually gets used has as few visual dimensions as possible, and each one carries exactly one meaning. I standardize on a small vocabulary (shape means component type, color means one thing like trust boundary or environment, line style means one thing like sync versus async) and I put a short label next to any icon that could plausibly mean two different things, rather than trusting the icon to speak for itself.

Structured elaboration

I organize the legend around a few categories, each with one job:

• Icons and shapes for component type. Rectangle for a compute service, cylinder for a data store, cloud outline for an external managed service, diamond for a decision or manual approval point. Each icon carries a short label with the actual service name and owning team, so the shape alone never has to carry the full meaning.
• Color for exactly one dimension. I pick one axis, most often trust level or environment (for example, green for internal, blue for customer-facing, orange for third-party), and I do not let color also imply something else like risk or status. Color-only meaning also fails for colorblind readers, so every color-coded element gets a redundant label or pattern, not color alone.
• Boundaries and grouping. A solid rounded box marks a deployment or service boundary; swimlanes mark team ownership. Arrow style is reserved for data flow semantics only: solid for synchronous calls, dashed for asynchronous or event-driven calls.
• A visible version and owner on every diagram. Diagrams drift out of date silently unless the legend itself forces a last-updated date and an owner to appear on the page.

The test I apply to every symbol before it goes in the legend: could two people in the room (one from security, one from product) each read this icon and land on a different meaning? If yes, it needs an explicit label, not just a prettier icon.

Worked example

Two genuinely ambiguous elements and how the legend resolves them:

1. An envelope icon on a connecting line. Read literally, this could mean a message queue or an actual email being sent. The legend resolves it by banning the bare envelope icon: a queue is drawn as a cylinder labeled with the actual technology ("Queue: Kafka"), and an outbound email is drawn as an external cloud icon labeled with the provider ("Email: SES"). No icon is left to carry that distinction alone.
2. A blue-colored box. Under a naive scheme, blue could mean "public-facing" or just "this team's color." The legend fixes the meaning: blue is reserved for customer-facing surfaces only, and it is always paired with a solid rounded border for "public-facing service." If a service is public but sits behind a web application firewall, that gets an explicit shield icon added rather than a new color, because color is only allowed to encode the one dimension it was assigned.

Trade-offs and pitfalls

• A notation system with too many dimensions (shape, color, border weight, icon, badge) is worse than a smaller one, because nobody memorizes six conventions; they revert to guessing, which is exactly the ambiguity the legend was supposed to remove. I keep the total vocabulary small enough to fit on one printed page.
• A legend that lives in a separate document from the diagrams decays fast: people update the diagram and forget the legend exists. Embedding the legend on the diagram itself, or enforcing it through a shared template in the diagramming tool, costs more up front but is the only version that survives six months of edits.
• Documenting a convention is not the same as enforcing it. Without a lightweight check (a template default, or a reviewer checklist item on architecture PRs), individual authors will quietly invent their own shorthand, and the legend becomes aspirational rather than actual.
• The legend has to match what the team's actual tool can render. A convention built for draw.io's rich icon set will not survive a move to Mermaid or another text-based diagram tool with a much smaller icon vocabulary, so the notation should be designed around the tool people will really use day to day.

Direct answer

Three moves turn a jargon sentence into something an executive can act on: lead with the business outcome instead of the mechanism, swap engineering verbs for plain ones, and reach for an analogy only when it doesn't overstate what's actually guaranteed. None of that means removing information, it means reordering it so the part the executive needs to decide on comes first.

Structured elaboration

1. Lead with outcome, not mechanism. State the risk, cost, or benefit first, then attach the technical action as the "how," not the headline.
2. Replace engineering verbs with plain ones. "Rotate," "provision," "deploy" mean nothing to someone outside engineering; "renew," "set up," "roll out" carry the same meaning without the vocabulary tax.
3. Use an analogy only when it survives a follow-up. An analogy that implies a stronger guarantee than the system actually provides, calling an eventually-consistent system "instant," will bite you the first time it breaks in front of the audience.
   These three moves aren't limited to a single sentence. The same reordering scales to a longer live session, for example a technical workshop script: open with the business outcome for the whole session, and only layer in the underlying mechanism as the audience asks for it, rather than front-loading the architecture before anyone hears why it matters to them.

Worked example

Jargon: "We need to rotate TLS certificates and update our ingress controllers."
Executive version: "We need to renew a security certificate before it expires, and update the component that routes incoming traffic to our services, so customer connections stay encrypted and the site doesn't go down when the old certificate lapses."
Why it's better: the executive version leads with the two things that matter to a non-engineer, security and uptime, keeps the concrete nouns (certificate, routing) but strips the internal name ("ingress controller"), and states the consequence of not acting, the site goes down, instead of leaving the urgency implicit in "we need to."

Trade-offs and pitfalls

Over-simplifying into a metaphor that implies a false guarantee is worse than leaving a term untranslated, because it sets an expectation you can't meet. Calling a best-effort backup "instant recovery" is the kind of thing that gets quoted back to you during an actual incident. Stripping out every technical noun can also read as evasive: "we made some changes" invites more scrutiny than naming the certificate and the routing layer, which sound concrete and controlled. The goal is removing vocabulary that requires domain training, not removing the substance of what changed.