Not one of the three case studies—this is the receipt behind a belief on my [about page →]: help docs should be optional, and I know exactly what they're for.
Events looked like a basic concept internally—so basic that nobody agreed on what the word meant. Engineering called them "countables." Product leadership insisted everything was an "event." And the UI, it turned out, had already shipped a third term—"Product Elements"—based on user research others had forgotten or wasn’t aware of.
When I asked in a public channel—three months into the job, though I'd used Pendo for years as a customer—what we collectively call pages, features, and track events, the thread pulled in product, customer success, professional services, technical account management, and technical support—five teams, five competing answers—and ended with a product management director offering to put a meeting on my calendar to explain "why this has to be 'event.'”
The thread that made the article necessary—29 replies about one word, ending with a director offering a meeting to explain why it "has to be 'event.'”
Meanwhile, "events" was spreading through the UI and our help content either way. Whatever the internal debate decided, customers needed one clear, public answer to what is an event in Pendo, and no article existed at all. This was net-new: I set out to write the first one, and to make it the definition everyone could point to.
This looked like a simple "explain a concept" article. It wasn't—because the concept meant something different depending on who you asked, and I'd already watched that play out internally.
To calibrate, I deliberately reached out to four SMEs in different customer-facing roles and asked the same three questions: how do you explain events to customers, what confuses them most, and what should this article cover.
So the real problem wasn't "explain events." It was reconciling four legitimate but incompatible views of what the article was even for—a conceptual model, a security FAQ, a technical reference, and a troubleshooting guide—for a term the company itself was still debating about.
I didn't take the advice to narrow scope. The live article → covers raw events, Page and Feature tagging, Track Events, and event properties in one piece, with the raw-events security angle integrated rather than split out.
That was a real tradeoff, not a default: a narrower article would've been faster to ship and easier to keep accurate, but it would've reproduced the same fragmentation I was trying to fix. I chose completeness over speed because the goal was one article that orients anyone, regardless of which door they came in through.