Case Study: UX for enterprise data management platform
A case study in building institutional change from the inside — without a mandate, without a team, and without precedent.
Context
Company stage
Large, established enterprise with a newer, still-establishing product initiative within it.
Industry
Enterprise data management & developer tooling.
Product type
Developer edition of an enterprise-grade database management system — a technically complex, non-GUI product serving a broad range of developer personas.
What was at stake
I was brought into a 0-to-1 product build with no UX infrastructure, no research practice, and no institutional belief that UX applied to products like this, while competitors were quietly beginning to pull ahead.
The Problem
The prevailing belief was that UX was a GUI concern, something for web apps and dashboards, not database engines, CLI tools, and developer consoles. In a legacy enterprise environment still running on early-90s product practices, this wasn't a fringe view. It was the default.
The risk wasn't visible yet, but it was real. Competitors were beginning to incorporate developer experience thinking into their data products. Without a similar shift, the platform risked stagnation at precisely the moment the market was accelerating.
The Constraints
Organizational: No UX or research function existed. No precedent, no process, no framework, and no institutional mandate to build one. Leadership skepticism had to be converted before any resources could be unlocked.
Resource: Without backing, all research had to be self-executed. Test design, session facilitation, synthesis, reporting - all running in parallel with active ownership of a 0→1 product build.
Political: Getting other product teams to invest time in UX for their non-GUI products, after it had never been expected, was a separate and ongoing challenge beyond the initial leadership pitch.
Time: No formal deadline, but a self-imposed urgency driven by clear market signals. Competitors were moving. The window to get ahead of the curve was finite.
How I evaluated options
Option C was never a genuine consideration. The real decision was between A and B, and it came down to one question: what actually moves skeptical leadership in a legacy enterprise org?
The answer was evidence, not argument. A well-reasoned pitch without data would be dismissed. A working proof of concept with results attached was harder to ignore. Option B carried more personal cost but a significantly higher probability of changing anything.
My Verdict
Option B.
I ran a structured research practice on my own product - building the tools, running the sessions, synthesizing findings, and translating them into product decisions. The results became the foundation for a leadership pitch that secured formal funding. From there, the practice scaled first across my immediate team, then to roughly half the wider org.
Why I chose this
Institutional change in a legacy org doesn't move on ideas alone, it moves on demonstrated outcomes. Building the POC first was the only path that gave the advocacy real weight.
What I intentionally didn't do
Wait for permission before starting. Waiting would have meant either no start at all, or a delayed start that ceded more ground to competitors.
Risks I accepted
Running full product ownership and a solo research initiative simultaneously was demanding. I accepted that personal cost as the necessary price of building something credible enough to survive scrutiny.
Decision & Rationale
Outcome
What changed
A UX research practice built from scratch - frameworks, tooling, standards, and best practices designed to be replicable. Several milestone product moments shipped, including first cloud infrastructure partnerships, container-based deployment, and expanded support for new developer personas and tooling integrations.
What moved forward
Product adoption grew 2x year-over-year across the full developer lifecycle. Approximately half the wider org adopted the research practice. The initiative demonstrated that UX applied meaningfully to non-GUI, technically complex products, a genuine mindset shift in an org where that belief hadn't previously existed.
What I'd do differently
Build collaboratively from the start rather than alone. My sequence was: build, then convince. A better sequence is: conceptualize, do an early rough pitch, build the POC with stakeholders iteratively, then pitch again, this time with shared ownership of the outcome. Solo execution proved the concept. Collaborative execution would have scaled it faster.
Applicability
If I were dropped into this problem today as a consultant, the first question I'd ask is: what does it take for this specific organization to change its mind? In legacy enterprise environments, the answer is almost always demonstrated outcomes, not arguments. The fastest path to institutional change is a small, credible, well-documented proof of concept.
The second move would be to design the POC for shareability from day one — frameworks and standards that other teams can pick up and run with, not just results that live with one person.
For clients navigating similar challenges, introducing a new discipline or practice into a resistant organization, the playbook is consistent: start small, make it visible, make it replicable, and let the outcomes do the convincing.