In partnership with
Hey friends 👋
Wednesday, 2:47 PM. Sprint planning meeting. A bunch of the team on Zoom. My engineering lead is talking about "latency issues with the batch processing job" and everyone is nodding like this makes perfect sense.
I am doing mental math to figure out if I can turn off my camera and Google "what is batch processing" without anyone noticing.
This is the stuff nobody posts on LinkedIn.
When it all clicks.
Why does business news feel like it’s written for people who already get it?
Morning Brew changes that.
It’s a free newsletter that breaks down what’s going on in business, finance, and tech — clearly, quickly, and with enough personality to keep things interesting. The result? You don’t just skim headlines. You actually understand what’s going on.
Try it yourself and join over 4 million professionals reading daily.
The moment
Shortly after joining the BE platform team , I got invited to a technical architecture review. It sounded important. I showed up.
Twenty minutes in, I realized I understood maybe 15% of the words being said.
"If we denormalize the schema, we can avoid the join overhead, but we'll need to manage data consistency manually."
Cool. Cool cool cool.
I nodded. I took notes that made no sense. I wrote down "denormalize???" with three question marks because that felt productive.
At the end, someone asked, "Stef, any concerns from a product perspective?"
And I said, I actually said this, "No concerns. This all sounds... solid."
Solid. The word you use when you have absolutely no idea what just happened but need to sound like you followed along.
🧠 Pro tip: Every PM has done this. The difference between junior and senior PMs isn't that senior PMs never get lost in technical conversations. It's that they've learned to flag it in the moment instead of nodding and hoping nobody asks them a follow-up question.
Here's what I didn't know then
That meeting - Half the people in it didn't fully understand either.
The senior engineer who explained everything so confidently? She told me later, "I was kind of winging it. We'll figure out the consistency thing when we get there."
Another PM who'd been there three years? He pulled me aside after and said, "I still Google 'denormalize' every time someone says it. I can never remember if it's the one with more tables or fewer tables."
Everyone is pretending more than you think.
Related read: I asked three senior PMs at HubSpot about their most embarrassing "I had no idea what was happening" moments. All three had stories from within the last six months. One had been a PM for eight years. Technical complexity doesn't stop being confusing just because you have more experience.
What actually helps
I used to think I needed to become technical enough that nobody would ever doubt me again. So I took database courses. I learned SQL. I read engineering blogs.
That stuff helped. But you know what helped more?
Admitting when I didn't understand something.
Not in a "wow I'm so bad at this" way. In a "hey, I'm not familiar with that approach - can you walk me through the tradeoff?" way.
Turns out, engineers don't mind explaining things. What they mind is when you pretend to understand and then make product decisions based on... vibes.
Now when I'm lost in a technical conversation, I do this:
Flag it in the moment: "Hold on, I want to make sure I'm following. When you say 'batch processing,' what does that mean for how users experience this feature?"
Ask for the tradeoff: "What's the thing we're optimizing for here, and what are we giving up?"
Restate in product language: "So if I'm hearing this right, we're prioritizing speed over accuracy in the short term, and we'll fix accuracy issues manually if they come up?"
Half the time, restating it like that helps the engineers realize they haven't fully thought through the tradeoff yet.
🔧 Try this: Next time you're completely lost in a technical conversation, write down one word you don't understand. After the meeting, don't Google the definition - ask the engineer "Hey, can you explain what you meant by [term] in terms of how it affects the user?" You'll learn the technical thing and build trust by showing you care about connecting it to product outcomes.
The thing I wish someone had told me
You're not supposed to know everything.
That sounds obvious. But I genuinely thought other PMs just... knew stuff. Like they'd absorbed it through osmosis or had some secret technical background I was missing.
Turns out, most PMs are learning on the job. The good ones just ask better questions.
The engineer who seems annoyed when you ask basic questions? They're usually annoyed about something else (probably the system, not you).
The PM who always has the perfect technical answer? They probably Googled it five minutes before the meeting (or they're making it up and hoping nobody asks follow-up questions).
Your job isn't to be the smartest technical person in the room. It's to ask the questions that connect the technical decisions to the customer problems.
☀ Quick reflection: Think about the last technical conversation where you felt lost. What was the actual product question you needed answered? (Like: "Will this slow down the user experience?" or "Does this create technical debt we'll regret later?") That's the question you should've asked - not the technical implementation details.
Clear financial writing, faster
Turn spoken explanations into accurate, formatted financial copy for reports and investor comms. Wispr Flow saves editing time and keeps messaging consistent. Try Wispr Flow for finance.
The unexpected benefit of admitting you don't know
Weeks after that terrible architecture review, I was in another technical planning meeting. An engineer proposed a complex caching solution.
I asked: "Can you help me understand what problem this solves for users? I want to make sure I'm connecting the technical work to the experience improvement."
The engineer paused. Then said: "Honestly, It doesn't really solve a user problem. It just makes the system cleaner on the backend."
We didn't build it. We prioritized something else that did improve the user experience.
That conversation only happened because I'd built a reputation for asking honest questions instead of pretending I understood.
If I'd nodded along (like I did in that first meeting), we might've spent three weeks building something nobody needed.
🧠 Pro tip: Engineers actually respect PMs who ask "why does this matter to users?" more than PMs who try to sound technical. Your job is to be the voice of the customer, not to be a worse engineer than the actual engineers on your team.
Try this today
Next time you're in a meeting and someone says something you don't understand, try this:
Instead of nodding and Googling later, say: "I want to make sure I understand, how does that decision affect [the user/the timeline/the tradeoff we're making]?"
You're not saying "I don't know what that word means." You're saying "I want to understand the impact."
Most of the time, you'll learn the technical thing and force everyone to think about whether the technical decision actually makes sense.
Still figuring this out, one confusing meeting at a time.
See you next week,
Stef
P.S. The batch processing thing? I eventually learned what it means. And then immediately forgot again. It's fine. The feature still shipped.