Cloud migration services are one of the major revenue streams for our organization, particularly migrations between platforms like Google Workspace and Microsoft Teams. During a strategic discussion with the CTO, we uncovered a recurring business challenge: existing migration platforms solved the technical need, but introduced significant inefficiencies, workflow friction, and revenue leakage through third-party dependency costs.

​

This opened an opportunity to explore whether we could create our own migration platform. Due to limited internal bandwidth, I was trusted to independently take this from product discovery to MVP execution, owning research, product definition, UX design, and frontend implementation.

The trigger for this initiative was not a conventional design request, but a business opportunity.

Our organization was actively using third-party migration tools like CloudM and BitTitan to support customer migrations. While effective, these platforms came with commercial trade-offs, reduced flexibility, and workflows shaped around external business models rather than our internal operational realities.

The opportunity was straightforward:

Could we build an internal migration platform that better aligned with our cloud engineering workflows while protecting long-term business value?

That became the working hypothesis.

This was a deeply technical problem space, so visual design alone would have been superficial without domain understanding.

​

I spent extensive time with cloud engineers to understand:

• migration workflows
• technical dependencies
• operational bottlenecks
• platform limitations
• validation processes
• failure scenarios
• existing tooling frustrations

​

These conversations were critical because cloud migration is not just a UI problem. It is a workflow orchestration problem shaped by technical constraints, compliance considerations, and operational precision.

Once I had enough domain context, I studied both native and third-party migration ecosystems, including:

• Google Cloud Migration Center
• Microsoft Cross-Tenant Migration
• CloudM
• BitTitan
• CloudiWay

​

The goal was not feature replication. It was understanding how different platforms approached workflow complexity, technical abstraction, and migration orchestration.

​

For example, native platforms like Google and Microsoft offered strong technical depth and ecosystem integration, but many workflows felt operationally rigid, shaped more by platform constraints and business priorities than user efficiency. Third-party tools like CloudM and BitTitan provided broader migration flexibility and mature workflows, which I found useful from a feature completeness perspective, but some interactions still felt unnecessarily complex for operational teams handling repetitive migration tasks.

​

This helped me evaluate what should be preserved, what needed simplification, and where we could create a more streamlined operator-first experience rather than simply mirroring existing solutions.

This project became a major personal milestone.

​

Given limited engineering bandwidth and my parallel exploration of AI-assisted development workflows, I made the decision to go beyond traditional design ownership and build the frontend MVP myself.

​

Using Claude inside Figma Make as an AI-assisted development collaborator, combined with clear design references and system thinking, I moved from static UX design into frontend implementation. This allowed much faster iteration, tighter feedback loops, and a more tangible validation artifact than static prototypes alone.

​

For me, this was less about experimentation and more about expanding design leverage.

Because the product operated in a technical domain, validation depended heavily on close collaboration with cloud engineers.

​

Throughout the process, I regularly reviewed workflows, assumptions, and product decisions with the engineering team to ensure the experience aligned with real migration operations.

​

This iterative feedback loop helped avoid designing conceptual workflows that looked clean in UI but failed operationally.

The MVP was successfully completed and positively received by:

• The CTO
• Cloud engineering stakeholders
• Internal teams evaluating the opportunity

​

Key outcomes:

• validated an internal product opportunity tied directly to a revenue stream
• reduced dependency on conceptual third-party alternatives at the exploration stage
• created a working MVP instead of static product speculation
• demonstrated independent 0 → 1 product ownership

​

The product is currently awaiting engineering bandwidth for full production implementation.

This project fundamentally expanded my understanding of product ownership.

​

I learned how to operate in highly technical domains, how to collaborate with subject matter experts without shallow assumptions, and how product design can extend far beyond interfaces into business strategy and execution.

​

It was also the first time I independently took a product from opportunity discovery through research, scoping, design, and frontend MVP execution.

​

That shift changed how I think about the role of a modern product designer.