Click the image to visit.
Background
An audio AI company that sold technology, not products
Gaudio Lab develops audio technologies ranging from source separation and noise removal to text-to-audio and spatial audio. These technologies were delivered to customers through SDKs, APIs, and embedded solutions.
However, customers had to work directly with the Business Development team to access them. Each technology was also managed by a different team, making product information difficult to maintain and share consistently. As inefficiencies accumulated across sales, integration, and support, we decided to bring these technologies together into an unified developer platform.
Product Goal
Building a scalable developer platform
Our goal was to create an intuitive platform where users could discover, purchase, and integrate our products without relying on the sales team.
As the PM responsible for the company’s first developer platform, I led the process from user research and requirements definition to wireframing, product policies, validation, launch, and roadmap planning.
Research
Interviewing customers and internal stakeholders
I interviewed 10 people across the product lifecycle: 3 customers, 2 business developers, 2 AI/DSP researchers, 2 product developers, and the CEO. The goal was to understand pain points from technology development and deployment through sales, integration, and actual use. This revealed both immediate customer friction and structural issues that made it difficult to turn our technologies into scalable products.
Customers: Learning what products were available, signing contracts, and checking usage all required contacting a representative. Authentication methods and supported audio specifications also varied across APIs, increasing the effort required for integration.
CEO: Wanted to turn technologies into products faster and create new sources of revenue.
Business Development: Limited capacity made it difficult to respond to every inquiry. The team focused on larger contracts, leaving smaller opportunities underserved.
Product Development: Different model structures made each deployment resource-intensive, while standardized QA criteria were limited.
AI/DSP: Researchers lacked clear product requirements for audio specifications, QA, and performance metrics when models moved into production.
Discovery
Fragmented information and a lack of standardized processes
The interviews revealed two recurring problems:
Information was fragmented across customers, Business Development, Product Development, and AI/DSP.
Processes were not standardized, so similar problems were repeatedly handled case by case.
Together, these issues created friction throughout the process of turning technologies into products and delivering them to customers.
Defining Requirements
Balancing technology, usability, and scalability
To define what could be included in the first launch, I needed to align stakeholders around three questions: What products should we offer? What capabilities should we provide? How much information should we expose?
I first mapped the requirements for the ideal version of the platform. I then worked with each team to identify the constraints that would shape the first release.
Business Development: Existing contracts, billing structures, and customer management
Product Development: Time and resources required to standardize technologies into products with consistent usability and I/O specifications
AI/DSP: Technical performance, competitive positioning, and future research roadmap
CEO: Business priorities, company timeline, and alignment on product goals
After several rounds of discussion, we decided to focus the first release on APIs, which were already receiving the most customer inquiries. The initial scope therefore centered on standardizing API products, building the onboarding flow, and providing the information developers needed to start using them.
I then structured the platform into four core areas based on their roles and future scalability. I also defined requirements that could accommodate additional technologies beyond the first launch. This process led to several parallel projects, which I coordinated alongside the platform development.
Wireframe
Prototyping with AI agents to reach decisions faster
Some decisions were difficult to communicate through documentation alone. Since many stakeholders were not familiar with developer tools, I used AI agents to quickly turn different options into interactive prototypes. This made it easier to discuss ideas through actual use rather than abstract descriptions.
For example, our API models had different capabilities and parameters, making it difficult to represent them consistently within one dashboard. I first grouped the models into three types based on their input and output structures. I then prototyped different filter structures with an AI agent and shared them with stakeholders to gather feedback on usability.
This allowed us to compare alternatives through direct interaction and make decisions faster.
Building
Several projects running in parallel toward one launch
Defining the platform created several parallel projects, and completing the product required bringing their outputs back together into a consistent experience. As the PM responsible for the overall platform, I translated requirements into concrete deliverables, kept each project aligned with the product direction, and continuously coordinated progress and dependencies across teams.
Design: The designer built a design system on top of my wireframes and guidelines, and we collaborated throughout implementation
CEO / Staff: Coordinated company communications, executive briefings, launch timing, press releases, and promotional materials
Business Development: Recruited customers for pre-launch testing
Product Development: Standardized API key authentication, API calls, error codes, parameters, and I/O specifications based on recurring customer inquiries
AI Team: Defined the scope and criteria for competitive model benchmarking
Outcome
The impact showed up immediately after launch
The platform turned a previously manual API business into a self-service product that customers could discover, integrate, and pay for on their own. The structure also proved extensible: the catalog grew from 3 API products to 12 within four months of launch, without redesigning the customer journey for each one.
Scalability: API products offered
3 → 12 in 4 months after launch
Revenue: First post-launch enterprise contract
~$50K, closed within 1 month of launch
Growth: Paying enterprise customers
2× the pre-launch count in 3 months
Impact
One system that could scale with both customers and the business
For customers, the platform made it possible to explore new AI models, understand what each product offered, access the information needed for integration, and start using them without going through a separate sales process.
For the company, it established a repeatable path from product launch to monetization. Instead of rebuilding the customer journey for every new model, teams could launch products within a shared structure for documentation, authentication, usage, billing, and account management.
For customers: Faster onboarding · Self-service integration · Clearer product information
For the business: Repeatable launches · Immediate monetization · Centralized customer management
Key Challenges
Designing for developers without being one
The hardest part was not drawing the interface. It was understanding enough of the technical system to make the right product decisions.
I had to translate different AI models into a consistent product structure, determine what information developers needed during onboarding, and design for customers with very different purchasing models, from individual pay-as-you-go users to enterprise accounts.
At the same time, the product structure and policies were being defined together. Decisions about authentication, API keys, file handling, usage, billing, and account permissions were not simply backend constraints. They directly shaped the customer experience.
Reflection
Learn the system before simplifying it
This project changed how I approach complex products. I learned that simplifying an experience does not mean hiding technical complexity. It means understanding that complexity well enough to decide what the user needs to see, when they need to see it, and what the product can handle for them.
Working closely with engineers also changed how I communicate product ideas. Instead of treating technical feasibility as something to validate after design, I began bringing it into the design process itself, using flows and functional prototypes to make decisions concrete and resolve ambiguity earlier.