Setting the scene

Config Management is a free feature bundled with every GKE license. Research showed customers who adopted it stayed with GKE significantly longer. It was a retention driver hiding in plain sight, and almost no one was using it.

Without intervention, a significant engineering investment would deliver little to no ROI. Leadership prioritized it.

Why wasn't anyone using it?

Only 2% of customers visiting the Config Management section installed anything. The feature was free. The problem wasn't price.

User research interviews pointed to two root causes. First, "Config Management" is an ambiguous label in the cloud space. Customers landed on the page and couldn't tell what the product actually did. Second, two distinct tools, Config Sync and Policy Controller, were bundled into a single combined flow. Users didn't understand why installing a security feature required configuration steps, or vice versa. The combined experience obscured both products.

The constraints made this harder than it sounds. No dedicated PM. I was the only designer supporting two separate feature teams with different release schedules. Engineering and Product disagreed on the path forward: Engineering wanted to invest in command-line flows, Product wanted UI-first. Leadership wanted results quickly.

Getting everyone pointed in the same direction

Without a PM, I proposed a mini-workshop with the Director of PM to get the project grounded. We synthesized existing customer feedback, aligned on Config Management's strengths and weaknesses, and defined what success looked like. One clear priority emerged: quick installation and fast value realization. Customers liked to experiment with infrastructure tools before committing. The higher the installation barrier, the fewer customers would ever discover the value.

That workshop gave us a shared direction. From there, I partnered with the UX Researcher to build a design vision we could use to align Engineering and Product around a single path forward.

One gap became obvious fast: without a PM, we were relying on documentation to understand how the installs actually worked. I flagged this early and brought a Customer Success Engineer into our design sessions. He understood the technical complexity at the level we needed. That decision prevented costly mistakes and built Engineering trust before we got to prototyping.

Three bets we made on the design

Three problems needed solving: confusing information architecture, a combined installation flow that served neither product well, and a zero-state page that gave users no reason to proceed.

Separating the two tools. I proposed restructuring the IA to give Config Sync and Policy Controller each their own presence within a Config Management section. Each feature could stand alone, be found independently, and communicate its own value. This required Engineering to decouple the shared backend, which met initial resistance. I walked Engineering leadership through the prototype and research findings directly. They agreed the UX improvement justified the investment.

Rethinking the zero state. Another GKE team had researched what drives conversion from zero-state dashboards. The clear winner: showing users what the product looks like when it's working, before they install anything. I applied that pattern to both Config Sync and Policy Controller. The new flow became: value-first dashboard, install, observe. Simple and linear.

Consistent installation flows. With two decoupled features launching simultaneously, Engineering requested consistent installation patterns across both to reduce build effort. From a UX perspective, consistency also meant a more predictable experience for users switching between tools. Both goals aligned.

The prototype. I built the full flow in Axure RP rather than Figma. HTML-based prototypes produce better research signal: users respond to something that feels like a live product differently than they respond to a static mockup. The prototype covered Day 0 (not installed) through Day 2 (data in the UI) for Policy Controller.

Putting it in front of real users

The UX Researcher and I ran task-based usability tests with users representing current and potential Config Sync customers. We combined interviews with prototype tasks: install Policy Controller, install Config Sync, explain what each feature offers.

Users immediately understood that two distinct tools existed once the IA was separated. The value-first dashboard orientation worked: users consistently grasped what they were getting before being asked to install. The simplified UI flow felt noticeably easier than the command-line alternative.

One surprise: users noted the UI would help them get started and experiment, but said they'd likely switch to command line for production environments where they needed full control. That finding was honest and useful. It validated the milestone 1 focus on installation and experimentation, and pointed directly to what milestone 2 would need to address.

We presented the designs and research findings to leadership. They approved moving forward with full prioritization for the following year.

The outcome

Config Sync conversions went from 2% to 11%, a 9-point lift, sustained after rollout. The feature moved from underutilized to a measurable driver of customer retention.

Users noticed the separation most. Several described Config Sync as more straightforward than they expected, which validated the core bet: clarity of purpose matters more than feature richness when driving initial adoption.

The pattern, value-first zero state paired with a simplified linear flow, became replicable across other GKE features facing similar adoption challenges.

What I'd do again

Operating without a PM forced better thinking. Facilitating the workshop, building the vision, and aligning conflicting stakeholders pushed me into product strategy territory I wouldn't have touched otherwise. That discomfort sharpened the work.

Research broke the impasse between Engineering and Product better than any argument could. Prototype testing gave both sides objective evidence to align around. The findings didn't just validate the design; they gave leadership the confidence to approve a significant engineering investment.

Bringing the CS Engineer into design sessions early was the decision I'd repeat first. It cost nothing and prevented months of rework.