Leading with the Principles of the Product Model: How We Navigated a Virtual Switching Crisis at Cisco

I’ve always believed in a principles-based approach to delivering outcomes, long before I had the language to describe it that way. I’ve shied away from complex and onerous processes that threaten to bring rigidity and cognitive overload, rather than clarity. Ironically, it’s this same principle-led mindset that has proven consistently effective in network architecture, product management, technical marketing, and transformation.

Marty Cagan, Teresa Torres, and several others have been vocal champions of a principles-first approach over the past few years. And while the message is gaining traction globally, I’d argue there’s still a long way to go, particularly here in Australia. Every job, every role, every situation has its nuances. I’ve found that rigid frameworks and processes often fail to adapt to situational differences and the variety of unknowns that emerge when working toward an outcome.

One might think or be led to believe that the product model principles are only applicable to the SaaS domain. But that’s not true—the principles have a more universal application in delivering successful product and service outcomes beyond SaaS. It’s an exercise in critical thinking around a product or service outcome.

Turning Back the Clock

Let me provide an example from my time leading product management for virtual switching at Cisco in San Jose around ten years ago.

However, first, let’s rewind to 2008, when I led the vSphere platform technical marketing team at VMware in Palo Alto. My team was responsible for the networking, storage, security, and high availability aspects of VMware Infrastructure, which would soon evolve into vSphere. At the time, VMware had a strong partnership with Cisco. It was mutually beneficial. Cisco’s ‘trusted advisor stamp’ was essential in data centre environments. Network engineers would follow Cisco’s guidance and best practices religiously. Without Cisco’s blessing, network engineers would refuse to trunk VLANs from edge switches to virtualised servers. The compute folks would compensate by buying servers with a multitude of 1Gbps NICs, not the most efficient solution, but all they could do. This impasse limited VMware's growth. 

So VMware developed virtual switching APIs in the ESX kernel exclusively for Cisco, and Cisco developed a virtual switch (Nexus1000V). They co-developed and co-published best practices, endorsing the trunking of VLANs into servers, thereby removing one of the barriers to VMware's growth. In return, Cisco cemented its position as the default connectivity partner. Later on, the Cisco AVS virtual switch was developed as part of the premier Cisco ACI data centre solution.

But by 2012, Cisco's and VMware’s relationship started to shift. VMware had acquired Nicira—the leading SDN company at the time—for $1.2B, and with that acquisition came VMware’s networking solution: NSX.

Fast-forward to 2017. I was back at Cisco and responsible for several data centre products, including their virtual switching portfolio. VMware NSX had matured significantly and was ready to scale. In an early 2017 blog post (if my memory serves me correctly), VMware announced that it would deprecate and eventually remove the virtual switching APIs that Cisco’s solutions relied on. The clock was ticking. Their strategy was clear: migrate customers to NSX. And knowing the VMware folks well, I might have done the same in their position.

But that didn’t diminish the challenge. Cisco had thousands of enterprise and service provider customers globally depending on those APIs via the Nexus 1000V and AVS platforms. The risk of losing them to VMware was real and immediate.

This was a textbook customer retention crisis—and a moment where principles, not processes, made all the difference.

As product lead, I was empowered to tackle the problem, but I knew I couldn’t solve it alone. I assembled a team of senior and distinguished engineers. Our business goal was clear: retain as many customers as possible with a notional target of 80%. We were familiar with our customers and their environments. Our product goal was to deliver a non-API dependent replacement solution that would minimise operational impact in production environments.

Given the high service level objectives in data centres, any change would need to pass rigorous testing. That meant our replacement product had to deliver on performance, observability, and migration simplicity—and it had to ship within 12 months to align with our customers’ virtualisation upgrade cycles. Their long planning cycles meant we had to communicate early and retain their trust, assuming we had a feasible, viable, usable, and valuable solution.

We started by validating some key performance assumptions through a proof-of-concept. We understood it wouldn’t perform as well as the original kernel-based API, but could it meet the “good enough” threshold our customers needed?

At the same time, I published several blog posts on Cisco’s platform. In the first, I called out VMware’s actions as questionable, and assured customers that we had their backs. As development progressed, I shared updates, offering transparency and reinforcing our commitment to minimising disruption.

Our product and engineering teams were co-located, with around 10 engineers per team. We faced a gnarly challenge with a clear outcome, and the engineers leaned in with passion and resolve. Despite more glamorous projects across Cisco, we retained every single team member. We met daily—not as a stand-up ritual, but to solve problems, support each other, and maintain momentum.

At launch, we delivered on time and achieved the outcomes we had set: seamless migration, strong customer satisfaction and trust, and meaningful customer retention.

Aligning with the Principle of the Product Model 

Here’s how our journey aligned with the fundamental principles of the product model:

1. Empowered Product Team. We had a truly empowered team. Product managers and engineers worked together on a complex challenge. While we didn’t require designers for this use case, I worked closely with product marketing and sales to ensure clear and consistent messaging.

2. Product Discovery Before Delivery Within the first week of inheriting the problem, the engineering team validated the feasibility. From day one, we assessed customer value, usability, and overall viability.

3. Continuous and Iterative Delivery From the initial proof-of-concept, we evolved the product iteratively, validating internally against performance and migration readiness criteria.

4. Outcome Over Output Our north stars—customer retention and minimising operational disruption—were crystal clear. They guided our priorities, trade-offs, and decision-making.

5. Product Vision and Strategy Alignment The vision was well-articulated: develop two virtual switching products that operated similarly to their predecessors to minimise customer impact. That clarity enabled the team to focus and maintain purpose.

6. Customer Centricity Success depended on deeply understanding our customers’ needs and pain points. Throughout development, we worked closely with a sample group to ensure we were solving their most critical issues.

7. Collaboration Over Handoffs Product managers and engineers worked side-by-side throughout the project. Marketing and sales stakeholders were kept in the loop from the beginning, not just at launch.

8. Strong Product Leadership I was empowered to lead the initiative and build a team of dedicated product managers and engineers. Co-location enabled continuous coaching, problem-solving, and alignment.

9. Technology as an Enabler We treated technology as a differentiator, not just a tool. By involving senior and distinguished engineers early, we delivered a novel and innovative solution under challenging constraints.

10. Informed, Not Opinion-Based Decisions. Thanks to strong customer relationships, our product managers had a clear insight into what mattered: operational continuity. That insight shaped every decision we made.

Summary

Ultimately, our products succeeded by the standards that matter: delivering the business and product outcomes we set out to achieve. There were no cumbersome rituals, no arbitrary gates—just a shared set of principles and a team aligned around a common goal. Everyone knew their role, and everyone leaned in to deliver.

A principles-based approach provides the dexterity and flexibility to approach different product/service challenges with confidence and purpose while avoiding waste. The principles aren't limited to SaaS, but value creation in any product, service, or transformation situation.