If your data engineers spend 80% of their time on one-off pipelines and minor dashboard tweaks, your organization is hemorrhaging money. You are trapped on a treadmill of duplicate ingestion work and “projects” that never actually end. This is not just a technical bottleneck—it is a leadership failure in how work gets classified.
Every hour spent rebuilding a capability that should have been a platform is an hour of ROI evaporation. When you treat everything as a project, you are making a deliberate decision to increase your cost-per-feature across the organization. The result is not just brittle infrastructure; it is talent burnout as your best engineers tire of repeating the same low-leverage work.
To fix your funding, staffing, and technical debt, you must explicitly categorize every initiative as a Project, Product, or Platform. This framework is how you step off the treadmill and start building leverage.
Key Takeaways#
- Eliminate Project Overhang: Kill the eternal pseudo-product by enforcing strict end-state criteria and handoff protocols.
- Scale Engineering Impact: Use the 3+ Teams Rule to identify where platform investment creates outsized organizational leverage.
- Secure Sustained Funding: Stop scavenging from project leftovers and establish permanent budgets for long-lived assets.
- Reduce Technical Debt: Prevent the maintenance tax created by duplicate, unmanaged pipelines.
- Apply Product Thinking: Shift from shipping code to delivering user outcomes so internal tools actually see adoption.
- Communicate ROI with Precision: Use distinct success metrics for each work type to prove value to the C-suite.
The Work Type Trinity#
In a high-functioning data organization, not all work should be funded, staffed, or measured the same way. Misunderstanding these distinctions is one of the fastest ways to accumulate debt that later shows up as delivery drag, fragmentation, and avoidable cost.
- Project: Time-bound, delivery-focused work. It has a sponsor and an expiration date.
- Product: Ongoing, user-focused assets. It requires a roadmap, a Product Owner, and a feedback loop.
- Platform: Foundational, multi-consumer capabilities. It creates the leverage that allows product teams to move faster.
The Trinity Matrix#
| Feature | Project | Product | Platform |
|---|---|---|---|
| Time Horizon | Months (time-bound) | Rolling (ongoing) | Years (long-lived) |
| Primary User | Sponsor / stakeholder | Defined internal user group | Multiple product teams |
| Success Metric | On-time delivery | Adoption + satisfaction (NPS) | Adoption + leverage |
Migrating a legacy sales database to the warehouse is a Project. Building a self-service ingestion framework that allows 15 different teams to migrate their own data is a Platform.
The Practical Playbook: Classifying and Executing#
1. The Intake Classification Logic#
Stop defaulting to project status. Projects are cheaper upfront, but they are often the primary source of long-term debt because they ignore maintenance, ownership, and reuse.
Implementation Checklist#
- The Time Horizon Test: Will this work still matter in 24 months? If yes, it is likely a Product or Platform.
- The 3+ Teams Rule: If three or more teams need the same capability, classify it as a Platform immediately.
- The “Who Are the Users?” Test: If there is only one stakeholder, it is probably a Project. If there is a recurring user base, it is a Product.
- Define the Exit Criteria: If it is a project, what does “done” look like? Who accepts the handoff?
- Calculate the Leverage Proxy: Estimate the hours saved across the organization if this is built once as a platform instead of ten times as a project.
What good looks like: A team that rejects one-off requests if they violate the platform roadmap or lack a long-term owner.
Failure mode: Treating everything as a project. Mitigation: Force a Work Type designation on every Jira ticket or intake form.
2. Transforming Capabilities into Products#
Internal tools fail when they are built in a vacuum. Applying product thinking ensures your platform is not just a loose collection of scripts, but a usable asset that solves a recurring problem for a defined audience.
Implementation Checklist#
- Identify Target Personas: Who is the customer? For example, domain data engineers or marketing analysts.
- State the Problem: Define the specific pain point, such as “Ingestion takes two weeks of manual coding.”
- Specify Interfaces and SLAs: Define the contract. If the platform provides a table, what are the latency and uptime expectations?
- Enforce Non-Goals: Explicitly list what the product will not do to prevent scope creep.
- Execute Inner-Sourcing: Allow product teams to contribute pull requests to the platform so scale does not depend entirely on platform headcount.
- Recruit Champions: Partner with two early-adopter teams to validate the tool before a broader rollout.
What good looks like: High internal NPS and a platform that effectively sells itself through ease of use.
Failure mode: Product without feedback. Mitigation: Establish a monthly user steering committee.
3. The Sustainability and Funding Model#
Platforms degrade without sustaining investment. You cannot maintain multi-year infrastructure on the leftovers of quarterly project budgets.
Implementation Checklist#
- The 20% Capacity Rule: Dedicate 20% of every platform roadmap to maintenance, bug fixes, and deprecation. This is non-negotiable.
- Quantify the Platform Tax: Measure the friction of using the platform, including onboarding time, and work to minimize it.
- Shift FTEs to Permanent Funding: Move platform engineers out of project-based variable cost pools and into fixed headcount.
- Track Reuse: Document every instance where a shared capability prevented a new from-scratch build.
- Separate Sustaining from Growth: Distinguish clearly between budget for new features and budget to keep the lights on.
What good looks like: A platform team that continues improving core stability even when no major new projects are active.
Failure mode: Unfunded platform. Mitigation: Require a sustaining investment line item in every strategic initiative.
A Worked Example: The Finance Dashboard Transformation#
Context: Finance requests a monthly revenue dashboard.
The old way: Build a custom pipeline and dashboard as a one-off project.
Result: The engineer is stuck maintaining it forever. Marketing later asks for the same data and builds a second, conflicting pipeline.
The better way: Intentionally slow the initial delivery to build a platform metrics layer, then deliver the dashboard as a product on top of that layer.
The tradeoff is straightforward: spend more time upfront so every other team in the company can pull Revenue from a single source of truth. In this example, that means spending roughly 30% more initially in exchange for downstream reuse, consistency, and lower maintenance overhead.
Internal Contract: Revenue Data Product#
| Field | Specification |
|---|---|
| SLA | Data refreshed monthly; ≤1 hr latency for updates |
| Interface | Validated Parquet in Landing; documented dbt models |
| Ownership | Platform operates infrastructure; Finance domain owns configuration |
| Non-Goals | This product does not perform currency conversion or tax adjustments |
The Leadership Scoreboard#
Different work types need different success measures. If you use the same scoreboard for projects, products, and platforms, you will reward the wrong behavior.
| Metric | Why It Matters | Good Direction |
|---|---|---|
| On-time Delivery | Measures reliability for fixed-scope projects | Stable |
| Adoption Rate | Validates that your products and platforms are actually useful | Up |
| Reuse Leverage | Measures the hours saved by shared capabilities | Up |
| Onboarding Time | Measures the friction of your platform | Down |
| Platform Tax | Measures the overhead of using shared infrastructure | Down |
| Incident Rate | Measures platform stability and reliability | Down |
| Technical Debt | Measures the cost of duplicate work being built | Down |
| Maintenance Capacity | Ensures the 20% rule is being followed | Stable (20%) |
Leadership Language: The Executive Scripts#
To the VP/CFO: ROI and Leverage#
- “I classify our work as project, product, or platform—each requires a different funding model if we want to avoid wasting capital.”
- “Cutting the platform budget is a deliberate decision to increase our cost-per-feature across every team in the company.”
- “We are paying a duplicate-work tax because we have not funded the foundational metrics layer.”
- “I measure platform success by adoption and leverage; if teams are not using it, we are not getting the ROI.”
- “Maintenance is a non-negotiable 20% of our capacity; skipping it today guarantees a system failure next quarter.”
To the Engineering Team: Clarity and Ownership#
- “This dashboard is a product, not a project—we are building for ongoing feedback, not just a one-time handoff.”
- “If 3+ teams need this, we stop building pipelines and start building a platform capability.”
- “Inner-sourcing is how we scale; we will accept PRs from any team that needs a new feature in the ingestion framework.”
- “Product thinking means we care more about the user’s NPS than the lines of code shipped.”
- “We do not start a project until we define exactly how it ends and who owns it afterward.”
The Pushback Scripts#
- The “No” on Maintenance: “I can defer new platform features to hit this deadline, but maintenance is non-negotiable. If we skip it, we are choosing to accumulate debt that will slow us down 2x next month.”
- The “Project” Trap: “Calling this a project sets the wrong expectation. If it needs ongoing support and iteration, it is a product. Let’s align on the long-term headcount for it now.”
- The Cost of Inaction: “Last quarter, three teams built the same CDC logic. We wasted 400 engineering hours because we did not have a shared platform. I am moving 2 FTEs to fix this.”
Common Mistakes to Avoid#
- Treating Everything as a Project: Fix: Force explicit classification at intake to acknowledge long-term costs.
- Unfunded Platforms: Fix: Establish a permanent sustaining investment budget that is not tied to projects.
- Project Overhang: Fix: Define a clear definition of done and strict handoff or deprecation protocols.
- Building Platforms Without Users: Fix: Validate demand with the 3+ Teams Rule before writing a single line of code.
- Conflating Product and Platform: Fix: Remember that platforms enable (infrastructure and tools), while products deliver (data and dashboards).
- Ignoring Non-Goals: Fix: Explicitly state what a product will not do in the brief to prevent scope creep.
- Zero Leverage Tracking: Fix: If you cannot prove how many hours you saved other teams, your budget will be the first to go.
- Skipping Inner-Sourcing: Fix: Do not become a bottleneck; create a contribution guide so others can help themselves.
Closing and Next Steps#
Deliberate classification is the hallmark of a mature data organization. If you do not distinguish between these work types, you are not leading a platform team—you are managing a collection of soon-to-be-obsolete projects.
Weekly Action Plan#
- Audit: Review your top three current initiatives and classify them using the Trinity Matrix.
- Identify Mismatches: Find one “project” that is actually an unfunded product, and write a product brief for it today.
- The 20% Mandate: Update sprint planning so 20% of capacity is explicitly reserved for maintenance and debt reduction.
- Standardize Intake: Update your request form to include Work Type and Target Users.
As a final test, ask yourself this: Are you building foundational assets that multiply your team’s value, or are you just paying a platform tax on every new project you ship?
