A PM's first job is to test the business assumption

Most teams treat the business case as settled before the PM shows up. Someone in a leadership meeting decided the new rule, the finance model assumes it, and the team’s job is to ship it. Here’s what I think: the product manager’s most important job is to validate the assumptions under that idea before anyone writes the code that depends on them. The prioritization, the roadmaps, the standups all sit downstream of whether the premise was true.

Why care? Because a business assumption that fails after you have built on it is the expensive kind of wrong: you spent the engineering weeks, shipped the thing, and only then discovered the floor was never there.

Here is a real one. A senior PM, Lisa Trumstedt, spent a year (May 2025 to May 2026) as interim product manager inside a market-leading Swedish housing platform, on a newly formed team in a business-critical part of the product. The setup was ordinary: leadership had defined a new business rule, finance had modelled around it, and the team existed to build it.

The premise was the thing that broke

The first workstream was discovery, but not the user kind. The team compared the technical methods that could deliver what the new business logic required, and the comparison surfaced something uncomfortable: the assumption the whole logic rested on did not hold. The approach would land incorrectly, with consequences the business would not have accepted once they showed up in production.

This is the moment that decides everything. A PM who sees themselves as a delivery manager builds it anyway, because the rule came from above. Lisa did the opposite. She took the data and the technical reasoning back to leadership and said, in effect, we will not build this, we recommend changing the business rules instead. Business Development and Finance looked at the evidence and agreed. A large business risk went away before a single line of code existed.

What was validated there was whether the premise underneath the feature held up, long before anyone asked whether the feature itself was usable. That is the PM’s first job, and the easiest to skip, because the premise arrives already wearing the authority of a leadership decision.

You validate the premise even when you cannot reach the user

This was a public company in a regulated domain, which meant the obvious validation move, testing with real end users before launch, was off the table. No quiet beta. No phased rollout. When the product shipped, it shipped to the whole organization at once.

So how do you validate when you cannot put the thing in front of a user? You go to the people who sit closest to the user inside the company. Lisa ran structured conversations with the customer-facing roles, account managers and customer success, the ones who hear the complaints and know the edge cases by heart, and combined that with internal research. The internal organization became the proxy for the market. Imperfect, yes. But a proxy you can actually question beats an assumption nobody has questioned at all.

The translation is part of the validation

The reason this worked is the least glamorous part of the role. Every week, Lisa sat between Legal, Business Development, Communications, Finance, and Analytics and translated. A business stakeholder put it plainly afterwards: it is genuinely hard to follow what developers mean when they explain why something works or does not, and having someone act as that bridge was what let the business see the consequence of each choice.

That translation is how the validation reaches the people who can act on it, because a technical finding the business cannot understand changes no decisions. The bridge is what turned “this assumption is false” into “Finance agreed to change the rule”: the soft skill and the hard outcome were the same skill.

The honest objection

Now you might be thinking: this just slows the team down, discovery is procrastination dressed up as rigor. While the careful PM validates premises, the team that trusts leadership and starts building is three sprints ahead, learning from real shipped code instead of meeting notes. There is truth in this. Plenty of assumptions are cheap to test by shipping something small and watching, and for those, a PM who validates everything to death is a real failure mode.

The distinction that matters is reversibility. Shipping to learn works when being wrong is cheap to undo: a feature flag, a small cohort, a quick rollback. It stops working the moment the cost of being wrong is high and the rollback does not exist. A public company that releases to its entire user base at once, in a regulated domain, with a business rule finance has already modelled into its numbers, has no cheap undo. There, validating the premise first is the fast path, because the slow path is building the wrong thing and discovering it in production. The housing team avoided shipping a feature that would have landed wrong for the whole organization with no way to quietly pull it back.

The first move

So the PM’s first job is to ask which assumption, if false, would waste the most work, and then find the cheapest honest way to test it before the build. Sometimes that test is shipping something small. Sometimes, when you cannot reach the user, it is a structured week with the people who can. Either way, the test comes ahead of the code.

So here is the move. Take the next thing on your roadmap and write down the single assumption it would be most painful to be wrong about. Then ask how you would know it is true without building the whole thing. If you cannot answer that, you have found the riskiest part of your plan. And if you want to check the numbers your assumptions rest on against how comparable products perform, that is what a benchmark is for: https://benchmark.scilla.studio.