You just found out you own Pendo now, and nobody left a manual. That’s the objection I hear every time someone lands this job: I don’t know where to start, and I’m worried I’ll miss something important that breaks later. Inheriting Pendo usually means inheriting three or four years of decisions nobody wrote down, half-finished guides, and a dashboard someone built for a meeting that stopped happening in 2023.
Here’s the thing worth knowing up front: most of what’s already in your Pendo instance is fine. It doesn’t need a rebuild. It needs someone to read it, name who’s responsible for what, and put a light rule around what happens next. That’s the whole job for the first 90 days.
Before you touch a single setting, a few ground rules:
Log in and just look, for real, before you change anything. Open every dashboard. Click through the guides that are live. Check which reports have actually been viewed in the last 90 days versus which ones exist because someone built them once and forgot. (You’ll usually find at least one dashboard nobody has opened since it was made. That’s normal, not a crisis.)
Pendo’s own dashboard guidance is a decent checklist for this pass: what’s the dashboard for, who’s it for, is it still answering that question. Use it as a filter, not a to-do list.
Self-check: if you had to explain to your CEO in one sentence what this Pendo instance is currently used for, could you?
Every inherited system has ghost owners, people who set something up and then changed roles, left the team, or just stopped looking. Product usually owns the guides. Customer success usually wants the account health data. Someone in leadership probably asked for a report once and never checked on it again.
Go talk to each of them. Not an email, an actual 20-minute conversation. Ask what they expect Pendo to tell them and how often they look at it. You’ll learn more about what’s broken from five short conversations than from a week alone in the settings menu.
Self-check: for each dashboard or guide you found in step one, can you name a person who’d notice if it disappeared?
Now go back through what you found in step one, this time with the stakeholder context from step two. Pendo’s account reports article is worth reading here if account health tracking is part of what you inherited, since it explains what the platform can actually roll up versus what needs to be built by hand.
Look for feedback loops specifically: is there a place ideas and requests get logged, and does anyone act on what lands there? A feedback queue with nobody assigned to it is worse than no queue at all, because it tells your team you’re listening when you’re not.
Self-check: if a customer submitted feedback through Pendo today, who would see it, and by when?
This is the step people skip, and it’s the one that saves you the most pain later. Governance sounds heavier than it is. It’s really just three answers written down somewhere everyone can find them: who can create new dashboards and guides, who approves what gets tracked, and how often the whole setup gets reviewed.
We’ve written before about what Pendo governance actually looks like for a small team, and the short version holds here too: you don’t need a committee, you need one owner and a quarterly 30-minute check-in on the calendar.
If I’m honest, the mistake I see most often (and made myself early on) is treating governance as a document instead of a habit. A page in Notion nobody opens isn’t governance, it’s decoration.
Self-check: right now, if two people wanted to build competing dashboards for the same metric, is there a rule that stops that?
Once you know what exists, who owns it, and what the rules are, write down three things you’ll actually do in the next 90 days. Not everything you could do, just three. Fix the one broken feedback loop. Retire the two dashboards nobody uses. Set up one report the CS team actually asked for.
This is close to the same shape our Pendo admin setup guide for the first 90 days walks through, and it’s worth reading alongside this one if you’re doing this cold. A roadmap with three items gets done. A roadmap with fifteen items becomes the thing you feel guilty about every Monday.
Inheriting a tool is a lot like buying a house from an estate sale: the furniture’s already arranged, some of it’s genuinely good, and the fastest way to ruin the place is to renovate before you’ve lived in it a month.
Pendo pays off when the system around it works, not when one more person learns one more feature.
Give yourself two to three weeks to observe and talk to stakeholders before you change or delete anything. Small, reversible cleanup (archiving obviously dead dashboards) is fine sooner.
That’s common, not a dealbreaker. Treat step one and two as your documentation project. What you learn by asking becomes the record that should have existed already.
Almost never. Most inherited instances need pruning and ownership, not a rebuild. Save a full rebuild for cases where the data itself is untrustworthy, which is rare.
Try one thing this week: pick the single dashboard in your Pendo instance with the most views and find the one person who relies on it most. Ask them what it’s missing. That conversation will tell you more about your first 90 days than anything in the settings menu.
If you want help mapping the rest of it, book a strategy call and we map your first 90 days with you.