We Evaluated WalkMe, Pendo, and Whatfix. Then Built Our Own.
The buy decision should have been obvious. Three mature platforms, WalkMe, Pendo, Whatfix, all offered exactly what we needed: in-product guidance, contextual help, user onboarding flows. All had enterprise customers. All had proven track records.
We evaluated all three seriously. Then we built our own.
This isn’t a vendor criticism. All three are solid products that work well for many organizations. But Cisco isn’t one product. It’s an ecosystem of dozens of products, each with its own compliance requirements, data sovereignty constraints, and user base with radically different needs. Network engineers configuring firewalls and marketing managers using collaboration tools aren’t just different personas: they operate in different compliance zones with different data gravity.
What “buy” couldn’t solve
The limitation we kept hitting wasn’t functionality. All three platforms could deliver guidance overlays, contextual tooltips, and onboarding walkthroughs. The limitation was architectural.
At Cisco’s scale, we needed a Digital Adoption Platform that could deploy across dozens of products without duplicating content. Every guided workflow, every troubleshooting sequence, every piece of institutional knowledge needed to be authored once and deployed everywhere: what we internally call BODE: Build Once, Deploy Everywhere.
This isn’t a preference. When your support organization handles 1.2 million cases per year, the knowledge behind each guided step has to come from a single source of truth. Maintaining parallel content across product-specific instances of a third-party DAP would have created exactly the fragmentation problem we were trying to eliminate.
There was also the data question. Our DAP needed to surface guidance that was informed by real case data, telemetry, and product-specific context. That required deep integration with Cisco’s internal systems, the kind of integration that’s possible with third-party platforms but requires significant customization that often creates maintenance debt.
The sovereignty calculation
The decision came down to a principle I’ve applied throughout my career: buying gives speed; building gives sovereignty.
A third-party DAP would have been faster to deploy initially. But every customization, every integration, every scale decision would have been negotiated with a vendor. Every new product onboarding would have been constrained by the platform’s architecture. Every compliance requirement would have been filtered through someone else’s roadmap.
Building gave us slower initial deployment but complete control over the architecture. We could design the content model to match Cisco’s knowledge taxonomy. We could integrate directly with case data and telemetry. We could deploy across products without per-seat licensing constraints that don’t scale to 170,000 users.
What we learned
The build decision was right for us. It wouldn’t be right for everyone.
The framework I’d use: if your organization is a single product with standard compliance needs, buy. The time-to-value advantage of a mature platform is real and significant. Don’t build what you can buy.
But if your organization is a multi-product ecosystem with complex compliance requirements and a need for deep integration with internal data, the kind of environment where “customize” starts looking like “rebuild”, the sovereignty of building may be worth the slower start.
The deeper lesson wasn’t about build versus buy. It was about what a DAP actually is. We walked into the evaluation thinking we were buying a tool. We came out understanding that digital adoption isn’t a tool at all; it’s a discipline you embed across your organization. The technology is a delivery mechanism. The hard work is capturing institutional knowledge, structuring it for reuse, and maintaining it as products evolve.
No vendor can do that for you. Whether you build or buy the delivery platform, the discipline is yours to create.
