Product work, explained through the decisions

The problem

As companies began putting more AI workloads and tools into everyday use, customers raised new questions about securing traffic, branches, and access to those tools. The work was to understand which concerns would last and what they meant for an existing routing and SD-WAN portfolio.

What I did

I brought together customer conversations, field feedback, market research, and technical input from security and engineering teams. I used that evidence to help prioritize product work and explain how the portfolio could support safer AI adoption.

How I approached it

• Turned broad AI security language into specific customer scenarios and risks.
• Worked with technical teams to connect those scenarios to product capabilities and roadmap choices.
• Helped customer-facing teams explain the work in terms of risk and modernization, not only features.

The problem

Two product lines serve customers with different operating models, but many of those customers need similar routing capabilities across both. Internal product boundaries should not force customers to solve the same problem twice.

What I do

I coordinate product work across teams to identify which capabilities should be shared, how they should appear in each experience, and where differences are intentional. My role is to keep customer needs ahead of organizational and product boundaries.

How I approach it

• Compare requirements by customer segment and the job the customer is trying to complete.
• Work through architecture, ownership, and delivery dependencies with the relevant product and engineering teams.
• Give customer-facing teams a clearer explanation of what is common and what remains different.

The problem

Cloud, edge, and AI infrastructure were creating new deployment patterns for virtual routing. The product question was which uses were real enough to influence the next generation of the platform and how customers would want to deploy and buy it.

What I did

I contributed to market analysis and launch planning for the next generation of the Catalyst 8000V platform. I translated emerging use cases into requirements, form-factor considerations, packaging questions, and input for the go-to-market plan.

How I approached it

• Compared emerging use cases by customer problem, deployment environment, and willingness to change.
• Mapped those needs to performance, scale, cloud availability, and consumption choices.
• Worked with technical and go-to-market teams to test where the existing platform fit and where it needed to change.

The problem

Generative and agentic AI created many possible product ideas at once. Customers still needed clear jobs to be done, useful safeguards, and a practical reason to change how they operate their networks.

What I do

I help turn that broad opportunity into specific product questions: which workflows are worth improving, what the system can safely do, what should remain under human control, and how the value should be measured.

How I approach it

• Separate three areas: infrastructure for AI workloads, security for AI activity, and AI-assisted operational work.
• Evaluate explainability, governance, and adoption needs alongside technical feasibility.
• Use prototypes and product discovery to test assumptions before treating them as roadmap commitments.

What I did

I managed business systems, operated high-availability environments, supported complex software, advised enterprise customers, and led technical teams before moving into product management.

What it taught me

• Product decisions have operational consequences for real people.
• Software, infrastructure, process, and incentives usually need to be considered together.
• Adoption, supportability, and operating cost are product requirements, not follow-up tasks.
• Trust is earned by understanding the details and making complexity easier to work with.