Reading The Universe

I started my project management career delivering service improvements. Those projects focus on process improvement, data analytics, and the implementation of a new technology. The last several years have been different, I have delivered PRODUCTS. The nature of those have been applications developed on a platform (e.g. SAP, Salesforce, Palantir Foundry). I wrote an article discussing the complimentary nature of project and product management. In this article, I’m going to share the tension between the two.

Every IT project I’ve worked on, since 2020, has carried two parallel stories. One is the story IT tells itself: the project management lifecycle. The other is the story our business stakeholders live: the product lifecycle.

The first story, the IT story, revolves around scope, schedules, risk registers, and milestones. It’s framed by the PMI/PMP construct that most IT departments lean on. The second story, the business story, is about outcomes. Business stakeholders don’t care about Gantt charts or earned value management—they want a product that solves a problem.

When those two stories don’t align—and they rarely do—it creates friction. Requirements become a battlefield. Timelines turn into negotiations. Steering committees devolve into debates over what “done” really means.

I’ve lived this tension repeatedly. My role has been to manage projects that deliver products, like Palantir Foundry applications, to internal customers. On paper, these are IT projects. In reality, they are business products. That difference is more than semantic. It fundamentally changes how requirements are defined, how success is measured, and how conflict unfolds.

This post is about that conflict—why it exists, how it shows up, and what I’ve learned about navigating it. My thesis is simple: the business’s vantage point wins. IT is a supporting function. We exist to serve the customer, and the customer is the business. If we forget that, we end up delivering projects that succeed on paper and fail in reality.

Two Lifecycles, Two Worldviews

To understand the friction, you have to understand the worldviews.

The Project Management Lifecycle

The PMI/PMP lifecycle is inward-facing. It is about execution discipline. The phases—initiation, planning, execution, monitoring, and closure—are designed to bring order to chaos. They help IT teams ensure deliverables are built on time and within budget.

This worldview is dominated by artifacts: project charters, work breakdown structures, schedules, risk logs. Success is defined by adherence to plan. If the schedule was followed and scope was controlled, the project is “successful.”

The Product Management Lifecycle

The product lifecycle is outward-facing. It begins with discovery—what problem are we solving?—and continues through delivery, adoption, growth, and eventual retirement.

This worldview is not about artifacts. It’s about outcomes. Did we solve the problem? Did users adopt the tool? Did it create measurable business value? A product is not “done” until it delivers results.

The Clash

Now put these two worldviews in the same room. IT says, “We’ve closed the project successfully.” The business says, “We don’t care if you’ve closed the project—we still can’t approve purchase orders any faster.”

That’s the crux: project closure is not the same as product success. For IT, the finish line is project closure. For the business, the finish line is value realization. These finish lines are not aligned in time or in perspective.

Example: Palantir Foundry Application

Take a Foundry app built for supply chain analysis. IT views the “go-live” as the culmination of the project lifecycle. Requirements were gathered, code was written, testing was complete, and the system was deployed. The project was closed.

But for procurement managers, the app was only a success if it reduced approval times and revealed inventory savings. Until those outcomes materialized, the project was not successful in their eyes.

This divergence creates the gap where frustration lives. IT points to process compliance. Business points to unmet needs. Both are right in their own worldviews. But only one worldview matters—the business’s.

Why Strife Emerges in Requirements

The most visible fault line between these worldviews is requirements gathering.

The Project Approach

In project management, requirements are meant to be exhaustive and frozen. They are gathered up front, documented, reviewed, and signed off. Scope creep is treated as the enemy. Deviations are managed through formal change control.

This approach makes sense for projects like building bridges. Bridges don’t need new features after they’re built. But IT solutions are not bridges. They are living systems used by humans in dynamic contexts.

The Product Approach

In product management, requirements are fluid. They evolve as discovery continues. They are captured as user stories and hypotheses. Features are prioritized based on business value, not simply because they were documented months ago.

Flexibility is not failure—it is responsiveness.

Where the Two Collide

When IT applies rigid project methodologies to dynamic business problems, friction is inevitable. Stakeholders don’t think in terms of “requirements.” They think in terms of outcomes:

• “Can I reduce the time it takes to approve purchase orders?”
• “Can I see inventory across all regions in real time?”
• “Can I trust the data when making million-dollar decisions?”

These are product outcomes, not project requirements. They are high-level, qualitative, and outcome-driven. Translating them into system specifications is IT’s job—but when IT treats the translation as final and immutable, the business feels ignored.

