4 Products Into One Voice AI Platform
Four disconnected products with separate interfaces, teams, and design patterns. No unified surface for voice AI. Two products lacked product-market fit.
Identified the shared primitive across all products (channel + logic + agent), drove kill decisions on two products, and directed the workflow builder evolution from drag-and-drop to fully prompt-based — while growing and mentoring the team that executed it.
Self-serve autonomy: agent config reduced from 1 week to under 1 hour. Unified control plane. Legacy tech debt sunsetted to fund the AI pivot.
The Challenge: The Chaos of Four
Starting in 2020, Plivo began building products for non-developer teams on top of its existing API infrastructure: a Sales Management Platform, a messaging and marketing platform, and a contact center for inbound support. By 2023, these sat alongside the traditional voice and messaging APIs, giving Plivo four products total. Each was built by a different team with its own interface, navigation, and design patterns. Customers buying multiple products got four disconnected experiences from one company.
As the market shifted toward voice AI, this fragmentation became a strategic blocker. There was no unified surface for building workflows that spanned voice, messaging, and agent management. More fundamentally, we had to decide which products deserved continued investment and which needed to be shut down. Four products needed to become one platform, and not all of them would survive.
Sellular Sales Management Platform 
Contacto Contact Center 
Engage Messaging & Marketing 
API Communications Infrastructure My Role
I started this project as Associate Director of Design and expanded into managing the entire product ecosystem over five years. My scope was strategic, not executional: I determined which products would live or die, defined the platform architecture that would replace them, and set the product direction for the voice AI pivot. A team of designers, which I grew from one to seven, executed the interfaces and interaction patterns under my direction.
Day to day, I owned sprint planning for the unification pod, held decision rights on what to build, sunset, or merge, and reported directly to executive leadership on consolidation progress. I sat in architecture reviews with engineering to shape technical decisions that had UX consequences, particularly around LLM context handling and workflow generation. I also ran weekly cross-team design reviews to catch diverging patterns early and maintain consistency across the platform.
The Strategic Decisions
What to keep, what to kill
Not every product deserved to survive. The messaging and marketing product had entered the market too late. Existing competitors were solving most use cases at effective cost, and we were not seeing product-market fit. I drove the decision to shut it down rather than chase perceived market share. In hindsight, we should not have been blinded by the opportunity without validating demand.
The Sales Management Platform was a much harder conversation. It had evolved from a simple dialer into a full-scale management tool, and it was generating revenue. However, the market was shifting toward AI agents, not outbound automation. As part of the executive leadership team, I co-sponsored the difficult decision to sunset it. We did not want to be a brand that contributed to outbound spam. To execute this safely, I defined a six-month transition framework: in-product notifications with a clear timeline, direct connections to account managers, and a maintenance-only policy with no new features during the wind-down. No enterprise-scale customers were lost in the migration.
The contact center's inbound support function is what transitioned into today's voice AI platform. Customer support represented the clearest use case for voice AI, and enterprise customers were actively seeking this. That became our focus. The traditional API product carried forward as the infrastructure layer.
Instead of features locked inside separate products, channels, workflows, and agents became reusable building blocks. A voice channel could use the same logic engine as a messaging channel. An AI agent could be swapped in where a human agent previously sat. The pattern held across every use case we tested it against.
Today, Plivo stands as one console that serves traditional telephony infrastructure, API use cases, and AI agent use cases in a single surface.
The shared building block: Channel + Logic + Agent 
Contacto Voice Routing 
Engage Marketing Journeys The Workflow Builder Evolution
The interaction model for building voice agents went through three distinct phases, shifting the platform from a high-touch engineering bottleneck to a fully self-serve ecosystem.
Phase one was a drag-and-drop canvas. While it worked for simple call routing (business hours, FAQ handling, forwarding rules), it broke down as workflows grew complex. Because users struggled to map abstract logic onto a visual canvas, the platform was decidedly not self-serve. Customers required a week of white-gloved engineering hand-holding to build, polish, and deploy anything meaningful.
Phase two introduced prompt-driven creation alongside the visual canvas. Users could describe what they wanted, and the system generated a workflow structure. Manual intervention was still required for editing, reordering, and deleting nodes. During this hybrid phase, we saw agents underperforming because customers would forget to plug in required actions (for example, a data-fetching step). The agent would then hallucinate because it could not access the data it needed. We had to go back and debug these configurations repeatedly.
Phase 2: Hybrid prompt + canvas — AI generates the structure, humans wire up the nodes Prompt-generated workflow with manual node editing and configuration Phase three, which is live today, unlocked true self-serve autonomy. We moved to a fully prompt-based, single-node architecture. The move from multi-node to single-node was driven by a clear product problem: context was not transferring cleanly between LLM nodes, causing conversation loops, broken flows, and increased latency. This was not a UI update. It was a backend architectural pivot driven by UX research.
I drove this decision by bringing user experience data into the architecture conversations. Our research showed that conversation quality degraded when context passed between nodes, and I used that evidence to shape how the engineering team approached context window handling. The result: the system now autonomously evaluates the steps and generates the agent end to end, eliminating the class of errors caused by manual multi-step misconfiguration. We also introduced integrated simulation testing, allowing users to pressure-test AI logic safely before deployment.
Phase 3: Fully prompt-based agent builder — from prompt to simulation-tested agent in under an hour
Platform Decisions
Unifying the design language across teams
With two designers per product team, each product was developing its own patterns despite the existing design system. I directed the team to consolidate on a shared library built on shadcn/ui with Inter as the universal typeface. This was a deliberate constraint for a lean team: a component library that mapped cleanly to development meant the team could ship faster without sacrificing consistency. Overlapping patterns were identified in weekly cross-team reviews and reconciled before they shipped.
Permissions and role-based access
When the platform served human agents, I defined a seat-based permissions framework to solve two problems: directing incoming calls to the right person, and ensuring operators only saw what was relevant to their role.
The framework established three roles: admin (full platform access), supervisor (read and write access to workflows, no delete), and specialist (limited to customer interactions, quality monitoring, and read-only data access). This separation was critical for larger teams where not everyone should be able to modify call routing or access billing.
As the platform transitioned from human agents to AI agents, admin and supervisor roles carried forward. We mapped out a dedicated billing and finance role for multi-stakeholder accounts, though the current migration to a unified console means this is still being implemented in its final form.
CDP (contact data platform)
I argued against building a native CDP due to unsustainable infrastructure costs from live syncing. We built it for short-term survival: the product needed it to function. I deprecated it the moment integration ecosystems matured. A design leader must know when to build, but more importantly, when to delete.
Enterprise Empathy: Building for Trust in AI Adoption
Enterprise customers do not adopt AI the way startups do. They are risk-averse. Handing customer support over to an AI agent represents an existential-level concern for companies whose brand depends on service quality. I established the adoption framework around one insight: enterprises will not hand over control unless they can verify the AI's behavior before it touches a real customer.
The framework had three stages. First, simulation testing as the entry point: before an AI agent handles a single real call, customers can pressure-test its logic against real conversation scenarios in a safe environment. This makes the invisible visible, which is the prerequisite for trust. Second, gradual rollout controls: customers route a percentage of traffic to the AI agent while humans handle the rest, increasing the ratio as confidence grows. Third, transparent performance data: showing exactly where the agent succeeded and where it fell back to a human, so the decision to expand is data-driven rather than faith-driven.
This principle extended beyond the product itself. The six-month sunset windows for legacy products, the transparent communication during transitions, the simulation testing before go-live: all of these reduced the perceived risk of change for organizations where failure is not an option. Trust became a design material, not an afterthought.
Test Scenarios Caller Objectives 
Simulation Results Multi-Run Comparison 
Eval Metrics Quality Scoring 
Goal Results Conversation Analysis The Outcome
- 4 to 1 Consolidation: Replaced four disconnected products with a single unified console built on reusable building blocks (channel + logic + agent)
- Universal Access: One surface where users build across voice, messaging, and agent management without switching environments
- Self-Serve Autonomy: Agent configuration went from a week-long, white-gloved process to under an hour, fully self-serve. No engineering hand-holding required
- Team & Succession: Grew the design team from 1 to 7, then right-sized to a lean team shipping faster with AI-assisted workflows. Mentored my direct report into independent platform leadership over six years
Building the Team That Built the Platform
The consolidation was a five-year arc, and no single person could carry it alone. I mentored a design manager through every phase: he started on the Sales Management Platform, transitioned to the contact center when sales was sunset, and had to learn the API ecosystem and legacy infrastructure alongside the new AI layer. My coaching covered sprint planning and product lifecycle management, business-customer intersection thinking, and giving direct feedback cross-functionally.
He now leads the current platform migration (merging AI and API into one console) independently. That handoff is the outcome I am most proud of. A leader's job is to make themselves unnecessary, and the fact that this work continues without me is the strongest evidence that the system we built was sound.
Reflection: Deciding What Should Exist
The five-year arc of this project taught me that platform-level design leadership is as much about deciding what products should exist as it is about designing the ones that do. The hardest work was organizational: aligning teams around a shared model, making painful cuts that did not have immediate payoff, and building people who could carry the work forward independently.
In an industry obsessed with adding features, real leadership is about clarity: knowing what to keep, what to kill, and what to consolidate. The messaging product should have been killed sooner. The Sales Management Platform sunset was the right call made at the right time. The CDP was built knowing it would be deleted. Each of these decisions required a different kind of conviction, and each made the platform stronger by making it smaller.