I've spent more than 20 years as a product leader in software organizations, including leading the DevOps portfolio at Idera, a collection of acquired brands with 14 product managers across 9 countries that grew from roughly $100 million to $150 million. Inheriting Product teams that were each built somewhere else teaches you to read a company's structure before you read its strategy.
Sales, marketing, and finance structures deserve their own conversation. The focus here is what the org chart reveals about Product, and what that tells you about the company as a whole.
Think of the strategy deck as the listing photos for a house: staged, perfectly lit, a bowl of lemons on the counter. The org chart is the floor plan.
It won't tell you whether the house is beautiful, but it will tell you whether a planned basement was never built, whether the bathroom started life as a closet, and whether the only way to reach it is from outside. And if a portfolio company can't produce a floor plan at all, that's your first finding.
A strategy can be rewritten in an afternoon, and now with AI assistance it might be rewritten in a few minutes, polished slides included. An org chart can't.
Reorganizing a team takes months, involves real people and real compensation, and costs someone senior political capital. That's why structure lags behind the story a company tells about itself, and why it tells you the longer-lasting truth.
If a company says it's customer-obsessed, look for who owns customer research. If it says AI is central to its next phase, look for who is accountable for that work. A calm, curious "walk me through how this came together" will usually get you a more candid answer than anything in the deck.
Where Product reports is the most revealing line on the chart. It tells you whose priorities win when priorities collide, and whose voice gets heard when the roadmap is built.
When Product reports to the CTO, the roadmap leans toward what is technically interesting or technically overdue, and development tickets become the main input. Some of that is healthy. The risk is that customer problems become something the team considers rather than outcomes it owns, and the product manager turns into a very well-organized backlog administrator.
When Product reports to the CRO, the roadmap starts to look like a list of deals in flight. Calls with the biggest customers become the main input, and the company slowly turns into a development shop for those accounts.
AI is about to make this sharper. A rep can now build a working demo, show it to a customer, and ask Product to just inject it into the platform, without anyone asking whether it's the right thing to build or who maintains it once it ships.
When Product reports to the founder, that's often exactly right early on. It becomes a concern once the company outgrows one person holding every decision. On the chart, it shows up as a product leader with a big title and very little authority.
The arrangement that holds up best at scale is usually Product and engineering as peers reporting to the CEO, with a clear agreement about who owns the "what" and who owns the "how."
Ask: "When Product and engineering disagree about priorities, who breaks the tie?" Then: "Walk me through where your last three big roadmap decisions came from." If every answer traces back to the same source, you've found the blind spot.
Often nobody chooses where Product reports, and that isn't automatically a warning sign. A convoluted org chart is frequently just a company that grew faster than its structure.
Product starts in the founder's head. When the founder moves on to other parts of the business, it gets handed to whoever seems closest. I recently spoke with a company where Product was being handled by sales and marketing because the CEO wanted to focus on engineering. Nobody had decided that. It just landed there and stayed.
That's a normal stage on the way to maturity. The risk comes when it outlasts the stage, and convenient decisions harden into silos nobody chose and nobody questions.
The boxes only tell you half the story. The other half is who sits in them, what they did before, and how long they've been there.
A common mismatch is a project manager given the product manager title. A project manager takes input and executes on it. A true product manager sits at the hub of the wheel, gathering input from every part of the organization and deciding what is most worth building next. It is an act of anxiety and balance.
Prior roles shape perspective too:
Watch as well for seats filled for reasons unrelated to the work, like a family member placed wherever they'd do the least damage. If that seat turns out to be Product, it says something about how the company values its product.
Tenure cuts both ways. Long-tenured leaders carry enormous context but can become set in their ways, which isn't great for innovation. A team whose management changes every six months never finds its footing.
Ask: "Before they stepped into these roles, what was each product leader doing, and how long have they been in the seat?"
The number of engineers each product manager supports tells you how much thinking happens before code gets written. A common working range in B2B software is five to ten engineers per PM, counting QA.
Look at the seniority mix, since a mostly junior team needs far more direction. And find out who guides technical strategy, whether a technical architect, a principal engineer, or in smaller companies the CTO. Without that role, product managers end up making technical calls by default.
Past fifteen or twenty engineers per PM, product management turns into triage. Pendo's research has found that roughly 80 percent of software features never reach meaningful adoption, and an overstretched Product team is one of the most reliable ways to pay engineers to build that 80 percent.
In a healthy balance, a PM spends about 30 percent of their time with development, 30 percent with customers, marketing, support, and sales, 30 percent on roadmaps and requirements, and 10 percent on administration. Most organizations lean closer to 80 percent facing engineering.
The fix isn't always headcount. A technical architect can absorb technical decisions. A business analyst or product operations role can take on detailed requirements. An excellent support team can field questions so Product doesn't have to.
A simple starting point is asking each PM to estimate their own split against 30/30/30/10. The gap shows you where to look first.
Ask: "How many engineers, including QA, does each product manager support, and how senior is that team?"
Leadership owns its structure. What you bring is an outside view and the standing to ask why it's set up the way it is, without having to live inside the answer.
Scale makes that question harder in both directions. Leaders from large organizations often install a big-company org chart too early, which smothers the agility a small company depends on. But a company growing from $8 million to $30 million can't keep running on the same small staff without taxing everyone past their limits.
Operating lean works when a business is optimizing. It becomes a problem when the business is supposed to be innovating. It's a dance, and the steps change with each stage of maturity. If the company has grown, raised money, or made acquisitions and the org chart hasn't changed, ask why.
Timing is what makes this matter for private capital. Structural problems are slow, and by the time they surface as a missed roadmap or a key departure, fixing them takes quarters of a hold period you can't get back.
So the next time a portfolio company sends over a beautifully staged strategy deck, go ahead and admire the lemons. Then ask for the floor plan.