Data always tells you what's going on.
It never tells you why.

Maria Petrova has spent most of her career on the inside of the problem she now gets paid to solve. Fifteen-plus years leading products at Smartly.io, Zalando, Supermetrics and TWAICE — the kind of European product organisations that are supposed to have this figured out — before co-founding ValueLab, a Helsinki product management consultancy, with Janetta Ekholm.

The two of them arrived from different angles at the same conclusion. Ekholm came out of Futurice and co-designed Finland's first product management curriculum at Aalto University; Petrova came out of operating roles where the roadmap was hers to be wrong about. What they built together is deliberately not an advisory firm. ValueLab places experienced product operators inside a client's team — people who, in the firm's own words, own the work, ship the product, and build the capability around them. Interim leadership when the seat is empty. A short evidence sprint when nobody can agree what's actually broken. Workshops run on the team's real backlog rather than a case study. Backed by the Reaktor and Coventures ecosystems, they've worked with TWAICE, Katana, AutoVex and Sanoma — green energy, manufacturing SaaS, automotive marketplaces, media. The stated ambition, as Petrova put it on the call, is to be the leading product agency in Finland, and then past it.

The pattern that keeps landing on her desk is the same one in every industry: teams shipping a great deal of software that nobody adopts. Her diagnosis is unsentimental. Building got easy faster than deciding got disciplined.

So when you ask her what a product decision framework actually is — a markdown checklist? a training deck? — she declines the premise and goes straight to the constraint underneath it.

“The closer you get to pushing a solution to market at scale, the bigger the risk. If users tried out your tool once and consider it not useful, to earn one more chance would be very, very difficult.”

Maria Petrova

That's the whole game, as she plays it. You get roughly one honest attempt at a person's attention. Everything upstream of that moment — the research, the hypotheses, the arguing — exists to raise the odds that the one attempt lands. There is no clever way around it. Fortunately or unfortunately, she says, there is no way to de-risk that other than user research and data.

Which is where most people expect her to produce a method. She won't. Petrova has watched the industry manufacture frameworks for a decade and a half — user story mapping, pain-gain canvases, the endless reposted hierarchy trees of what to read — and her position is that the technique is the least interesting part. There are so many frameworks and techniques that ship to market, but what's most important to me is highlighting some principles, and then you find the techniques that work best for you. If you love story mapping, do story mapping. What the artefact has to deliver is understanding of the customer's context and day-to-day. Everything else is preference.

Then the second constraint, delivered flatly, and it is the sentence the rest of the conversation orbits:

“Data always tells you what's going on. It never tells you why people behave this way or another.”

Maria Petrova

Take the ordinary case: nobody clicks feature X. The number is true and the number is useless. It supports two entirely different stories — they can't see the button, or they can see it fine and don't want what's behind it — and it cannot adjudicate between them. What the number does is generate hypotheses. What resolves them is a human method, and which method you reach for depends less on your taste than on your customer count.

In enterprise B2B, with a handful of accounts, the fastest, cheapest instrument available is a phone. The easiest thing is to ask them, because they will tell you. In consumer, that same phone call actively misleads: you'll reach one unusually opinionated person and mistake them for a population. So you change the tool. A couple of product experiments, a couple of A/B tests, and you learn whether a few tweaks can move the behaviour — or whether nothing will, in which case, pivot. Not two philosophies. One question — what gets me to the answer fastest? — with two correct answers depending on who is on the other end.

The sharpest moment of the conversation is a correction. Asked about mapping how a user moves through the product, Petrova stops the question mid-flight. Can I correct you straight away? — this, she says, was a fight she picked in several companies over the spring.

“When we talk about user opens screen A and then goes to screen B, we are talking about service blueprint. And that's not your customer journey. The first thing many builders share with me nowadays is the service blueprint. That's the perspective of whoever develops the solution, not of its users. It's how you want things to work out, not how your users think and how they operate.”

Maria Petrova

The distinction sounds academic until you price the error. A screen-by-screen map is a document about the company: how it has decided the user should behave. A customer journey starts before the product is open — someone wakes up, senses that something is off in their campaign data, and needs an answer now. Today they click through five dashboards to get it. The opportunity isn't a nicer version of those five screens; it's collapsing them into one, because they really need to get some information fast instead of delivering more clicks, and the faster they get it, the happier they are. Speed to the answer is the unit of customer happiness. You cannot see that unit anywhere on a service blueprint, which is exactly why teams optimise the blueprint and wonder why adoption doesn't move.

Ask her where humans still hold an edge as automation eats the rest and she reaches for the popular answer only to put it back down. Taste, she says, is what everyone says, and she both likes it and doesn't — it's very hard to define what taste even means. Pressed, she does define it, and better than most: you look at a screen and something feels off, something is itching, and you can't verbalise it yet. That's a pattern-recogniser built by exposure, and she notes the obvious symmetry — human brains and models are both doing something structurally similar under the hood.

But it isn't the answer she gives.

“The part where machines cannot do it really well is empathy. Connecting dots from online, offline user context and figuring out what exactly will be helpful — machines are not super cool with that yet.”

Maria Petrova

Note where that leaves the machine, in her division of labour. Faster surveys, recorded calls, models finding patterns across them — all fine, all welcome. But some research isn't a conversation at all. Sometimes you don't talk to users, you observe them, and the human brain still does that better. The durable human job isn't producing the answer. It's noticing what the answer was about.

Which brings the conversation to the one thing she volunteered without being asked. Given the chance to add anything at the end, she used it on instrumentation — and on the founders who tell her they don't need any.

“One trackable action is worth a 1000 words, so you still want to make sure that you have some information about how users act in certain contexts rather than what they claim they do. Don't disregard it. Think about it from the get-go.”

Maria Petrova

She is currently arguing this with more than one company: we have 550 customers, we don't need to monitor and track anything. Her objection isn't that talking to those customers is wrong — she's just spent the whole conversation arguing for it. It's that stated intent and observed behaviour are different data, and you need both. And the timing is not neutral. Nowadays you prompt an application into existence in three hours; what you cannot prompt into existence retroactively is the record of what happened in it. It's not just about building it and shipping it. It's also about evolving it, developing it, improving it — and for that you need certain tooling. Harder to retrofit later than to lay down early, as she and Nicolas agree, and the same is true of habits: easier to form one at the start than to adopt one after the fact.

Otherwise you end up in the place she describes in a single deadpan line, which is where a surprising number of well-built products already are — you have this application, nobody's adopting it, and you don't know why.