Any project is essentially a negotiation between three roles — Customer, Contractor, Sponsor. Each has goals, biases, blind spots. Understanding these interests helps navigating conflicts early rather than firefight later.
Customer
A Customer has a problem and needs a solution. A Customer sets the goals, acceptance criteria.
👍 The Customer likes more features, better UX with smooth customer journey and edge cases covered.
🥱 Most but not all! Customers do not need/understand refactoring, technical aspects of the solution neither DORA/TDD or any other tech slang/abbreviation. Just make it work!
⚠️Domain expertise imbalance
It might occur that Customer and Contractor have severely different level of expertise on the Project. The more experienced party might omit some Product-related peculiarities because they seem to be obvious for them. Whilst their vis-à-vis never faced such aspects.
Some marginal examples
- An offline-only business decides to go online and approaches a well-known web-studio with 10+ years of e-commerce.
- Or a Contractor gets the problem in a peculiar non-well-known domain to solve (e.g., in bio-RnD or in gas/water/electricity delivery).
Traditionally, it’s up to Contractor’s manager to fill the expertise imbalance gap: the acceptance criteria (“What?”) and Product Goal (“Why?”) should be either well clarified or well explained. By any means, the manager should have clear vision and should be ready to communicate it in holistic way.
This works on both levels: “Customer ↔ PM” and “PM ↔ DevTeam”.
Contractor/Developer
Obviously, a Developer implements the solution. As a Developer literally performs the work, their interest is to do less work. Broadly speaking, it’s often not about working less but about working more convenient, more efficient, under less pressure and so on:
👍
- Brand-new project
- Well-structured solution
Industry best practices - Time & Material
Scope "breathing room"
💩
- Legacy
- Messy code
Ad-hoc patches - Fix-price & Scope
📌First conflict appears here:
The Developer cares about things outside of Customer’s zone of interest and expertise. It’s manager’s task to communicate these aspects well and reveal the vision/values of opposite side.
Let the Dev Team understand till which extent they can go tech-perfect.
Shed some light for Customer on how bad can purely maintained product turn in the future.
Sponsor
A Sponsor provides the resources (expecting profit in the future).
An "absolute Sponsor" cuts the budgets and disapproves any extra work to-be-done (including fixing technical debt) — unless properly convinced.
How can someone persuade a Sponsor? — By talking business numbers: either by showing the potential gain or by cutting the expenses. For instance,
- Buying more expensive storage package
→ Getting extra score points on IT Security Enquête
→ More compliant Product
→ Potential for new markets. - Invest 2 sprints in implementation of
X
→ Spend less time on regularY
→ SpareNtime for next year
Prerequisites: “current-vs-estimated” numbers are known;N≫ 2 sprints.
Be ready for some bargain here: the Sponsor might have strong cards as well. Even by losing the argument, there’s a benefit: more clarity on Product Vision.
Despite of it’s pretty radical to evaluate all in-project relation through such prism, this exercise shows how misaligned interests naturally create friction: the Customer wants outcomes, the Developer wants workable conditions, and the Sponsors calculates the ROI.
The manager’s job is to translate between these worlds, fill expertise gaps, and keep everyone aligned on the “What”, “Why” and “How” without letting any one perspective dominate.