PM-Dev Chronicle Part 2: From Friction to Flow
Exploring the Push and Pull Between Product and Engineering—And How to Build Synergies. A tale of ambition, friction, and the art of building together.
Incase you’ve missed Part 1 of PM-Dev Chronicle, you can read it here:
PM-Dev Chronicle Part 1: Walking the Slippery Bridge
Part Two
A week later, Deepthi walked into the meeting room again.
Same room. Same sleep-deprived faces. Same aroma of over-brewed coffee. It felt like déjà vu.
But something was different this time.
The last meeting had been a battle of perspectives—developers viewing feasibility, product trying to push vision. It wasn’t hostile, but it wasn’t productive either. This time, she wasn’t here to convince them. She was here to collaborate.
She had spent the past week listening, researching, and gathering facts. No wishful thinking. No vague assumptions. Just a practical path forward.
Deepthi settled into her chair and placed her laptop on the table. The subtle hum of keyboards slowed. Eyes flickered away from screens. Good. They were listening.
"Glad you all are here," she began, her tone lighter than last time. “I’ve been digging into this, and I want to propose something different. Instead of forcing real-time dashboard updates, how about ‘near’ real-time?”
She glanced at Arjun, the architect—the one who would be most critical.
A pause.
Then, one by one, heads lifted from screens.
"I spoke with some of our integration partners," she continued. "Turns out, some APIs can handle updates every 10 to 15 minutes. Others, just once an hour. Instead of forcing everything to be instant, what if we create a system that adapts dynamically?”
This time, no immediate resistance. No scoffs or dismissals. That was progress.
Arjun, now interested, leaned forward slightly.
“Interesting.”
It wasn’t a yes, but it also wasn’t a no.
Deepthi pressed on.
"For APIs that allow it," she continued, "we use webhooks instead of polling. That way, we get updates only when something changes, instead of hammering them with requests every second.”
Raghav, who had been silently absorbing the discussion, let out a low whistle.
“That actually makes sense,” he muttered.
Encouraged, Deepthi kept going.
“And for APIs that have stricter limits, we stagger the updates—some every few minutes, others less frequently. No unnecessary traffic, no overload. That way, we optimize responsiveness without burdening the system.”
This time, the silence wasn’t filled with tension. It was filled with thought.
Raghav tapped his fingers on the table. “I can work with that.”
Arjun rubbed his chin, his face no longer skeptical but contemplative.
“Not a bad suggestion. That’s actually… smart.”
Deepthi noticed something shift in the room. The discussion had turned from 'why it won’t work' to 'how we can make it work.'
That was the breakthrough.
She leaned back, giving them space to process.
“How about we meet in a couple of days after we discuss what design considerations need to be made?” Arjun suggested.
Deepthi nodded. "Sounds good. I'll schedule a time for us to meet."
The meeting wrapped up. But this time, something had changed.
She had walked in last time trying to convince them.
She walked out today having earned their trust.
Not by pushing harder.
Not by debating louder.
But by speaking the technical language.
She still couldn’t write a single line of code.
But now, she understood how to communicate in a way that mattered.
As Deepthi gathered her things, she overheard Raghav and Arjun chatting quietly.
“Honestly, I didn’t think she’d come back with something useful,” Raghav admitted.
Arjun smirked. “Yeah, I thought this was gonna be another ‘PM asks for the impossible’ meeting.”
“Same.” Raghav nodded. “But she actually listened. She didn’t push unrealistic stuff—she gave us something that works.”
Arjun tapped his pen against the table. “It’s rare. Most PMs just push business needs without thinking through constraints. This was different.”
Deepthi pretended not to hear, but inside, she smiled.
She had cracked the code.
It wasn’t about knowing how to build the solution.
It was about knowing how to have the right conversations about it.
Author’s Note:
A bridge isn’t built by one side alone.
It’s built when both sides move towards each other.
That’s how great products are made.
That’s how great teams work.
That’s how friction turns into flow.