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

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. Leadership had defined a new business rule. A delivery date had already been promised to partners and the board. The team’s job was to ship it. By the time Lisa arrived, the business case was treated as settled.

That is the moment a product manager’s most important job starts: validate the assumptions under the idea before anyone writes the code that depends on them. The prioritization, the roadmaps, the standups all sit downstream of whether the assumption was true.

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.

The assumption was the thing that broke

The first workstream was technical discovery. The team compared the methods that could deliver what the new business logic required, and the comparison showed that 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.

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.

Lisa validated whether the assumption 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 assumption arrives already wearing the authority of a leadership decision.

You validate the assumption 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.

When you cannot put the thing in front of a user, you validate with 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”.

But what if validation slows the team down?

Discovery can be procrastination dressed up as rigor. While the careful PM validates assumptions, the team that trusts leadership and starts building is already shipping, learning from real code instead of meeting notes.

That describes validation done wrong, and doing it wrong is a separate problem. A PM who validates everything to death has stopped doing the job; the job is to find the single assumption that would waste the most work if false and test that one before the build. Plenty of assumptions are cheap to test by shipping something small and watching. This one was not: a business-critical rule in a regulated domain, with a delivery date already promised to partners and the board, has no cheap undo.

On the housing platform, those weeks of validation were what saved the business from the wrong path, a false assumption that would have surfaced only once it reached production, with consequences the business was not prepared to accept. A team that starts building earlier is ahead only if the assumption under the build holds. This one would not have held.

The first move

Ask which assumption, if false, would waste the most work, and 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.

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.