How PMs and Developers See Projects Differently (and Why Both Matter)

When our team delivered a mobile app redesign in just five months, it honestly felt like we'd pulled off something impossible. We had cross-platform mobile development, Salesforce integration, constantly evolving requirements, and a client who was (understandably) anxious to see their vision come to life. Looking back now, I realize the real achievement wasn't just hitting our deadline. It was learning how to make two completely different perspectives work together, even when they were pulling in opposite directions.

The PM Perspective: Managing Dependencies and Client Expectations

For project managers, complex projects become a mental map of interconnected pieces. This project involved tracking a dependency chain: a mobile developer builds initial functionality, passes it to a Salesforce developer for API creation, then back to the mobile developer for final integration. One person waiting means everyone is waiting.

‍

Project managers review Jira boards multiple times daily. With so many moving pieces, the constant questions are: Who's blocking who? What's at risk? What needs escalation? Two-week sprints require planning three or four sprints ahead of time to prevent developers from sitting idle.

‍

The client relationship adds another layer. Weekly sprint reviews and frequent check-ins provide visibility that catches issues early and keeps everyone aligned. Client pressure pushes everything forward, with the PM balancing what the client wants with what the team can and should deliver. As requirements emerge and designs evolve, the PM's job becomes adapting the plan while still hitting targets.

The Developer's Reality:

For developers, this project meant building a unified solution using Kotlin Multiplatform to share code between Android and iOS. The Salesforce API integration followed consistent patterns, which made a huge difference.

‍

Behind the scenes, the connection between the mobile app and Salesforce was powered by a structured, REST-based API framework. Each request from the mobile app flowed through versioned endpoints in Salesforce that handled the logic, data retrieval, and response formatting. The process was seamless, the mobile app sent a request, Salesforce processed it through clearly defined service layers, and the result was sent back in a consistent, easy-to-consume format. This consistency meant faster testing cycles, fewer integration issues, and a more reliable user experience for mobile users.

‍

By using a single, repeatable API pattern across the project, developers avoided reinventing solutions for each new feature. Every integration followed the same structure, organized folders for services, data objects, handlers, and helpers, which made the codebase predictable and easy to maintain. This disciplined approach allowed the team to scale development efficiently, build new endpoints quickly, and ensure long-term stability without sacrificing agility or quality.

Where Perspectives Collided: Lessons from the Retrospective

The team retrospective revealed important disconnects between how PMs and developers experienced the same project. Understanding these gaps is crucial for future success.

‍

Meeting fatigue vs. client engagement - For PMs, this visibility prevents disasters and maintains relationships. For developers, every meeting is context switching that breaks focus time needed for complex problem-solving.

‍

Scope management struggles - Every change requires evaluation, not just for the effort, but for which part it takes time away from. PMs must shield the team and the original plan.

‍

Pressure transmission - PMs need to absorb client stress, assess what's actually urgent, and translate it into calm, clear direction.

‍

Requirements and design gaps - As one person noted, "We estimated the project not knowing all the details, and that's the risk we took. It was good that we added buffer hours." The buffer saved the project, but better upfront requirements would have made it unnecessary.

What Actually Made It Work

Despite tensions between different perspectives, the team shipped a great product on time. The retrospective revealed why:

‍

Multiple people highlighted "great team cooperation and communication" and noted the team "felt like we were all in sync." When someone felt pressure, they said something. When scope crept, people pushed back. When adjustments were needed, they happened together.

‍

The buffer time in estimates was crucial, giving room to absorb changes, evolving designs, and unexpected complexity.  

‍

Kotlin Multiplatform meant one codebase for both Android and iOS, so changes and iterations didn't double the work. Salesforce API implementation following consistent patterns lets developers build on previous work rather than constantly reinventing solutions.

‍

The project succeeded because both perspectives existed, not despite it. Constant Jira monitoring caught blockers before they became disasters. Developers' focus on technical quality prevented shipping poor solutions. PM client communication kept requirements flowing. Developer pushback on scope prevented drowning in changes.

‍

The most successful projects aren’t built on identical viewpoints, they thrive on empathy and collaboration. When project managers understand technical realities and respect developers’ need for focus, and when developers appreciate client pressures and the bigger business picture, teams move from friction to synergy. That’s where great outcomes happen.

‍