What Should We Build First?

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

Invoca had a contact center product uncomfortably bolted onto a legacy marketing platform. It was generating only $4–6 million in ARR. It had customers, but it didn't have momentum. That question became the starting point for what would evolve from targeted improvements into a full redesign of the product's core workflow, a shift in how the team worked with engineering, and ultimately a foundation the product could actually grow on.

How do you answer a question like that? With research. Not a months-long study — there wasn't appetite for that — but a focused, one-week effort I conceived and pitched to product leadership, looking at the entire contact center product to find where the biggest problems lived.

I started by pulling Pendo session replays to watch how users were actually navigating the product. I talked to the internal CS team — the people fielding customer complaints and workarounds every day. I reviewed existing research materials that had accumulated with minimal synthesis. Within that first week, a clear picture emerged: the Calls Report was the center of gravity. It was the workflow every contact center user touched daily, and it was the one they struggled with the most.

The Pendo data told a stark story. Less than half of customer accounts were even logging 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's stickiness metric sat at 19.7% DAU/MAU — average for SaaS, but the underlying distribution was unhealthy.

The data also revealed where complexity was creating the biggest barrier. Invoca's planned onboarding was 75 days — the actual average was 92. In 2022, only 11 out of 32 customers completed onboarding within the year. The Calls Report was where users needed to build confidence that the system was working — and it was failing them.

The research caught the attention of Invoca's CEO, Gregg Johnson. He asked to review the project at a high level — we walked him through the Pendo findings, the CS feedback patterns, and the case for the Calls Report as the highest-impact investment. One question he asked stuck with me:

Getting buy-in for deeper research was a recurring challenge at Invoca — the culture leaned toward building what users asked for rather than investing time to understand the underlying problem. So we split the research into shorter phases that could each earn continued investment, proving value incrementally rather than asking for trust upfront.

Once we had approval to move forward, my PM partner Erick Montez joined the project. Erick and I would collaborate on call review and adjacent projects for the next year and a half. Jake Rowe and Brittany Choy also joined — supporting research and taking on significant design work. I led UX and collaborated with them regularly to keep the design vision aligned.

We planned a 3–4 week effort: FullStory session analysis, direct customer interviews, competitive design research, internal stakeholder conversations, and a heuristic analysis. We interviewed five customers ranging from 9-agent teams to 100+ agent organizations — eight users total, all focused specifically on their call review workflow and pain points.

Here's what they were doing: contact center QA analysts and sales managers were manually reviewing calls, hunting for coaching opportunities for their agents — looking for bad calls that needed intervention, good calls worth replicating, and anomalies that might signal a larger trend. The coaching was the point. Better call handling meant higher conversion rates. And the pressure was real — some QA reviewers had weekly call review quotas tied directly to their compensation and bonuses. This wasn't optional busywork.

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.

A QA Manager at Windstream named Matt Dunn captured the experience bluntly: "I don't use Invoca directly because it is too complicated and it overwhelms me." He wasn't alone. Across all interviews, a clear hierarchy of problems emerged.

Transcript issues were the #1 pain point. The transcription quality directly undermined everything downstream. If users couldn't trust the transcript, they couldn't trust the signals or scores built on top of it. Signal and scoring validation was next — users couldn't understand why things were scored the way they were, and the workflow forced constant tab-switching between the transcript and the Analysis tab, losing context every time.

Underneath all of it sat the foundational problem: lack of trust in the data. When we asked users directly how much they trusted the product's scoring and transcription, the answers were sobering.

Without trust in the data, users were manually validating every call before they'd stake their reputation on sharing insights internally or taking action with agents. The automation Invoca offered was being treated as a suggestion, not a source of truth.

I did substantial competitive research — direct competitors like Observe.ai, but also products outside the industry with structurally similar workflows. Gong's conversation analysis for B2B sales teams. Carvana's vehicle search at scale. Kayak's sophisticated filtering and sorting.

The cross-industry patterns were the most valuable. They showed how mature products had solved the same core problem — helping users find the specific thing they need within a massive body of options. Products like Kayak and Carvana that handled high-volume search well all treated filtering as the primary interaction, not an afterthought bolted onto a data table. That pattern became a foundational principle of the redesign.

The VP had initially approved smaller, targeted improvements to the existing Calls Report. That's where we started. But as the deeper research findings accumulated and we began working through solutions, it became clear that the problems weren't surface-level — they were structural. The existing page was a lead weight around our ankles.

I'd been advocating for building something new rather than patching the old system — the research made a compelling case that incremental fixes would inherit every bad pattern that had accumulated over the years. One of the engineering directors helped push the decision over the finish line when he put it directly: sometimes it's easier to build something new than to contend with all the baggage and technical debt. We made the call to build a new flow from the ground up — informed by everything we'd learned, unconstrained by everything that wasn't working.

