Product Adoption Assistant
Building an AI tool TSMs actually want to use
Problem
Technical Success Managers were losing hours every week searching across Confluence, help documentation, knowledge articles, Jira, Salesforce, and Google Drive to answer routine account questions. Finding the information was only half the problem. Existing playbooks were static, forcing TSMs to diagnose each adoption, deployment, or risk issue themselves, locate the right sequence of plays, and execute every step manually.
Context
Two FY26 business objectives defined the opportunity: reduce undeployed ARR and increase adoption across Zscaler’s core products. Leadership had established the outcomes but had not defined the solution.
I connected those objectives with insights from the broader Post-Sales transformation. The organization needed more than better enterprise search. It needed an AI product that could unify fragmented knowledge, understand account problems, and dynamically assemble the right playbook for each situation.
The resulting three-phase vision moved from unified knowledge and dynamic playbooks, to agentic execution with humans in the loop, and ultimately to proactive digital success for accounts without assigned TSMs.
I connected those objectives with insights from the broader Post-Sales transformation. The organization needed more than better enterprise search. It needed an AI product that could unify fragmented knowledge, understand account problems, and dynamically assemble the right playbook for each situation.
The resulting three-phase vision moved from unified knowledge and dynamic playbooks, to agentic execution with humans in the loop, and ultimately to proactive digital success for accounts without assigned TSMs.
My Role
As Director of Business Systems Product Management, I conceived Product Adoption Assistant, defined its product vision and three-phase roadmap, and led the program from discovery through launch. I owned the strategy, validation approach, cross-functional alignment, and critical decisions to pause, rearchitect, and resume the product.
Strategy & Process
- 1Work Backward from the BusinessStarted with the adoption and undeployed-ARR objectives rather than an available AI technology, then translated insights from the Post-Sales transformation into a product vision for dynamic, AI-assisted playbooks.
- 2Use Real Questions, Not AI DemosEvaluated the opportunity using open-ended adoption, configuration, and playbook questions drawn from real customer and account scenarios, exposing weaknesses that polished demonstrations and simple retrieval tests would have missed.
- 3Move Beyond SearchTested whether federated search could solve the problem and found that retrieval worked only when TSMs already knew what they needed. Defined Product Adoption Assistant as a dynamic guidance product capable of diagnosing account problems and assembling the correct play automatically, rather than as another enterprise search interface.
- 3Design the Product in PhasesDefined a roadmap that moved from unified knowledge and dynamically assembled playbooks, to agentic playbook execution with human oversight, and eventually to proactive account support for customers without assigned TSMs.
- 3Curate the KnowledgeApplied lessons from Agent Z by narrowing and cleaning the source corpus, removing ambiguity and improving the authority of the knowledge available to the assistant.
- 3Validate with HumansTested real customer and account scenarios with business users and TSMs. A panel of CSE subject-matter experts graded whether the product’s answers and recommended plays were correct.
- 3Treat Failure as EvidenceUsed four unsuccessful validation rounds to isolate the problem instead of repeatedly tuning prompts. The consistent 40% to 50% task-success range showed that content cleanup alone was not reaching the model effectively.
- 4Diagnose the ArchitectureDetermined that the curated content was being constrained by the secondary AI framework’s ingestion layer. Prompting and corpus improvements alone could not solve the problem.
Key Decisions
- 1Protect Trust Before SchedulePaused the program for two weeks under direct executive pressure to launch. Shipping inaccurate guidance risked damaging TSM trust and customer outcomes, while pausing created the possibility that scarce AI Engineering capacity might never return.
- 2Continue Through the RiskCame close to canceling the program but chose to proceed after the pause. A low-accuracy launch could have destroyed adoption, but abandoning the product would have left the underlying business problems unresolved.
- 2Rearchitect the Knowledge LayerSecured engineering capacity for purpose-built connectors to Confluence, Jira, and the playbook repository rather than accepting the secondary framework’s ingestion limitations as permanent.
- 3Keep Humans in the LoopDesigned the agentic roadmap to automate appropriate parts of each playbook while preserving TSM judgment for customer-sensitive decisions, balancing efficiency with accountability.
Impact
- 1Accuracy RecoveredImproved human-scored task success from approximately 40% to 50% across four failed testing rounds to 95% in the fifth round after implementing the connector strategy. Task success measured both correct answers and correct play recommendations against real customer scenarios.
- 1Strong Early AdoptionReached 70% quarterly active adoption across all 580 eligible TSMs during the first quarter, representing approximately 406 active users.
- 1Time ReturnedSaved approximately five hours per week for each active user through unified knowledge access and dynamically assembled playbooks.
- 2Product Adoption IncreasedProduced a 12% relative increase in adoption across the measured core products.
- 2Undeployed ARR ImprovedReduced undeployed ARR 5%, exceeding the original 3% business objective.
- 3The Product ExpandedProgressed from knowledge unification and dynamic playbooks into agentic execution, while establishing the foundation for proactive digital success across accounts without assigned TSMs.
Lessons Learned
Clean content is necessary for AI accuracy, but corpus curation cannot overcome an architecture that cannot ingest and use that content correctly. The eventual breakthrough required purpose-built connectors, access to authoritative sources, and real engineering ownership.
The experience also reinforced that trust is an AI product requirement, not a change-management activity that begins after launch. Pausing under executive pressure created political and capacity risk, but shipping inaccurate customer guidance would have created a more permanent failure. Protecting trust was ultimately what made strong adoption possible.
The experience also reinforced that trust is an AI product requirement, not a change-management activity that begins after launch. Pausing under executive pressure created political and capacity risk, but shipping inaccurate customer guidance would have created a more permanent failure. Protecting trust was ultimately what made strong adoption possible.
