The three things every product team needs direct access to

Most product teams don't fail because they picked the wrong framework. They fail because nobody ever let them near the three things the job actually requires.

Marty Cagan makes this point in Transformed, his book on moving to the product operating model, and it has become the fastest diagnostic I run. Before I look at a team's process, I look at its access. A product team needs direct access to:

• Users and customers
• Product data
• Business stakeholders

Direct. Not "Sales sends us a monthly summary." Not "we file a ticket with the analytics team and hear back in a week." Not "our VP relays what the CFO said."

Miss one of the three and the team can still look busy. It just can't be right on purpose.

1. Users and customers

Access to the people you build for is what lets you do three things:

• Understand the problem and the need underneath a request, rather than the request itself
• Test a solution quickly, while it's still cheap to be wrong
• Confirm the thing you shipped actually relieved the problem

Here's the part teams get wrong. They scope customer access to the PM and the designer, and quietly exclude engineers to protect their focus. That's a false economy. The whole Product Trio should be able to talk to customers and test with them.

An engineer who has heard a customer describe the problem in their own words builds a different thing than an engineer who received a ticket. They spot the cheaper solution. They flag the edge case that matters and drop the one that doesn't. You cannot get that from a written handoff, because the handoff is exactly where the context dies.

The usual failure mode isn't hostility, it's gatekeeping. Sales owns the relationship. Support owns the inbox. Customer Success owns the account. Each has a defensible reason to stand between your team and a conversation, and the sum of those reasons is a team that hasn't spoken to a user in five months. If that's you, the fix is smaller than it looks: five conversations this week, booked as a standing slot rather than a one-off project.

2. Product data

Interviews tell you why. Data tells you where to look.

Behavioural data is where opportunities announce themselves before anyone can articulate them: the step where activation collapses, the feature with a great trial rate and no second use, the segment that churns twice as fast as the average. Those are signals. They're also the only honest way to check whether last quarter's work did anything.

The tell for missing data access is specific. Your team can recite its north star metric but cannot query it. When a number moves and you have to file a request to find out which segment moved, discovery stops being continuous and becomes a quarterly report. By the time the answer arrives, the team has already committed to something else.

3. Business stakeholders

This is the one teams fight hardest to avoid, usually because they've confused access with interference.

The four product risks are value, usability, feasibility, and business viability. Your customers cover the first two. Your engineers cover the third. Nobody covers the fourth unless the team is genuinely close to the people who hold the constraints: margin structure, legal exposure, contractual commitments Sales already made, the milestone the board is expecting.

Without that access, teams build things that are valuable, usable, and feasible, then watch them die in a review that nobody warned them about. The work wasn't wrong. It was just never viable, and the team had no way to know.

Access here also buys you the other direction. It's how you translate a business target into something a team can actually move, which is a harder and more useful skill than it sounds. I've written about why handing a team a revenue number backfires, and the translation only works if you can ask the stakeholder what's really behind the number.

How to tell which one you're missing

Each gap has its own signature. Read your last three months and see which one you recognise:

No customer access. Your roadmap is assembled from internal opinion and whoever asked loudest. Debates get settled by seniority, because there's no evidence in the room to settle them with.

No data access. You spend meetings arguing about whether a problem exists at all, rather than how big it is. Nobody can size anything, so everything gets sized by how strongly someone feels.

No stakeholder access. The work is fine right up until a review, where it gets reversed for a reason nobody states out loud. You find out about the constraint after you've spent the sprint.

Most struggling teams I meet are missing two of the three. Almost none of them describe their problem that way. They say they need a better prioritisation framework.

Access is granted, not hustled

An individual PM can bootstrap a bit of this. You can beg a few interviews off an account manager, learn enough SQL to be dangerous, catch the CFO by the coffee machine. That works for a quarter and it doesn't scale, because you're spending your credibility on plumbing.

Recurring access is an organisational decision. Somebody senior has to say the engineers are allowed in the interview, the team gets read access to the analytics, and every team has a named business counterpart who shows up. Three sentences. They're worth more than any process change you could make this year.

That wiring is the unglamorous core of what a product model transformation actually changes. Not the ceremonies, not the job titles. Who is allowed to talk to whom, and how often.

Frameworks are cheap. Access is the expensive part, and it's the part that decides whether the rest of it works.