We explored multiple directions, made deliberate trade-offs about information density versus simplicity, and prioritized the filter and selection workflows that research had identified as the biggest pain points.

The most important design question we asked: what content do users care about most when deciding whether a call is worth reviewing?

The answer became clear fast: AI summaries. The FullStory data had revealed something important — users were racing through calls at under two minutes each because there was no intermediate layer of information between the call list and the full transcript. They had no way to preview what a call was about before committing to it. AI summaries filled that gap — a quick read on what actually happened before committing to a full review. I pushed for summaries to be the dominant content element in the call list — not tucked behind a click or treated as secondary to metadata. It was the single most valued piece of content in the workflow.

The other critical content was scoring. Automated scorecards had existed in the product but the old Calls Report buried them. We made scores far more prominent — giving users an at-a-glance quality signal right in the call list, with the ability to override if they disagreed. Human judgment stayed the final authority while AI did the heavy lifting of initial assessment.

Based on the competitive analysis, I advocated strongly for leading with filtering as the primary interaction — matching users' actual mental model rather than forcing them into a table-first layout that research had shown wasn't working.

We brought interactive prototypes back to four customers for concept testing. The reactions were overwhelmingly positive across the board.

Sherita Vance at Christus Health — the same user who had rated her trust at 45% — saw the redesigned call list and said: "I'm loving it, it's interactive." When she clicked into the call detail page, she paused:

At BBQ Guys, the group reaction was immediate: "I like it. I really do. I like all the filters. I really like the review status. I like it overall. I'm impressed with it."

Ronnie Brown at T-Mobile — who had started the research phase rating his trust at 10% — summed it up at the end of his session: "Honestly, I love it. I think this is better than what we're doing today for sure. It seems very easy to navigate and to use. I say thumbs up, looking good."

The confusion points that did surface were minor — 75% were related to prototype limitations and placeholder content, not the design concepts themselves. The refinements from testing were mostly specifics, not directional changes. The research foundation was solid.

We launched the beta after about six months. Getting there was harder than the design work itself.

Invoca's engineering leadership was accustomed to having significant influence over what got built — and what didn't. Engineering leaders questioned the project repeatedly in the early stages — not the design decisions specifically, but whether this was the right investment at all. Political conversations had to happen between product and engineering leadership to keep it moving forward.

There was also a process challenge. Engineers weren't used to having their implementation reviewed by UX during development. The concept of a "UX review" — checking the built product against the design intent before it shipped — was new and initially met with resistance. I had to sell the process to the team, not just the design.

The engineering manager found the framing that made it click:

We weren't just completing a project. We were helping parts of the company evolve into a different way of working — one where research informed decisions, where design had a seat at the table through implementation, and where UX quality was checked before shipping, not after. That cultural shift created real friction. But the precedent it set mattered for everything that came after.

When we released the redesigned Call Review Console, the response was immediate and overwhelmingly positive. The CS team started hearing praise instead of complaints. But shipping isn't the finish line. We iterated based on real usage patterns.

Many of these features had been identified in the original research — we just hadn't been able to ship them all at once. The post-launch iteration gave us the chance to deliver on the full vision incrementally.

What I owned:

What I partnered on:

The Call Review Console redesign wasn't just a UI facelift. It became the foundation the contact center product needed to grow.

Product growth: The contact center product grew from approximately $4–6M ARR at project start to $12–15M ARR within two years of the redesign launching — roughly 3x growth. The Call Review Console was the core workflow that made the product viable for daily use by QA teams and sales managers. It didn't single-handedly drive that growth, but it removed the biggest barrier to it.

Customer response: Strongly positive reception at launch, with the CS team reporting a notable shift from complaints to praise about the calls workflow.

Process precedent: Established the UX review process with engineering — a practice that started with this project and carried forward into subsequent work.

Organizational influence: Demonstrated to leadership that research-informed design could be done in phases, earn buy-in incrementally, and deliver results — changing the conversation about how product decisions were made.

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 this quarter. 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 — the research gave us clarity on what to build, and the competitive analysis gave us patterns to draw from. The hardest part was the organizational work. Earning buy-in in phases, navigating the tension between product and engineering, introducing a new process in the middle of a high-stakes project. That's the work that determines whether good design actually ships.

Looking back, this project taught me that the most impactful UX work often isn't the most visually dramatic. The Call Review Console doesn't have a flashy hero image. It's a search-and-filter workflow for reviewing phone calls. But it was the workflow that mattered most to the people who used it every day — and getting it right unlocked everything that came after.