Product management fundamentals don't change just because we're building for internal customers. Value is still value. Usability is still usability. But how we answer these questions in enterprise IT requires a different lens.
Having spent years building products for enterprise IT organizations as well as real product companies, I've learned that while Marty Cagan's four questions provide an excellent framework, the way we answer them needs to reflect the unique challenges of building for internal customers. Let me share what I've learned about applying this model within enterprise IT.
If you haven't read through Marty's post on svpg.com I suggest doing that before you read this post, and if you haven't read at least his first two books (Inspired & Empowered) you should consider that as well. Much of the framework I use for enterprise was inspired (puns aside) by what he does in true product companies, with modifications made for enterprise without needing to go all the way to adopting a needlessly complicated framework.
Value: Will They Use It?
In enterprise IT, value is about whether people will actually use what you build. This seems simpler than external products, but it's deceptively complex.
Your monitoring tool might be mandated by leadership, but if your SRE teams find ways around it because it doesn't meet their needs, you've failed the value test. I've seen entire security solutions become shelfware because teams created shadow IT solutions that actually solved their problems.
Here's what value really means in enterprise IT.
First, understand that your users have choices, even when they technically don't. They can:
- Create manual workarounds
- Build their own solutions
- Use shadow IT tools
- Simply not use the tool effectively
Second, value in enterprise IT often comes from:
- Time saved in daily operations
- Reduced cognitive load
- Better data for decision making
- Improved collaboration between teams
- Reduced context switching
Usability: Can They Figure It Out?
In enterprise IT, usability has unique challenges. Your users are technically sophisticated but often time-constrained and interrupt-driven. They're not going to spend hours learning your tool unless it provides overwhelming value.
I learned this lesson building a deployment platform. We had all the features teams needed, but they kept using their existing manual processes. Why? Because our platform required them to learn a new workflow when they were already struggling to keep up with incidents and feature demands.
Consider these enterprise IT usability factors.
Authentication and access:
- Does it work seamlessly with SSO?
- Are the right roles and permissions easy to manage?
- Can users quickly get to what they need?
Integration points:
- Does it work with existing tools and workflows?
- Can it be accessed from where users already work?
- Does it reduce context switching?
Learning curve:
- Can users get value in their first interaction?
- Does it match existing mental models?
- Are advanced features discoverable without being overwhelming?
Feasibility: Can We Build It?
Feasibility in enterprise IT is about sustainable operation. Your team needs to build and maintain this solution while also supporting existing systems.
I've seen teams get excited about rebuilding monitoring systems using the latest open source tools, only to realize they don't have the expertise to maintain them long-term. Or try to create custom security tools without considering the ongoing burden of keeping up with evolving threats.
Key feasibility considerations for enterprise IT:
Technical sustainability:
- Do we have the skills to maintain this long-term?
- Can we support it with our current team structure?
- Does it align with our technology strategy?
Operational reality:
- Can we meet required SLAs?
- Do we have the monitoring and alerting capability needed?
- Can we troubleshoot issues effectively?
Integration complexity:
- How does this impact our existing systems?
- What are the security implications?
- What are the performance impacts on other services?
Viability: Should We Build It?
Viability in enterprise IT is about organizational alignment and long-term sustainability. Will this solution still make sense in two years? Does it align with our technology strategy? Can we maintain it with our expected resources?
The hardest lesson I've learned is that just because we can build something doesn't mean we should. Sometimes the best product decision is to help teams better use existing tools rather than building new ones.
Consider these viability factors:
Strategic alignment:
- Does this align with our technical strategy?
- Does it support our organizational priorities?
- Will it still make sense as we evolve?
Resource reality:
- Can we sustain the ongoing maintenance?
- Do we have budget for required infrastructure?
- Can we support the necessary training and documentation?
Organizational impact:
- How does this affect other teams and processes?
- What changes will be required in how teams work?
- What existing systems or processes can we retire?
Putting It All Together
The four questions framework works in enterprise IT, but we need to adapt how we answer them. Here's what I've learned:
- Start with value, but define it in terms of actual user behavior, not theoretical benefits.
- Consider usability in the context of interrupted, busy technical users.
- Evaluate feasibility based on long-term maintenance, not just initial building.
- Assess viability through the lens of organizational sustainability.
Remember: in enterprise IT, you're creating a solution that your colleagues will depend on every day. Get it wrong, and you're making your colleagues' lives harder.
That's why these four questions matter even more in enterprise IT. They help us build solutions that don't just work technically, but work within the complex reality of our organizations.
This framework builds on Marty Cagan's four questions of product, which you can read more about at SVPG.com. I've adapted it based on my experience applying it specifically in enterprise IT environments.