Stephany Cardet · Simplicity always wins

Bottom line, up front

Every new deal triggered 2+ hours of research. I designed a feature where Ava runs that research automatically and keeps it current as deals evolve, cutting discovery time by 67% and giving the whole team a shared starting point.

Ava is an AI agent for sales engineering and account executive teams. She connects to the tools these teams already use - Salesforce, Slack, Google Drive, Gong, and the web - and works autonomously across them to handle the research, preparation, and context-gathering that surrounds every deal.

Problem

Before any real work could happen, every deal started with hours of research

A new opportunity appears in Salesforce. Before a sales engineer can have any meaningful conversation with that prospect, they need to know who the company is, what technology they use, who their competitors are, and what challenges they probably face. So they start researching. Google, LinkedIn, news articles, whatever they can find. Then they compile it somewhere. Then they share it with the team.

Then two weeks later, after a call where the prospect mentioned a new initiative and a competitor they hadn't heard before, that document is already wrong.

“I spend 2–3 hours researching each new deal before I even know enough to have an intelligent conversation.”

Sales Engineer

Discovery

10 of 12 sales engineers reported spending 2+ hours on discovery per deal. Every deal.

And 9 of 12 said those documents went stale almost immediately after creating them. Companies change. Calls reveal new information. Nobody had time to go back and update the doc.

10 of 12 sales engineers reported spending 2+ hours on discovery research per new deal, a pattern confirmed by time logs in Hero.

9 of 12 struggled to keep discovery documents current as they learned more from prospect or customer calls, often resulting in outdated artifacts or multiple conflicting versions.

Key insights

Speed matters for first impressions. The faster sales engineers could complete discovery, the sooner they could engage meaningfully with prospects. Delayed discovery meant delayed outreach, giving competitors a head start.

Discovery is a team sport. Multiple people often work on the same deal: account executives, sales engineers, solutions architects. Everyone needs the same foundational knowledge, but they were each doing their own research independently.

Discovery became outdated quickly. Once created, discovery documents became static snapshots. Companies would announce funding, change priorities, or launch new products. Sales engineers would learn critical information during prospect or customer calls. But this new context was rarely added back to the original document.

Methods: User Interviews, User Survey

Opportunity

The real opportunity wasn't just automating research. It was keeping it current.

If every sales engineer was doing the same research in the same order for every deal, Ava could own that. But the more interesting problem was what happened after. Discovery became a static snapshot the moment it was created. The actual opportunity was building something the whole team could trust over time, not just at the start.

That shifted the question from "how do we help someone research faster" to "how do we build a shared source of truth."

Strategy

I needed to figure out what Ava should know and where to get it

Working with engineering, I mapped out which integrations could source discovery and which events could trigger updates. A completed meeting, a new Gong recording, a Salesforce stage change - each one became a signal that something might have changed worth revisiting.

For structure, I ran card sorting with sales engineers and stakeholders to figure out what information mattered most and in what order. The sections that came out of it weren't surprising. What mattered was the sequence. Business context consistently came before technical details in early-stage deals. Sales engineers needed to understand why a company was evaluating something before they cared about what tools they used.

Methods: User Interviews, Card Sorting

Design

A chat message felt right, until I watched what users actually did with it

My first direction delivered discovery conversationally in the deal thread. Ava would summarize what she found when a new deal appeared.

Iteration 1: conversational delivery of discovery in chat

Testing broke that assumption quickly. Users weren't pushing back on the content. They were fighting the format. I kept watching people scroll up mid-session to reread Ava's message. One user took a screenshot to save it somewhere else. Nobody treated these as conversations. They treated them as documents trapped in a chat thread.

A good conversation message is timely. A good knowledge artifact is persistent, scannable, and shared. Those are different things, and I was building the wrong one.

Making discovery a first-class object changed how teams related to it

Discovery became a persistent artifact at the top of every deal, not a message in a thread. The conversation surfaced changes: when Ava updated discovery based on a new Gong call or Salesforce note, she'd post a short message explaining what changed and why.

Iteration 2: discovery as a persistent artifact

The artifact was shared by default, which solved the duplication problem from research. One starting point, visible to everyone on the deal, from the moment the opportunity appeared.

When Ava couldn't find enough to build full discovery, she said so and suggested questions the sales engineer could ask on the first call to fill the gaps. When multiple deals existed for the same company, she flagged it and let the user decide whether to link or start fresh.

A/B testing validated the approach. Users navigated faster, spent less time re-orienting when they opened a deal, and reported feeling more confident going into prospect conversations.

Two edge cases came up consistently in testing and needed explicit design decisions.

Ava’s design was guided by the idea that she was a teammate. Like any good teammate, she would speak up when she didn’t know something or when something was incomplete. When she couldn’t find enough information to build meaningful discovery, she created a partial artifact rather than waiting. She communicated directly in the conversation what was missing, and offered to suggest questions the sales engineer could ask on the first call to fill those gaps.

When multiple deals existed for the same company, Ava flagged it and gave users a choice: link to the existing discovery or start fresh. That prevented silent duplication while keeping the user in control of the decision.

Methods: User Interviews, A/B Testing

Impact

Less time on discovery. Artifacts used by more than one person.

The feature launched to early adopters and the results showed it had a real impact on how sales engineers worked. I measured discovery time the same way we had during research, through activity logs, which meant the before and after numbers were directly comparable.

67% reduction in discovery time, confirmed through activity logs showing how much less time sales engineers spent on research per new deal.

90% of discovery artifacts were used by multiple team members, demonstrating successful knowledge sharing across deal teams.

The 90% number is the one I keep coming back to. The goal was never just to save one person an hour of research. It was to give the whole deal team a shared reference. That number suggests the artifact format did that job.