| Technical Writer | AI-Powered Documentation & Product Education |
I build documentation systems and learning programs that accelerate product adoption for SaaS and analytics platforms. This page explains how I work, what I believe, and how I approach complex documentation challenges.
I specialize in creating AI-powered documentation strategies, implementing Jobs-to-be-Done (JTBD) methodology, and building scalable learning programs for technical products.
Currently: Technical Writer at Red Hat, documenting enterprise analytics products for the Critical Response Team.
Previously: Led digital adoption initiatives, built in-app training programs, and implemented AI-augmented documentation workflows at enterprise SaaS companies.
Core focus areas:
Most technical writers organize content around features. I organize it around user goals.
Why? Users don’t read documentation to learn about features. They read it to complete a job. When documentation mirrors user workflow instead of product architecture, adoption increases and support dependency decreases.
Example: Instead of documenting “Database Configuration” as a feature section, I document “Setting up your first production database” as a user goal. The content might be similar, but the framing makes it immediately actionable.
This is why I advocate for Jobs-to-be-Done (JTBD) methodology in technical documentation.
AI is augmentation, not replacement.
I build custom tools to eliminate documentation toil so I can focus on strategy. Claude skills for content quality analysis and JTBD automation. Custom Gemini Gems for release notes review and workflow standardization. NotebookLM for content analysis and gap identification.
AI makes me more effective, not redundant. It handles the repetitive work while I focus on understanding users, structuring information, and collaborating with product teams.
Jobs-to-be-Done is a framework for organizing documentation around what users are trying to accomplish, rather than what features exist in the product.
Traditional approach: “Here’s how Feature X works.”
JTBD approach: “Here’s how to accomplish Goal Y,” which may involve multiple features.
When Red Hat decided to adopt JTBD organization-wide, I saw an opportunity to not just implement it manually, but to build AI-powered tools that could scale the approach across multiple products.
Here’s how I’m approaching it:
First, I analyze Adobe Analytics to see what users search for and where they struggle. I review support tickets to identify recurring user goals. I interview developers and customer success teams to understand real-world workflows.
Then I built custom AI tools to do the heavy lifting. I created a crawling script to gather existing content. I use Claude and Gemini to analyze that content and generate job statements at scale. The AI maps features to user goals, identifying jobs that require multiple features or cross-product workflows.
Right now, I have the raw material ready. Job statements extracted. Content analyzed. Consolidation opportunities identified.
The next phase is restructuring the documentation itself. Reorganizing it around user journeys instead of product capabilities. Creating clear entry points for different user personas. Building the JTBD-oriented information architecture.
Then comes measurement. I’ll track bounce rates, time-on-page, and support ticket trends. Iterate based on what users actually use, not what we think they need.
In the age of AI and chatbots, finding answers is easy. Users can ask ChatGPT or an AI assistant for quick facts. But getting the right answer at the right time, in the context of their actual workflow? That’s where JTBD-structured documentation makes the difference.
Red Hat adopted JTBD because documentation structured around user goals reduces time-to-value. Users find what they need faster. It decreases support dependency because documentation maps to real workflows. It improves product adoption because users succeed faster and trust the product more.
What I’m doing differently is building AI-powered tools to scale the methodology. Instead of manual analysis taking weeks, the groundwork happens in hours. That frees me to focus on the strategic work: understanding user needs, designing the information architecture, and validating the restructured content with real users.
At Red Hat, there was a rigorous exercise around content quality analysis. Everyone was spending hours on manual reviews, using their own tools and approaches. The process was inconsistent and time-consuming.
I saw an opportunity.
I started experimenting with AI to automate the quality checks. First, I tried NotebookLM, but it wasn’t precise enough for the kind of detailed analysis we needed. Then I discovered I could build custom Claude skills that would not just flag issues but explain why something failed quality standards.
So I built one.
The skill automates the repetitive quality checks. It looks for structural issues like procedures without context or missing prerequisite information. It catches language problems like passive voice that obscures responsibility or undefined jargon. It identifies user experience issues like cognitive overload or missing error handling.
But here’s what makes it useful: it doesn’t just say “this is wrong.” It explains why it matters and how to fix it. That turns it into a learning tool for writers, not just an automated checker.
When my peers saw it working, they started using it too. What used to take hours of manual review now happens in minutes. And the quality checks are consistent across the team.
The real impact? We freed up time to focus on strategic work like understanding user needs and improving information architecture, instead of spending hours hunting for style inconsistencies.
Documentation is reactive. Training is proactive.
Users read documentation when they’re stuck. They engage with training when they want to get better. Both are necessary, but they serve different jobs.
When I was at Odessa, I was still relatively new to technical writing. I was learning on the job, figuring things out as I went. I noticed something: we had comprehensive documentation, but users still struggled with onboarding.
Odessa was planning to implement Whatfix, a digital adoption platform that provides in-app guidance. What I loved about the approach was how it simplified the user journey by meeting users where they are. Not in a separate help portal, not in a PDF, but inside the product itself.
I learned it from scratch and took the lead on the initiative. I worked across Engineering, Product, Support, and executive teams to design interactive onboarding flows, product walkthroughs, and in-app training content for different user personas.
The result? Onboarding-related support tickets dropped 30% within three months.
I learn whatever is needed to solve the problem in front of me.
When Git-based workflows became essential, I learned version control and docs-as-code practices. When I wanted to automate documentation tasks, I learned Claude and built custom skills for content quality analysis and JTBD automation. When Red Hat adopted JTBD methodology, I learned the framework, implemented it, then built AI tools to scale it. When Odessa needed to implement digital adoption, I learned Whatfix from scratch and led the cross-functional initiative. When I needed to measure content effectiveness, I learned Adobe Analytics and data-driven content improvement.
I experiment constantly. NotebookLM for analysis. Gemini custom Gems for workflow automation. Claude for task automation.
I treat experimentation as part of the job: hypothesize, test, measure, learn, iterate.
Email: shivaniwaikar25@gmail.com
LinkedIn: linkedin.com/in/shivani-waikar
GitHub: github.com/shivanisathe25
Featured Interview: Tech Writer’s Tribe - Interviewing the Leader
Last updated: May 2026