The Audit: Why Every Product Person Must Look Before They Leap

Starting a new product role is a lot like buying a house.

On the surface, everything looks solid. The kitchen is updated, and the layout works. The neighborhood checks out. You can picture yourself settling in with a glass of wine and watching the sunset from the back porch.

Then the inspection happens and you learn the wiring hasn't been touched in years. The foundation has shifted just enough to matter. Some of the fixes were done quickly, not thoughtfully.

Product organizations tend to reveal themselves in the same way. Whether you're a leader taking over the product org at a new company or a PM moving to a new division of your current one, there will be surprises.

You step in, review the roadmap, meet the team, and start connecting the dots. A roadmap labeled "Q2" turns out to be from a previous year. The design system lives partly in Figma and partly in Slack threads. Onboarding is owned by … well, it depends on who you ask. While none of this is unusual, when taken together, it shapes how work actually gets done.

A quick but thorough product audit is your 'house inspection.' This article outlines how a senior product leader should audit an organization they've recently joined. That said, the ideas can also be used by any product person considering a move to a new division or company. While you won't be able to conduct lengthy workshops during an interview process, you can ask the same probing questions to assess how product-forward the organization is.

The New Person Problem

Suggesting a full-scale audit in your first week on the job feels intrusive. You've just walked through the door, and you're already asking to see the utility closet. It's easy to worry about offending the team or starting off on an adversarial footing.

But usually the opposite happens.

Product teams generally know when they aren't hitting their stride. They've been struggling with shifting priorities or a lack of the right data to do their jobs well. Don't think of an audit as judging someone's work. Think of it as performing an opportunity definition on the company's internal environment. Most of the team will be relieved to finally have a platform to voice the friction points that keep them from their best work. It turns their frustrations into a legitimate plan for improvement. If someone resists, take note. That's usually where a silo is hidden.

What You're Actually Evaluating

Looking at outputs alone: roadmaps, backlogs, velocity charts, doesn't tell you much about how the organization operates. You want to understand the system behind these outputs.

The audit focuses on how work moves from an initial idea to something shipped and supported. This includes how customer needs are understood, how strategy is defined, how ideas are explored, and how decisions are made along the way.

These are the areas my audits typically explore:

• Qualitative Customer Needs: How clearly are we understanding real problems and jobs-to-be-done?
• Quantitative Customer Actions: Do we know what users do, rather than just what they say they do?
• Product Line Strategy: Have we defined a target market and a moat so we aren't just a commodity?
• Strategic Roadmap: Is the team aligned on the next 12–18 months of value?
• Prioritization of Big Bets: Does the organization habitually second-guess big bets every six months?
• Opportunity Definition: Is the problem well understood before solutions are proposed?
• Concepting & Ideation: How are directions explored before narrowing in?
• Requirements & Design: How clearly are ideas translated into something buildable?
• Product Metrics: Are we measuring changes in behavior or just tracking output?
• Experimentation: Do we have a safe space to learn without breaking the main product?
• Whole Product Launch: Can the organization support what's being released?

While most teams can point to pieces of this, variation shows up in how consistently each area is handled, and how connected they are to one another. Gaps tend to appear at the seams between research and roadmap, between design and build, between launch and learning.

How the Audit Actually Happens

The core activity consists of working sessions with the product leadership team, typically spread across a few blocks of time in the first month. If schedules allow, it helps to bring people together in person. Conversations tend to move faster, and you pick up on details that don't always surface over video. It's also a great forcing function for in-person bonding if you're new to the team or company. Either way, the process holds.

For each area, the group works through three questions: what's happening today, what should be happening, and what sits in between. The first part, describing the current state, requires a bit of discipline. It's easy to drift toward how things are supposed to work. The goal here is to stay grounded in how they actually do.

• Where do ideas originate?
• What happens when priorities conflict?
• How often do plans change midstream?

These aren't abstract questions; people will have specific stories and examples.

From there, you sketch a more consistent version of how each area should operate. While you don't necessarily need a perfect system, you do need one that holds up under real conditions and handles similar tasks, similarly, across the organization. The final step is to size the gap and begin identifying what needs to change.

A simplified output might look like this:

And so forth, for each audit category. But with a much higher level of granularity than shown above.

Keep in mind that the spreadsheet itself isn't the end goal. The discussion behind it is where most of the value sits. It's often the first time the group has worked through these topics in a structured way.

The Trap of Trying to Do Too Much

Once the gaps are visible, the list of improvements can grow quickly. This is where prioritization comes in. It's tempting to treat everything as urgent, especially when each item connects to something that hasn't been working well. In practice, spreading attention too thin tends to stall progress. Teams start multiple changes at once, none of them fully take hold, and the organization falls back into familiar patterns.

A more workable approach is to stage the changes. Some improvements have an immediate impact and don't depend on much else. Others require groundwork: new data, new habits, or coordination across teams. Each of these takes longer. I have found that a good portion of the change can happen in the first year, once the initial set of improvements is in place. The rest unfolds more gradually as those changes settle in and expand.

The Transformation Roadmap

The audit results in an organizational transformation roadmap. This isn't your customer roadmap; it's the plan for building a better machine. You have to sequence the changes so you don't break the organization while trying to fix it.

Here's an example, simplified view:

Where Tools Fit In

Process and tools are tangled together. You can't talk about quantitative research without someone bringing up Amplitude or Pendo. The trick is to avoid the tooling trap: the three-hour circular debate about whether Jira is better than Linear. Capture the need in the workshop, but move the specific tool selection to a separate workstream.

When the time comes to discuss tools, your goal is a baseline toolkit that everyone actually uses. Product analytics like Amplitude or Mixpanel provide the quantitative backbone, while experimentation tools like Optimizely or VWO let you validate bets before you go all-in. For research, tools like UserTesting or SurveyMonkey bridge the gap between what you think and what you know. Project management is where things usually spiral. I suggest you worry less about the license fees and worry more about the coordination cost. If three teams are using three different tools, you're paying a "tax" every time you try to look at the overall progress. Simplify and consolidate. Pick a toolset, stick to it, and move on to the actual work.

Assessing Company Orientation

The Process Roadmap fixes the how, but the culture determines whether those fixes stick. In a world of Product-Led Growth, the product is the experience. If you're a product company, product (the thing, not the organization) has to be at the center of the culture.

This requires an honest assessment of six dimensions. Look at Thinking: are we starting with the customer's problem or just a list of features we want to build? Look at Rituals: do our all-hands meetings celebrate sales wins exclusively, or do we celebrate product milestones too? Look at Metrics: is the conversation only about revenue, or are we tracking Customer Benefit Metrics that anticipate future revenue? Look at Decisions: are we moving on "gut feel" from the loudest person in the room, or is there backing data? Consider the Structure: does Product have a seat at the executive table? Finally, Growth: can a user find value and buy the product without human intervention?

I plot these on a northstar chart that spans from where we are today and where we need to be. Closing a massive gap between the current culture and the target requires more than just a new tool or a new meeting. It requires a CEO-led push and constant communication.

Every organization has different starting and target endpoints. That said, I've found that most companies start too far left on many of these vectors. Here's an example for a recent client:

Final Thoughts

The Audit is a 2-4-week litmus test that ends the guessing game. It lets you lead with a clear view of the house you've just moved into. The outcome is a multi-year plan to build an organization that actually ships value.

Don't skip the inspection. Finding out the roof leaks is frustrating. Finding out after the storm hits is a disaster.