Demo experience research → cross-org infrastructure changes

Context

Cisco employees and external partners use demo environments (built on a shared Cisco platform called dCloud) to walk customers through the Meraki product. The team I was on owned the Meraki side of those demos. I was handed a narrow question: what pain points exist for users of Meraki demos specifically?

The real job turned out to be recognizing that this was the wrong question. As participants kept surfacing friction with the underlying dCloud platform itself, not just with Meraki content, the work stopped being a Meraki demo study and became a cross-org input into the broader demo platform. Most of the value was in reframing what the research was actually about, and then having the evidence to make that reframing land with teams who hadn’t asked for it.

What I did

The work ran in two sequential phases, designed so qualitative depth could inform quantitative scope.

Phase 1 — Interviews (15 sellers, November 2025): One-hour sessions with 15 Meraki sellers (11 technical sellers and 4 business sellers) spanning Cisco employees, channel partners, and distributors. Interviews explored how demos fit into actual sales and pre-sales workflows: how sellers chose platforms, how they prepped for different customer situations, and where things broke down.

One useful output was mapping a “demo prep spectrum”: from fully prepared (known customer requirements, time to identify the right environment) to fully ad-hoc (“can you hop on this call right now?”), which clarified that the same platforms needed to serve very different use modes with very different needs.

After the first couple of sessions, a pattern was clear enough to act on: the friction wasn’t really about Meraki content but about the dCloud platform underneath, and a sibling product, Catalyst Center, kept surfacing the same way. Because the sessions were moderated, I could follow that signal live and promote those two threads from occasional follow-ups into standard parts of the protocol. That mid-study shift is what set up the survey’s broader audience.

Findings clustered into four pain point areas, most of them platform-level issues belonging to the dCloud team rather than Meraki-specific ones:

• Demo discoverability
• Lack of realistic enterprise-scale data
• Read-only limitations blocking full workflow demos
• Demo maintenance problems

Phase 2 — Survey (201 sellers, January 2026): A follow-up survey sent to a broader audience of Meraki and Catalyst Center sellers (145 Cisco employees and 56 partners/distributors) to validate the qualitative themes, weight priorities, and check whether seller type changed what mattered most.

The survey confirmed the interview findings and added quantitative weight. One number became a useful anchor for stakeholders: 81% of sellers reported that demo quality has a significant to critical influence on whether an opportunity moves forward. Zero reported minimal influence. That reframed the platform problems as business-critical, not just usability annoyances.

Outcome

On the platform side, the dCloud team made concrete changes traceable to the research: improved content tagging, removal of outdated demos, and improvements to the platform’s search experience.

On the influence side, the work reached well beyond my immediate team: findings were presented to leadership in sales enablement and sales engineering, organizations outside the original research scope entirely. That cross-org reach was the unexpected outcome.

Qualitative readout — The Seller Demo Experience: Identifying Top Pain Points (PDF)

Survey readout — Improving the Demo Experience for Sellers (PDF)

Reflection

The sequential design was deliberate: qualitative interviews to surface what the real problems were and build the conceptual framework, survey to validate that problems were widespread and to weight which mattered most. The survey also revealed a difference interviews alone couldn’t have shown: Catalyst Center sellers and Meraki sellers had meaningfully different priorities, which would have shaped recommendations differently if only one group had been surveyed.

Beyond the design choice, this was the project that taught me to design research with permission to expand the scope. If I had held strictly to the original “Meraki demos only” framing, the dCloud findings (which turned out to be the most actionable piece) wouldn’t have surfaced.

It also reinforced that the right time to broaden a study is when participants are already drawing the broader picture for you. The platform-level pain wasn’t something I went looking for; participants kept bringing it up unprompted. The job was to listen, recognize the pattern, and then make space in the synthesis and the readout to address it honestly.