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 at a market-leading Swedish housing platform. Her team was new and sat in a business-critical part of the product.

Leadership had defined a new business rule. A delivery date was already promised to partners and the board. The team’s job was to ship it. When Lisa arrived, the business case was treated as settled.

Validate the assumptions under the idea before anyone writes code that depends on them. Prioritization, roadmaps and standups all sit downstream of whether the assumption was true.

The assumption was the thing that broke

The team compared the methods that could deliver what the new business logic required. The comparison showed that the assumption under the whole logic did not hold. The approach would land incorrectly, with consequences the business would not have accepted 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.

That is the PM’s first job, and the easiest one to skip. The assumption already carries 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. 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 closest to the user inside the company. Lisa ran structured conversations with account managers and customer success, the ones who hear the complaints and know the edge cases by heart.

The internal organization became the proxy for the market. But a proxy you can question beats an assumption nobody has questioned at all.

The translation is part of the validation

Every week, Lisa sat between Legal, Business Development, Communications, Finance and Analytics and translated.

A business stakeholder put it plainly afterwards: it is hard to follow what developers mean when they explain why something works or does not. Having someone act as that bridge let the business see the consequence of each choice.

That translation is how the validation reaches the people who can act on it. The bridge turned “this assumption is false” into “Finance agreed to change the rule”.

But what if validation slows the team down?

While the careful PM validates assumptions, the team that trusts leadership is already shipping. It learns from real code instead of meeting notes.

That describes validation done wrong, which is a separate problem. 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.

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

Take the next thing on your roadmap. 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.