PM-Dev Chronicle Part 1: Walking the Slippery Bridge
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.
"Product management is really the fusion between technology, what engineers do, and the business side of things."
– Marissa Mayer, Former Google Product Leader & Yahoo! CEO
The roads leading to the office bustled with street vendors enthusiastically engaging with their customers, offering fresh idlis and steaming cups of filter coffee. The aroma filled the air, blending with the early morning rush of Bengaluru.
Inside SynergyTech’s glass-walled office, however, the atmosphere was far from lively. The warmth of the sun streamed in through the windows, but inside the conference room, the mood was pensive. It was time for yet another roadmap review session—one of many that the product and engineering teams held regularly.
Deepti Sharma, the Product Manager, walked in with quiet confidence. She looked sleep-deprived, but that was nothing unusual. Everyone else in the room looked just as exhausted. Despite this, her energy remained high. She had an exciting feature lined up for discussion, something she believed would make their enterprise customers sit up and take notice.
“Real-time insights.” She announced as she took her seat, scanning the room. “That’s what they want. That’s what will set us apart. Imagine a dashboard where every metric updates instantly—live, with no delays, no batch processing. Real-time, as it should be.”
Before the inevitable technical skepticism could set in, Arjun Dubey, the system architect, leaned forward with a measured look.
“Deepti, before we talk about how to do this, have you validated why customers need real-time insights? Are they just asking for it because it sounds good, or is there a concrete business case?”
Deepti was prepared for this. She had spent the past few weeks talking to key customers, analyzing how they used the product, and understanding their pain points.
“Yes, I have,” she responded confidently. “Three of our largest enterprise clients have expressed frustration over delayed decision-making because they rely on batch-processed reports. One of them even built a workaround by exporting data and refreshing it manually every 30 minutes.”
A few heads nodded, showing interest.
“The biggest issue,” she continued, “is that operational teams are flying blind. They make decisions based on outdated data. One customer told me that by the time they catch an issue in supply chain tracking, it’s already too late to act. If they had real-time insights, they could intervene sooner, prevent losses, and improve efficiency.”
There was a pause. This wasn’t just a nice-to-have feature; it was tied to real business impact.
“Fair enough,” Arjun said, exchanging a glance with Raghav Bhat, the senior backend engineer. “Now let’s talk feasibility.”
That was the cue.
“Live updates,” Raghav said, leaning back in his chair. “From all integrated sources?”
“Yup.” Deepti nodded.
“And by ‘live,’ you mean?” Raghav probed further, his tone cautious.
“As soon as the data changes, the dashboard reflects it instantly. No lag.” Deepti’s confidence didn’t waver. She had expected this question.
Raghav exhaled sharply. “You say it like it’s achievable with the wave of a wand.”
“It’s not magic,” Deepti countered, folding her arms. “We have the technology to make this happen.”
Raghav leaned forward, elbows on the table. “Technology comes with limitations. Right now, our system processes data in batches. Event-driven architecture. That means we queue data, process it, and update in intervals. It works because if something fails, we retry in the next cycle without causing system-wide chaos.”
His voice turned firmer. “What you’re asking for is a synchronous system—where every time someone opens the dashboard, we fetch fresh data from multiple third-party sources. What happens when one of those APIs is slow? Or worse, when it goes down?”
Deepti hesitated. She wasn’t ignorant of tech, but she hadn’t fully considered failure scenarios—at least, not like this.
“Can’t we… somehow make the data exchange faster?” she asked.
A soft chuckle rippled through the room.
And then, from the corner, Arjun spoke up again, his voice patient and composed. “Deepti, you like food, don’t you?”
Deepti frowned. “I—what?”
“Restaurants,” Arjun clarified. “Right now, our system works like a fine-dining kitchen. Orders are placed, prepared, and served in sequence. Some dishes take longer, some shorter, but the process remains efficient. What you’re asking for is a live kitchen, where every customer stands at the counter, waiting while the chef prepares their meal instantly. Now imagine what happens when one order takes longer than expected.”
Deepti could picture it now—a growing queue, restless customers, one delayed order cascading into another, the entire kitchen slowing to a painful halt.
“Oh.” The realization hit her.
“Exactly.” Raghav leaned back again. “And that’s without even talking about rate limits. Some APIs won’t let us make more than a certain number of requests per minute. If we hit that limit? The feature dies.”
Silence filled the room. No one wanted to be the first to speak.
Finally, Deepti broke the quiet. “Okay, so what’s the alternative? Because customers still want something close to real-time.”
Arjun nodded approvingly. “Now that’s the right question.”
“We tweak the model,” Arjun suggested. “Instead of actual real-time, we reduce the batch processing window. Maybe every 10 minutes instead of every hour. That way, users get near real-time data without breaking the system.”
“And,” Raghav added, “we should talk to our integration partners. We need to figure out what their APIs can actually handle, so we don’t build something that collapses the moment we scale.”
Deepti exhaled, nodding. “I’ll reach out to them before we meet next.”
As the meeting wrapped up, Raghav and Arjun exchanged knowing glances.
“You think she’ll get it this time?” Raghav asked.
“She’s starting to,” Arjun replied.
The aroma of coffee lingered, a silent witness to the friction, learning, and quiet victories that shaped the team.
Deepti had walked into the meeting expecting a simple yes, but walked out with something far more valuable—a deeper understanding of trade-offs in technology. Being a product manager wasn’t just about pushing for features; it was about balancing customer needs with technical realities, understanding trade-offs, and working with engineers, not against them.
She had won trust by validating the business need, proving that real-time insights weren’t just a nice-to-have but a real problem worth solving. But she had also learned a hard truth—what customers want and what’s technically feasible don’t always align.
The engineers had done their part too—challenging assumptions, ensuring scalability, and guiding the conversation toward a practical solution. They weren’t roadblocks; they were protecting the product from breaking under its own weight.
This wasn’t about winning or losing—it was about finding common ground.
But the real question remains…
Would this chasm between product and engineering ever be bridged?
And more importantly… what would Deepti do next?
Find out in Part 2, publishing next.