The Most Missing Discipline in IT

How Typical IT Departments Get Stuck

Let’s talk about something that rarely gets named but shows up in subtle, systemic ways across nearly every IT department I’ve worked with: the absence of real product management discipline.

“IT”(AKA Tech Services, TechOps, etc.), and other similar service-oriented and operations departments, get the attention of executives especially during budget focused conversations. They are framed as a cost center. A necessary function. Something you want to run lean, automate, and ideally not think about too much. And to be fair, a lot of IT leaders inherit a situation where the unspoken goal is: “Keep the lights on, minimize spend, and don’t break anything.”

This attitude towards—and within—the IT department reinforces sub-optimal patterns of behavior:

• Roadmaps, if they are created at all, are used to ‘check a box’, rather than being a powerful tool for creating strategic alignment.
• Many conversations about outcomes turn into: “Can we survive and get by without spending the time and money to do all these system upgrades?”
• The user experience of end users is an afterthought—if it’s considered at all. Instead, the attitude towards users is one of: “They’ll use what we give ‘em.”
• It’s difficult to have conversations about our success metrics that aren’t uptime, cost avoidance, and ticket velocity.
• The long-term vision is lost, except in the hearts of the most passionate people.

If you’ve noticed one or more of these kinds of challenges in your org, consider this an invitation to rethink what’s possible—and maybe take a step toward a better future that you dare to believe in.

Let’s talk about what has been a hidden problem all along that may be creeping into your process and culture, causing many of the disfunctions mentioned above.

The Skills of a Good Product Manager are Absent

Product management, at its core, is about solving the right problems for the right users in the right way at the right time. It requires clarity of purpose, feedback loops with real users, cross-functional alignment, and a focus on measurable impact, not just efficiency of delivery.

Product managers in traditional product orgs would never say…

“We built and shipped the thing, so we’re done.”

They’d ask..

“Did it work?”

Not:

“Did we accomplish our goal?”

But, instead:

“Did we help our customers accomplish their goals?”

Product managers need to be disciplined and intentional about discovering where they were wrong. They’d go talk to users. They’d iterate. They’d adjust the roadmap. They’d throw out work if it wasn’t creating value.

And the results of all this disciplined thinking are…

• Products that people actually want to use
• Fewer wasted cycles on things that don’t matter
• Clearer priorities & fewer fire drills
• Teams stay focused & customers stay engaged
• And the business sees steady, compounding gains—because every release is moving the needle on something that matters.

IT departments could do that too. But first, we have to be willing to consider that the old ways of managing our IT business might be out of date. The approaches that worked for managers in the previous decades might be insufficient in the 2025 technology sector.

What It Looks Like in Practice

Imagine taking a skilled product manager (and I don’t mean a “project manager” rebranded) but someone who’s built and owned real user-facing products—and putting them in charge of an IT function. And now imagine telling them:

“You are now accountable for the success of this department.”

What do you see this person doing in your mind’s eye?

You can bet they wouldn’t start by just measuring tickets closed, or really anything to do with output.

They’d look for friction. They’d find out what users are really struggling with. They’d advocate. They’d iterate. They’d ruthlessly prioritize based on impact and value. And they’d probably uncover things no one in the org even realized were holding people back.

That is to say: They’d be immediately at work on outcomes.

Doing this work requires curiosity, stakeholder collaboration, persistence, and quite a bit of humility—because, when you actually bother to look, you might find that the solution you were so proud of doesn’t actually solve the problem you thought it did.

No Budget. No Headcount. No Problem.

“But product managers are expensive!”

I hear you! But you don’t need to hire a full-time PM to start moving in this direction.

A few simple shifts can go a long way.

Step 1: What Are We Even Doing Here?

The first and most important job is to think about the work you are doing from first principles. This means asking questions that nobody wants to ask because they sound so basic and fundamental as to seem unimportant or meaningless.

Some decent examples of first principle questions are:

• Why does this IT function exist?
• How does our work contribute to the company’s goals?
• If our internal users had a choice, would they choose to use what we provide?

Sometimes too, the answers to these questions can be awkward if it turns out we’re not really focused on the right things at the moment. If thinking about these things makes you feel tired and your brain hurt, that means you’re doing it right!

Step 2: How Do We Measure Success?

From there, the next move is to define what outcomes actually matter. And no, I don’t recommend just slapping some KPIs into a dashboard. You can of course ask ChatGPT for example metrics and it will probably give you something pretty reasonable.

But unless you can explain why these metrics matters to your teams in your specific context, no one’s going to trust it or rally around it.

If you’re willing to be a bit more thorough than simply “googling it”, we can use the first principle thinking mentioned earlier on creating our metrics.

I recommend thinking about this from one of two lenses. What follows are two free worksheets. Feel free to use and/or customize either of them.

Creating our Success Metrics From Lens #1: Accountability

Creating our Success Metrics From Lens #2: Winning the Game We’re Playing

These cascade of questions are intended to stimulate a brainstorm and a speculative conversation with you and your team. While it does take some mental effort, and requires intellectual honesty, by the time you’re dong going through one or both of these series of questions you should end up with a strong, outcome focused, Key Performance Indicator (KPI).Please feel free to use or customize these free worksheets.

This KPI can serve as a “North Star” which, if pursued, should lead your teams towards getting better at doing the things that matter, rather than just keeping themselves (and you) busy.

Step 3: Iterate, Learn, and Improve

If you manage to take some inspiration from the principles and practices of great product managers, you should start to view what you’re there to do in a new way. And I think you’ll find that it is a much more empowered and useful frame to attack the problems and opportunities that show up for a well oiled IT department.

• Use your roadmap as a communication tool, not just a schedule. Does it help stakeholders understand tradeoffs? Does it reflect what matters to the business?
• Talk to users before you roll something out. Ask: “What do you wish this system did that it doesn’t?”
• Define success in terms of outcomes, not just outputs. Instead of “we deployed the new tool,” say “onboarding time decreased by 30%.”
• Ask product questions. Who’s this for? What’s the real problem? How will we know it worked?

Let me be clear: this isn’t about layering on new ceremonies or frameworks. It’s about mindset. It’s about recognizing that internal systems and services are products. The stakeholders are employees. The outcomes matter. The experience matters. Adoption matters. And so does alignment with what the company is actually trying to achieve.

Many of the standard meetings, reports, and process that you will have set up right now are likely focused on outputs and predictability. While those are important aspects to a healthy IT department and can’t be ignored, setting up even one recurring conversation where you look with your team at the outcomes that are getting produced would be extremely powerful.

On top of that, maintaining a roadmap (a lightweight sketch of the future, not a high level plan with due dates already decided) can be a powerful tool to share with your partners and to have trade-off conversations about sequence and opportunity cost of doing certain projects now rather than later.

Create a Breakthrough and Share With Us!

IT doesn’t have to be just a cost center. It can be a driver of efficiency and a source of innovation. But only if we stop running it like a back office and start treating it like a product worth investing in.

What would it look like if your IT org shipped things people actually loved?