June 26, 2025

🧠 If Your PM Doesn’t Get It, You’re Explaining It Wrong (Use This Trick Instead)

_{Hello Hello!}

_{I've been lucky to spend most of my career as a developer — and these days, I work as a product manager. That gives me a pretty unique perspective. I've lived on both sides of the fence, and I get where both roles are coming from.
I remember looking at PMs in the past and thinking, "This person doesn’t know what they’re talking about."}

_{The truth? I wasn’t putting myself in their shoes. Back then, I only valued technical skills — but I’ve come to see that PMs bring an entirely different (and essential) set of skills to the table. They're a key part of building great systems, products, and software.}

_{Today, I want to help you improve how you communicate with this kind of professional.}

_{A PM is your partner — someone who helps clear the path so you can focus and do your best work. But that only happens when there’s trust and a bit of rapport between you.}

_{Hope this helps you get one step closer to that.}

_{Note: In the context of this email, when I say “PM,” I’m referring to either Product Manager or Project Manager. Yes — they’re different roles, of course. But for the sake of simplicity (and because many of the same communication principles apply), I’m grouping them together here on purpose.}

_{— Aderson}

---

🧠 If Your PM Doesn’t Get It, You’re Explaining It Wrong (Use This Trick Instead)

Ever finish explaining something to a PM and get that polite-but-confused look in return? They nod… smile… then ask a question that shows they didn’t get any of it.

Frustrating, right?

Here’s the question I hear from devs all the time: “How can I explain this in a way that actually lands?”

You don’t need to simplify your brain. You just need to translate. And one of the best ways to do that? Analogies.

When done right, analogies build a bridge between what you know and what they understand.

---

3 Ways to Make Analogies Work (Even If You’re Not “Creative”)

• 🧩 Anchor New Ideas to Familiar Ones
• 🔧 Use Everyday Objects, Not Tech Jargon
• 🗣️ Test and Tweak Based on Their Reaction

---

🧩 Anchor New Ideas to Familiar Ones

Here’s the secret: people understand new things by connecting them to things they already know.

That’s the whole job of an analogy.

If you're explaining an API, don’t dive into endpoints, headers, and payloads. Try this: "Think of the API as a restaurant menu. You choose what you want (the request), the kitchen prepares it (the backend), and the waiter brings it back (the response).”

That’s instantly relatable. Everyone’s been to a restaurant.

Good analogies collapse complexity into something the brain can grab onto.

Before your next meeting, ask yourself:

• What does this remind me of in real life?
• Is there a process, object, or experience that works the same way?

You don’t need to be clever. You just need to be clear.

---

🔧 Use Everyday Objects, Not Tech Jargon

The best analogies use things people can see, touch, or imagine easily.

✅ Use:

• Maps
• Kitchens
• Construction sites
• Traffic systems
• Filing cabinets
• Lego blocks
• Toolboxes

❌ Avoid:

• Compiler metaphors
• OS-level references
• Niche code abstractions

Example: Explaining microservices? Try: "It’s like having multiple food trucks instead of one giant kitchen. Each truck handles its own menu and can be replaced without shutting down the entire operation."

That hits way better than saying: “They’re modular units that decouple business logic via isolated deployments.”

Your PM’s not dumb — but they’re not in your head. Your job is to bring the concept to them.

---

🗣️ Test and Tweak Based on Their Reaction

Don’t just drop the analogy and move on. Watch their reaction.

Do they light up and nod? You’re golden. Do they look more confused? Time to try another comparison.

Analogy-building is a skill you develop over time — and yes, it’s learnable.

Try this:

• Before your meeting, jot down 1–2 analogies you might use.
• After the meeting, note what worked and what didn’t.
• Refine and reuse the ones that clicked.

Over time, you’ll build your own personal “analogy toolbox.”

And when your PMs get it faster, your projects move faster. Your meetings get shorter. Your influence goes up.

---

Final Thoughts

You don’t need to explain less — you need to explain differently.

Analogies aren’t about dumbing things down. They’re about making ideas portable — so the people around you can actually use them.

And once you get good at this, you’ll become the kind of dev people trust, listen to, and go to when things get messy.

---

Personal Updates

• 😰 It’s striking how common anxiety has become in our society. I was at the supermarket the other day and overheard someone talk about it as casually as if they had a simple headache.
• 🌿 I’m trying to incorporate mindfulness in my life to deal with anxiety. 10 min of meditation can do wonders.

---

"The single biggest problem in communication is the illusion that it has taken place." — George Bernard Shaw

---