What Should We Build First?

In early 2023, the VP of Invoca's contact center product asked a simple question: what should I build first?

Invoca had a contact center product uncomfortably bolted onto a legacy marketing platform. $4 to 6 million in ARR. It had customers, but it didn't have momentum. Invoca's planned onboarding was 75 days; the actual average was 92. In 2022, only 11 of 32 customers completed onboarding within the year. Less than half of customer accounts logged in each month. Of those that did, the engagement split was dramatic: a small segment of power users with extremely high event counts, and a long tail of users who barely touched the product.

The product had real users with real workflows. But it was fighting them.

I started with a one-week research sprint I conceived and pitched to product leadership: Pendo session replays to watch how users were actually navigating the product, conversations with the internal CS team, review of accumulated research that had minimal synthesis. Within that first week, the picture was clear: the Calls Report was the center of gravity. The workflow every contact center user touched daily, and the one they struggled with the most.

CEO Gregg Johnson asked to review the project. He paused at one point to ask if this was more research than the company typically conducted before a project. That moment captured the deeper challenge. Invoca's culture leaned toward building what users asked for rather than understanding the underlying problem. So we structured the research in shorter phases that could each earn continued investment, proving value incrementally rather than asking for trust upfront.

The deep dive ran for 30 days. Five customer companies, 8 users, 8 FullStory accounts analyzed. The workflow had two distinct levels: first, find calls of interest within a massive body — for some customers, millions per month. Then, find moments of interest within a specific call — the fumbled pitch, the brilliantly handled objection. The Calls Report was supposed to make both levels efficient. It wasn't. The pattern that emerged: users were spending entire workdays in a tool they didn't trust. Trust scores averaged around 50% across customers, with some as low as 10%. Without trust in the data, users were manually validating every call before they'd stake their reputation on insights or actions.

The reframe: this wasn't a UI problem, it was a trust problem. Every other issue (transcript quality, signal scoring, navigation) was a tributary feeding the same river. Until users could trust what the product told them at a glance, the workflow couldn't function as the daily driver it needed to be. That framing turned a list of complaints into a single design priority: the call review workflow needed to surface what mattered, fast, in a form users could verify in seconds.

Beta launched after about six months. The CS team started hearing praise instead of complaints. AI summaries, added late in the development cycle, became the most talked-about feature at launch. Customers didn't just want them — they wanted to download them, aggregate them across thousands of calls, and build workflows around them. Concept testing with customers had been overwhelmingly positive. The same Christus Health user who had rated her trust at 45% saw the call detail page and paused.

The contact center product grew from approximately $4 to 6M ARR at project start to $12 to 15M ARR within two years of the redesign launching. Roughly 3x growth. The Call Review Console didn't single-handedly drive that growth, but it removed the biggest barrier to it.

Post-launch, we kept iterating: comment filtering, "mark as reviewed" status (eliminating a workaround the onboarding team had built), helper content, "last viewed" so reviewers could pick up where they left off. Many of these features had been identified in the original research; we just hadn't shipped them all at once.

The UX review process started with this project carried forward into subsequent work.

The question that started this project, what should I build first, is one of the most important questions a product team can answer well. Most companies answer it with whatever users asked for most recently or whatever a sales rep needs to close a deal. We answered it with a week of research, and that week changed the trajectory of the product.

The hardest part wasn't designing the solution. It was the organizational work. Earning buy-in in phases. Navigating product-engineering tension. Introducing a new process in the middle of a high-stakes project. That's the work that determines whether good design actually ships.