A few years ago I sat in an interview for a new team. I asked what success looked like in the role, what we were targeting, and how progress got measured. The answer did not come directly. After a bit of back and forth, the question came back to me instead: what would you do in your first month.
I understood where that was coming from. Leaders want to hear a plan. But if I had answered with a list of things I would change, that answer would have been wrong, even if some of those changes turned out to be right later. You cannot know what to change before you know why things are the way they are.
So instead I said something closer to the truth. I would start by looking at the current backlog, the technical debt, and how the team was actually working day to day. My first real target would not be a new initiative. It would be clearing the lingering items already sitting in the queue, the ones that had been deprioritized meeting after meeting for reasons nobody had written down.
A product built over years carries decisions, tradeoffs, and history that are invisible from the outside. Touching the roadmap before you understand why it looks the way it does means inheriting someone else’s mistakes and adding your own on top.
The first 30 days are not for building. They are for finding out what you actually inherited.
Why the roadmap is the last thing to touch
A messy roadmap is often not the real problem. It is a symptom of something upstream: unclear metrics, a broken feedback loop, a team without trust, or a business model nobody has re-validated in two years.
If you change the roadmap in week one, you are optimizing a symptom. Three months later you will be back at the same table explaining why the new plan also is not working.
Clearing the lingering backlog first, the way I described in that interview, does two things at once. It gives the team a fast, visible win without requiring you to have all the answers yet. And it forces you to touch every corner of the existing system, which is the audit itself, just disguised as delivery.
Week 1: audit the numbers before you audit anything else
Start with what the product actually does, not what people say it does.
Pull the core metrics: activation, retention, churn, revenue per account, and support ticket volume. Do not rely on a dashboard someone built two years ago. Check whether the numbers still mean what they claim to mean. A lot of inherited dashboards track vanity signals that stopped mattering once the business model shifted.
Ask three questions of every metric you find:
- Who set this target, and when
- Has it been re-validated since
- Does anyone currently in the building actually look at it weekly
Churn and retention tell you more about product health than almost anything else. If churn is high and nobody has a clear theory why, that is your first real finding, not a footnote.
Week 2: audit the team and the backlog before you audit the code
A messy product is rarely a technology problem alone. It is usually a trust problem that shows up as technical debt and a backlog full of items nobody has the authority or appetite to close.
This is where I start in practice. Go through the current backlog line by line with the team. Some items are still real. Many are leftover asks from a stakeholder who has moved on, or half-finished work paused for a reason nobody remembers. Clearing that backlog is not busywork. It is a direct read on how decisions have been made here, and it earns trust with a team that has likely seen leadership churn before. If your delivery process only works when one specific person is in the room, that is itself a finding worth writing down, and it is something I have written about separately.
A widely used model of team dysfunction is worth applying directly. Sit with engineering, design, and support separately before you sit with them together. Look for absence of trust, avoidance of conflict, and lack of accountability. Teams that have been burned by previous leadership tend to go quiet in meetings and loud in private. That gap is information.
Your first 30 days are highest leverage when spent listening, not deciding. One good one-on-one with a skeptical engineer will tell you more about the real state of the product than a week of documentation review.
Ask everyone the same question: what would you fix first if nobody could say no to you. The pattern in the answers matters more than any single answer.
Week 3: audit the customer signal, not the customer opinion
Every inherited product has a story about what customers want. Usually it is half true and half internal assumption dressed up as insight.
The Jobs to Be Done framework helps separate the two. Instead of asking what feature customers requested, find out what job they were trying to get done when they came looking for this product. Pull support tickets, churn interviews, and sales call notes if they exist. Look for the job customers are hiring the product for, and compare it against what the roadmap has actually been building. If nobody on the team has run this kind of discovery before, it is worth starting from the basics, which I cover in a separate primer on product discovery for non-product founders.
This is also where you find out if the product has drifted. A common pattern in inherited products is a roadmap shaped by whoever asked loudest internally, disconnected from what users actually need. If that pattern shows up, name it plainly in your findings. It is a common failure mode, not a rare one.
Week 4: audit the roadmap history and the politics around it
Only now do you look at the roadmap itself, and even then, you are auditing its history, not writing a new one yet.
Go back twelve to eighteen months. For every major initiative, find out three things: what problem it was meant to solve, what actually shipped, and what happened to the metric it was supposed to move. You will usually find a gap between intention and outcome. That gap is the real story of the product.
Ask whether a product vision exists at all, whether anyone outside leadership could repeat it, and whether the current roadmap traces back to it or has quietly become a list of stakeholder requests. This is also where stakeholder noise tends to surface most clearly, something I have written about in more depth here.
This is also where you map the politics. Every inherited product has a person or two whose opinion has outsized weight, regardless of title. Find out who they are early. You will need them later, and ignoring them now creates friction you do not need.
What not to do during these 30 days
- Do not promise fixes in week one. Teams that have survived a leadership change are watching closely for signs you are repeating the last person’s mistakes, and an early promise you cannot keep costs you credibility fast.
- Do not skip the audit if the business is in a genuine crisis. If the company is burning cash with weeks of runway left, a full 30 day audit is a luxury you cannot afford. In that case, compress the process to the numbers and the team, and move faster on both. This is also where it helps to know whether you have inherited a product problem or something closer to a distribution problem, a distinction worth checking early if growth, not just product health, is the concern founders and boards raise, as covered in this related piece.
- Do not audit in isolation. Share what you are finding as you go, even in rough form. A board or an executive team that hears nothing for 30 days will assume the worst, and being transparent about what you are finding builds more trust during this period than a polished report at the end.
Closing the audit
By day 30 you should be able to answer four questions clearly: what is actually broken, why it broke, who has the context to help fix it, and what the smallest first move is that will build trust while you plan the larger changes.
Going back to that interview, I think the answer that would have sounded most confident, a list of changes on day one, would also have been the least trustworthy answer in the room. What actually built trust was saying I did not know yet, and explaining exactly how I would find out.
The roadmap comes after all of this, not before. What have you found in your own experience taking over a product that surprised you more than expected?
If you are a founder or board member evaluating whether your product needs an outside audit before your next planning cycle, you can reach out here.
Tahir Shahzad
Tahir Shahzad is a Product Manager, Product Owner, and technology consultant with over a decade of experience helping startups and organizations build products people actually use. If you are working on a product problem worth solving, reach him at tahirshahzad.com/contact/
