In a meeting room, a developer says: “That’s difficult due to the structure.” Or “There’s a security issue.”

After about three years in product management, you start feeling a subtle tension whenever you hear this. Is it genuinely technically impossible, or is there another reason? You hesitate to ask, worried you’ll be labeled as “PM who doesn’t understand tech.”

This guide is for those moments. It breaks down how to uncover the real reasons behind “it’s technically difficult” when talking with developers.

Why PMs Feel Intimidated by Technical Terms

API, permission systems, caching, WebSocket. When these terms flood a meeting, PMs without technical backgrounds naturally pause. “Will I be dismissed if I say I don’t understand?” The anxiety creeps in.

But the problem isn’t lack of understanding. It’s difference in context.

Developers talk about “implementation complexity,” while PMs ask about “the result users will experience.” They use the same words but have conversations at different levels.

Let me share an example from when I was planning an app.

PM (me): “Can we make order notifications real-time?” Developer: “Maintaining WebSocket connections causes heavy server load, and there are background constraints on mobile…”

I wanted to discuss UX—getting notifications within 5 seconds of an order. The developer was explaining the technical difficulty of real-time communication protocols. We were talking about different things.

5 Real Meanings Behind “It’s Technically Difficult”

When developers say something is “difficult,” they usually mean one of these:

1. It’s Genuinely Technically Impossible

This is the rarest case. Something physically cannot be implemented with the current tech stack.

Questions to Ask:

• “Is it impossible in our service, or does the technology itself not exist?”
• “Are there examples of other services implementing something similar?”

These questions help distinguish between genuine impossibility and constraints specific to your environment.

2. The Structure Needs Overhaul (High Development Cost)

This is the most common case. The real meaning behind “it’s not possible due to structure.”

Here, ‘structure’ typically refers to:

• Database design (table structure, relationships)
• API design (how data is exchanged)
• Permission system (who can do what)
• Screen flow (user navigation paths)

Questions to Ask:

• “Why doesn’t it work with the current structure? (Just briefly)”
• “How long would it take to change the structure?”
• “Is there an alternative way to achieve similar results without changing the structure?”

The third question is key. Often there’s a workaround that delivers 80% satisfaction even if not exactly the same.

3. Security/Policy Review Needed

When you hear “security issue,” PMs panic. Did I request something dangerous?

But in reality, it’s:

• Actual security risk (personal data exposure, permission bypass, etc.)
• Undefined policy (requires legal/compliance review)
• Developer’s defensive expression (“just in case”)

These three are often mixed together.

Questions to Ask:

• “What security problems are anticipated?”
• “Does this need legal team review?”
• “How do other services handle this?”

The third question is particularly useful. If competitors already implemented it, it’s not impossible from a security standpoint.

4. Performance Issues Expected

Statements like “this will make it slow” or “it’ll increase server load.”

The key here is quantifying how much slower.

Questions to Ask:

• “Will users noticeably feel the slowdown?”
• “At what traffic level does it become a problem?”
• “Can we test with a small number of users first and then decide?”

Often, “it might get slow” is just a possibility that can’t be confirmed until actual measurement.

5. Priorities Don’t Align (Honestly, Don’t Want To Do It)

This isn’t a technical issue but a communication issue.

The developer said “difficult,” but actually:

• There are other urgent tasks
• They’re not convinced of this feature’s value
• They’re exhausted from constantly changing requirements

Continuing technical discussion won’t help here.

Questions to Ask:

• “Can I explain again why this feature is important at this time?”
• “Do we need to coordinate priorities with other work?”
• “Can we separate must-haves from nice-to-haves in the requirements?”

Priority issues are best coordinated with PM or lead-level colleagues.

Expressions to Avoid When Asking

“Can’t we just do it simply?”

From a developer’s perspective, this sounds like “you’re making things complicated.” Instead, try:

“What’s the most complex part of this feature? Could we postpone just that part and do the rest first?”

“But other services do it”

Mentioning competitors is tricky since you don’t know their tech stack, team size, or development timeline. Instead:

“I saw a similar feature on ○○ service. Is there anything we can reference?”

“I don’t understand—explain it simply”

The word “simply” can sometimes sound rude. Try this instead:

“I don’t have a technical background, so could you break down the ○○ part a bit more for me?”

The Goal of Conversation Is ‘Agreement,’ Not ‘Understanding’

PMs don’t need to perfectly understand every technical term. What matters is finding a point of agreement.

You don’t need to know “exactly what WebSocket is” if you can conclude that “polling at 5-10 second intervals instead of real-time won’t significantly impact user experience.”

This table shows key questions you can ask immediately when you hear technical terms:

What Developer Said	Question to Ask Immediately
“It’s not possible due to structure”	Is there a way to achieve similar results without changing the structure?
“There’s a security issue”	What specific risks exist? How do other services handle this?
“Performance problems will occur”	Will users notice? At what traffic level does it become an issue?
“API integration is complex”	Which part is most complex? Can we proceed in stages?
“The tech stack doesn’t support it”	If changing the tech stack isn’t realistic, what alternatives exist with our current stack?

Collaboration Starts with ‘Respect’

Finally, one thing PMs should remember.

Developers didn’t become developers to say “no.” Most want to build great products. They just see things from a different angle than PMs.

“Not knowing tech” isn’t a weakness—the real skill is “the ability to collaborate with people who have different perspectives.” PMs who ask good questions create good outcomes.

---

Closing

In conversations with developers, the most important thing isn’t memorizing terms but the attitude of finding the real problem together. Behind “it’s technically difficult” lie various reasons: structure, priorities, performance, policy. I hope the questions outlined in this guide help two roles speaking different languages move toward the same goal.