Launch Tanzu Data Services
Leadership asked for a feature. I made the case for a platform: a unified services experience that developers and platform teams could build on, monitor and manage.
- Context
- A new team and a net-new product. Data services were scattered across CLI tools, with no end to end flow & shared model for developers or platform teams.
- Role
- Staff Product Designer / Design Lead. Strategy, research, experience architecture, end-to-end design and design system, aligned across Product, Engineering and Business.
- Impact
- +10%platform adoption−22%support calls0→1first GUI data services launch
From a fragmented list of services to a service experience
Find the right service without knowing where it lives
One catalog for every service across the Tanzu ecosystem, organized around what a developer needs instead of which product or provider owns it.
Turn infrastructure config into a guided workflow
A technically complex setup became a step-by-step flow that shows the right information at the right moment.
One place to understand a service
Health, configuration and the apps that depend on it come together around the resource, instead of being scattered across tools.
Make invisible relationships visible
A visual model of how services and applications connect across the platform, readable at a glance.
Three moments that shaped the product
We weren’t designing for one user
Interviews with developers and platform engineers showed a two-sided ecosystem. What a provider could publish and configure determined what a developer could discover and consume.
A service list couldn’t serve both sides, so the scope had to become the whole service lifecycle, and that lifecycle became the experience architecture.
A service list or a marketplace
The first answer from leadership was to scope down: add a service list to an existing page and ship in six weeks. I pushed back with the data we’d gathered, not an opinion, and put both options side by side.
Service list on an existing screen
- Fast, low risk, shippable in weeks
- Doesn’t solve discoverability
- No way for admins to publish or manage
- Another fragmented surface to undo later
Marketplace and management layer
- One quarter to production
- Solves discovery, publishing and management
- Projected drop in support tickets and lift in adoption
- A foundation other teams can reuse
Leadership approved the full scope.
Winning the argument meant co-owning the outcome
I set success metrics and MVP scope with the PM up front. Producer and consumer workshops, run separately and then together, used storyboards so engineering could challenge feasibility early and the business could see user impact without reading a spec.
With the design system team, I turned the work into reusable patterns and mentored designers to apply them.
The goal was to make the next product easier to design than the first.
From fragmented tools to a platform capability
The patterns we established became the foundation later Tanzu teams built on, and the research-led pushback on scope helped establish design’s seat at the product strategy table.