The Illusion of Alignment

This mismatch creates the illusion of alignment. In a kickoff meeting, IT documents requirements. The business signs off. Everyone nods. Months later, IT delivers a system that meets the documented requirements but fails to deliver the outcomes.

IT says: “We built what you asked for.”
Business says: “But it’s not what we needed.”

This is why steering committees often implode near project closeout. IT is celebrating success while business stakeholders are bracing for disappointment.

Personal Anecdote

I once managed a project where the requirements were clear: deliver a data integration pipeline with daily refreshes. The project team delivered exactly that. But the business expected near-real-time updates for operational decision-making. Daily refreshes were technically “requirements met,” but practically useless.

The project succeeded. The product failed. The requirements process had created a false sense of clarity.

Why the Customer’s Vantage Point Wins

Here’s the blunt truth: the business is the customer. IT is the service provider.

It does not matter how elegant the project plan was. It does not matter how well risks were mitigated. If the product does not solve the business problem, IT has failed.

The Power Dynamic

Budgets, headcount, and strategic influence flow to the functions that create business value. IT can deliver perfect projects forever and still lose relevance if the outcomes don’t matter to the business.

The customer’s vantage point wins because the business funds IT. IT is a cost center. And like any cost center, it survives by demonstrating value to the revenue-generating parts of the enterprise.

Three Shifts IT Must Make

1. Translate project milestones into business outcomes.
   Don’t just report that the “requirements phase is complete.” Report that “we now know exactly how procurement managers will cut approval times.” Translate technical progress into business value.
2. Adopt product thinking inside project frameworks.
   Even when working within PMI’s structure, IT can adopt product-centric practices—like framing deliverables as features, prioritizing based on outcomes, and allowing iteration.
3. Stay after the project ends.
   Closing the project is not the end of the story. Products live on. IT must create mechanisms for ongoing support, iteration, and measurement. Otherwise, the value story ends prematurely.

Example: Data Quality

On one project, IT declared success because the data warehouse was deployed and stable. But the business rejected it because data quality was low. The project team moved on; the product team had to clean up the mess.

This taught me a lesson: data pipelines are not judged by their technical completion—they are judged by whether decision-makers trust the numbers. That trust is not created at project closure. It is created by ongoing product stewardship.

Bridging the Divide: Practical Lessons

So how do we bridge this gap? How do IT project managers survive in a world where business outcomes dominate?

Speak the Language of Outcomes

Stop reporting in project metrics. Start reporting in business metrics. Instead of saying, “The integration is complete,” say, “Business users can now access inventory data in one place, reducing manual reconciliation.”

Bake Iteration into Rigid Frameworks

Even in a waterfall-heavy enterprise, there is room for iteration. Break large deliverables into smaller increments. Get feedback early and often. Treat requirements documents as living guides, not contracts written in stone.

Manage Expectations Up Front

Be explicit at kickoff: there are two lifecycles in play. Clarify which milestones are IT-driven and which are business-driven. Set expectations that project closure is not the same as product adoption.

Align Incentives

Tie IT success metrics to business outcomes. If the business cares about reducing cycle time by 20%, then IT should measure and report against that metric.

Build Long-Term Product Ownership

Even if IT cannot formally own the product, create structures that mimic product ownership. Establish a feedback loop, track adoption, and measure value delivered over time.

Conclusion

The collision between project management and product management is structural. Enterprises will always need PMI-style rigor to keep IT delivery on track. Businesses will always demand products that deliver outcomes.

The conflict arises when IT confuses its story for the business’s story. Project closure does not equal product success.

The way forward is simple but not easy: remember that the customer’s vantage point wins. IT is a supporting function. Its value is not in delivering projects—it is in enabling outcomes.

So the next time you’re asked to manage a project that delivers a product, remember the dual narratives at play. Use project management discipline, but anchor yourself in product outcomes. Translate technical milestones into business value. Stay engaged after the project closes.

If you do that, you won’t just deliver projects. You’ll deliver products that matter. And that’s the only finish line that counts.

---

If you’re navigating the friction between project and product management in your own organization, I can help. I’ve spent the last two decades managing large-scale IT programs, delivering data products, and bridging the exact divide described in this article.

If your team is struggling to align project discipline with product outcomes, reach out. Let’s discuss how I can support you through consulting or targeted engagements.

Connect with me on LinkedIn to start the conversation.