Zscaler Product Organization Design
Standing up a product org from zero, then making it deliver at scale
Problem
Zscaler’s Post-Sales organization had no formal product or business-systems function. Product work supporting Customer Success and the broader Post-Sales organization was scattered across Operations, Business Capabilities, BI, automation teams, and technology partners, with no single organization accountable for delivery from discovery through launch.
The operating practices were equally fragmented. User feedback and requests were not captured consistently, intake and triage were slow, roadmap progress was difficult for stakeholders to follow, and a cumbersome handoff to support routinely created missed SLAs downstream.
Recurring ceremonies had accumulated without being evaluated for value. Backlog grooming and retrospectives did not exist, and planning for the next quarter often began only two weeks before the quarter started. The organization was reacting to demand rather than operating from a product strategy.
Context
I began the transformation in Q3 FY25 and established the full organization by Q4 FY25. From an approximately 40-person Operations organization, I selected and transitioned six employees into product roles and hired four additional team members.
At full strength, I directly led ten people across five Product Managers, two Designers, two Project Managers, and one Prompt Engineer, creating an eleven-person organization including me.
This was not simply a process improvement initiative. I needed to design the organizational structure, define the operating model, establish PM types and scopes, create job families and leveling expectations, assign direct and matrix relationships, develop existing talent, hire missing capabilities, and clarify ownership across Product, Design, Business Capabilities, Enablement, BI, IT, and Engineering.
At the same time, the new organization needed to build and operate the product lifecycle it had been created to own.
At full strength, I directly led ten people across five Product Managers, two Designers, two Project Managers, and one Prompt Engineer, creating an eleven-person organization including me.
This was not simply a process improvement initiative. I needed to design the organizational structure, define the operating model, establish PM types and scopes, create job families and leveling expectations, assign direct and matrix relationships, develop existing talent, hire missing capabilities, and clarify ownership across Product, Design, Business Capabilities, Enablement, BI, IT, and Engineering.
At the same time, the new organization needed to build and operate the product lifecycle it had been created to own.
My Role
As Director of Business Systems Product Management, I designed and built Zscaler’s first product-first organization supporting Post-Sales. I owned its organizational design, talent strategy, operating model, product practices, delivery performance, and outcomes. Design reported directly to me, while Business Capabilities, Enablement, BI, IT, and Engineering operated as matrixed partners.
Strategy & Process
- 1Build the Function, Not Just the ProcessCreated a formal product organization with clearly defined roles, responsibilities, scopes, reporting relationships, and ownership boundaries rather than layering new ceremonies onto the existing fragmented model.
- 2Develop and Hire DeliberatelyTransitioned six people from Operations into product roles, upskilled existing talent, and hired four additional team members to complete the required product, design, project-management, and AI capabilities.
- 3Start Discovery Before the BacklogCreated a user-first discovery process so ideas were validated against employee and business needs before becoming committed work.
- 3Redesign Intake and TriageReorganized how tickets, bugs, and enhancement requests were submitted, evaluated, routed, prioritized, and tracked, addressing a cumbersome support pipeline that contributed to missed SLAs.
- 3Create a Predictable Operating RhythmRebuilt quarterly planning around a T-minus-eight-week cadence and established weekly steering, biweekly advisory, and monthly governance forums, replacing just-in-time planning with shared roadmap visibility, recurring feedback, and decision accountability.
- 3Protect Platform HealthEstablished a formal planning policy that consistently reserved 15% to 20% of Product and Engineering sprint capacity for technical debt, production defects, and critical enhancements.
- 4Rebuild Quality PracticesOverhauled QA, UAT, usability testing, and end-user validation so releases were evaluated against real employee needs before reaching production.
Key Decisions
- 1Build a True Product OrganizationConsolidated accountability within a dedicated product function rather than leaving ownership fragmented across Operations, Business Capabilities, BI, and automation teams. Combined internal mobility with selective hiring to preserve domain expertise while adding missing product capabilities.
- 2Bring Design Into the OrganizationMade Design a direct part of the product function so research, experience strategy, and interaction design could shape decisions throughout the lifecycle rather than entering after requirements were fixed.
- 2Fix the Operating Rhythm FirstEstablished the planning cadence, governance model, and ceremony structure before enforcing new delivery and SLA expectations, giving teams a stable system within which accountability could work.
- 3Reserve Capacity for Product HealthProtected 15% to 20% of sprint capacity from feature demand, accepting lower theoretical feature velocity in exchange for a healthier platform and sustainable backlog.
Impact
- 1An Eleven-Person Product Organization Was EstablishedBuilt the first formal product organization supporting Zscaler Post-Sales, consisting at full strength of ten direct reports plus me across Product Management, Design, Project Management, and Prompt Engineering, and delivered the reported performance improvements within the first two quarters.
- 2Cycle Time Fell 30%Reduced elapsed delivery time across enhancement requests, bug fixes, and strategic products and projects, based on Asana and Jira reporting.
- 2Commitment Reliability Reached 90%Increased on-time delivery from 40% to 90%, measured by whether launches met the dates communicated to the business.
- 2Release Quality ImprovedReduced production defects and overall bugs 60% per release and quarter while decreasing post-launch enhancement requests 30%, as stronger discovery, requirements, QA, UAT, and end-user testing produced releases that more closely matched employee needs.
- 3Completed Work Increased 40%Increased completed bug fixes and enhancements through stronger planning, discovery, prioritization, and throughput management while keeping the backlog nearly current.
Lessons Learned
Building an organization while simultaneously designing its operating model created a different challenge than optimizing an established product function. There was no mature process to fall back on, and the roles, relationships, planning cadence, governance system, quality standards, and product lifecycle all had to be established while the organization continued delivering. The transformation reinforced that operating practices cannot compensate for unclear ownership. The largest improvement came from creating one product organization accountable for the complete lifecycle, then defining how direct teams and matrixed partners contributed without blurring responsibility.
The transformation also demonstrated that speed and platform health are not opposing goals. Reserving capacity for defects, technical debt, and critical enhancements reduced theoretical room for feature work, but the resulting improvements in quality, predictability, and backlog health increased the amount of valuable work the organization could actually complete.
The organization did not improve because it moved faster at every step. It improved because it became deliberate about what it built, when it committed, how it validated, and who was accountable.
The transformation also demonstrated that speed and platform health are not opposing goals. Reserving capacity for defects, technical debt, and critical enhancements reduced theoretical room for feature work, but the resulting improvements in quality, predictability, and backlog health increased the amount of valuable work the organization could actually complete.
The organization did not improve because it moved faster at every step. It improved because it became deliberate about what it built, when it committed, how it validated, and who was accountable.
