Digital Product Management: When IT Projects Become Products

For most of the history of enterprise IT, the mental model was construction. You had requirements. You scoped a project. You had a timeline and a budget and a deliverable. When you hit the go-live date and the system was live, the project was done. The team dispersed. The system went to maintenance, which was a different budget category, handled by a different team, measured on uptime and defect resolution, not on whether users were getting value.

This mental model worked reasonably well for a world where technology changed slowly, where you built a system and expected to run it for ten years, and where the main risk was the implementation itself. It works poorly for a world where user expectations change quarterly, where competitive software ships new features weekly, and where the question is not "did we build what we specified" but "are users getting value and are they still getting it six months after launch."

The shift from "IT project" to "digital product" is a response to that mismatch. A product is not a deliverable. It has users. It evolves based on feedback. It never really finishes because user needs, competitive context, and technical constraints keep changing. The product manager role, which owns the vision, the prioritization, and the user experience of a product and translates between user needs and engineering capability, is a function that barely existed in most IT departments ten years ago and is now essentially mandatory in organizations that have moved past "IT as a cost center."

The conceptual foundation for this shift draws on a few overlapping ideas. Lean Startup thinking, which Eric Ries popularized but which has roots in lean manufacturing and hypothesis-driven development, pushed the idea that you should build the minimum viable thing needed to test an assumption, learn from real user behavior, and iterate. Agile software development, in its many variants, moved teams from long planning cycles to short delivery cycles and from detailed upfront specifications to ongoing adaptation. These ideas combined into what is now broadly called "product-led development": let user behavior and outcomes drive prioritization, ship frequently, measure what changes, and adjust continuously.

OKRs, Objectives and Key Results, are the management layer that is supposed to align this approach to organizational strategy. The distinction they enforce matters: a feature shipped (output) is not the same as a user problem solved (outcome). An IT team that shipped fifteen features last quarter accomplished something. The question of whether those features improved any user metric is separate, and it is the question that product-led organizations are supposed to ask first. OKRs create a structure for connecting the work to the outcomes it is meant to produce, which forces teams to be explicit about the mechanism between "we built this" and "users benefited."

Gartner has tracked the product management function in enterprise IT and has noted the shift from project-based to product-based IT delivery as a key organizational maturity indicator. According to Gartner's newsroom, organizations at higher digital maturity levels are significantly more likely to have dedicated product managers for internal platforms and customer-facing digital products, and to measure IT success by business outcomes rather than project delivery metrics.

The internal product problem is where I think things get genuinely interesting and underexplored. When consumer product teams ship poorly, users leave. The market signal is clear and immediate. The engineering team can watch the abandonment metrics and connect them back to specific releases. This feedback loop is brutal but functional. It forces alignment between what gets built and what users actually need, because the cost of misalignment shows up quickly in churn.

Internal enterprise tools have captive users. When the HR system is mandatory, nobody can vote with their feet. The feedback loop that market pressure provides naturally has to be artificially constructed. Product managers for internal platforms have to create proxy signals: usage analytics to see which features are actually being used and which are being worked around, NPS surveys to measure whether users feel the product is improving, user interviews to understand where the friction is. None of these are as clean as churn. Users of mandatory systems will tell you they like the tool better than they actually do, because criticizing the tool that your employer gave you carries social risk. Workarounds happen silently and do not show up in usage logs unless you are specifically looking for them.

There is a related problem with prioritization. Consumer product teams can run A/B tests because they have traffic volume. Internal tools often do not. The team building the internal analytics platform does not have enough users to detect a statistically meaningful difference between two versions of the dashboard layout. They have to make prioritization decisions on qualitative feedback and intuition, which is harder to defend in budget conversations and easier to override when a senior stakeholder has a strong opinion about what should be built next.

The version of "product management" that survives contact with real enterprise IT organizations is usually somewhat messier than the startup version. It involves more stakeholder management, more negotiation with IT governance processes, more documentation requirements, and more constraints on what can be changed and how fast. The principles are the same: focus on outcomes, ship frequently, learn from users, adjust. The practice has to accommodate a more complex organizational environment than the clean version of the framework assumes.

I am not pessimistic about this. I think the shift in mental model matters even when the practice is imperfect. An IT team that asks "what outcome did this feature produce" is in a better position than one that asks only "did we ship on time," even if they cannot always measure the outcome precisely. The discipline of the question matters more than the cleanliness of the answer.