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

NICOLAS

On the note of creating a product decision framework — you said somebody needs to make the decision. What is that framework actually? Is it a markdown file with “do this, then that”? Or is it more of an educational piece? In your mind, what is the framework?

MARIA

To me it's all about de-risking. The closer you get to the customer with your solution, the bigger the risk — because you grab their attention once, and if they try your tool and decide it's not useful, earning one more chance is very, very difficult. So you need to think: if I have one chance, what's my best possible solution to bring in front of the customer, and what's the means to get there? Fortunately or unfortunately, there's no way to de-risk that other than user research and data. You need to understand really well the context of whoever the customer or user is. You can, of course, build a checklist — there are multiple techniques; humanity has developed a huge number of ways to run user research, to figure out what people will actually be happy with when they have a problem to solve. But I wouldn't say there's one blueprint you should use for everything — what matters is understanding customer context, customer day-to-day. If you love user story mapping, do user story mapping. If you love pain-gain canvases, use those — it doesn't really matter. I've seen so many approaches throughout my career.

NICOLAS

I remember you reposted a hierarchy tree for reading through product books, product development.

MARIA

That wasn't mine, but I reposted it, yes. 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.

NICOLAS

How do you balance user interviews and existing product data? In an early phase you don't have product data because you have no users — you're just doing interviews. Then at some point you get product data, and how do you—

MARIA

Data always tells you what's going on. It never tells you why. You have data, you see that nobody's using — let's say — feature X, it doesn't click. Then you can make a number of hypotheses, very simplistic ones: they don't click because they don't see the button, so make the button more prominent, highlight it, make it red. Or they don't click because they have no interest in moving forward, so we probably haven't put them on the right journey with what we show on screen. You make a number of hypotheses, and then you have two ways to move forward, and it really depends on the nature of the product.

MARIA

In some cases the easiest thing is to just call your customer and ask — especially if you're in B2B SaaS and your product is a bit more enterprisey with a handful of customers. The easiest thing is to ask them, because they'll tell you. If you're working on a consumer application, end of story — you can't call them all. You might call one, and it'll be a very unique person with a very unique opinion. That's where you say, “okay, now I need to test this properly” — we'll make a couple of changes, run some A/B tests, and learn whether we can actually get them to click with a few tweaks, or whether we can't make them click at all, in which case, let's pivot, let's do something different. So it's really about whether you can power your decision-making with data, and what gets you to the answer fastest.

NICOLAS

So you've been in the industry long enough to see past all the frameworks — they're just tooling. Your ambition is to be the leading product agency in Finland, and beyond, helping mostly SaaS but also B2C companies with their product development practices. The current issue: a lot of customers build a lot of features but don't see much adoption — partly because it's become so easy to build these days, alongside a lack of product development discipline. There have always been rules for de-risking product development, usually the job of a product owner or product manager. You come in and help them de-risk their practices by talking to users and forming hypotheses. In the beginning you only have user discussions; once you have product data, that data will never tell you why something is happening, only what is happening — so you need to make guesses and interact with your users, and B2C and B2B have different practices for that.

MARIA

Yeah, in a nutshell. And I think techniques and practices change, but the principle stays: you still need to know your customer pretty well to build an on-point solution that actually lands with them. Whether it's qualitative or quantitative data that you use to build that learning doesn't really matter that much — just find the appropriate approach for the current situation.

NICOLAS

A big part of what product managers do is understanding the user journey — how the user goes through the product, both visually and architecturally.

MARIA

Can I correct you straight away? That was another fight I picked up this spring, in a number of companies. The challenge isn't understanding how the user goes through the product — we all have an idea and assumption of how the user should go through our product. The challenge is understanding the user's day-to-day and their journey around the problem you're solving for them. When we talk about “user opens screen A, goes to screen B, goes to screen C, swipes a credit card” — that's a service blueprint. That's not your customer journey. Your customer journey is: your customer wakes up in the morning, and let's say they have a feeling that something is off with their marketing campaign data, and they need quick access to some tooling. Currently they click through five dashboards, but you know how to do it more efficiently and give them one instead of five. It's all about their context — they really need information fast, and the faster they get it, the happier they are.

MARIA

So when I talk about customer context, I really mean customer context — not how we want the customer to use our product, but how they actually live. It's very funny — when I start with a company, I ask, “can I see your user journey or customer journey map?” The first thing they show me is the service blueprint. That's a thing about the company, not about the users. It's how the company wants to work, not how the users think and operate.

NICOLAS

And then, how do you unblock them from what they want to achieve within their own context?

NICOLAS

With all the automation, where do you think the most important place for a human to be in the loop is? If you could automate everything, where does a human add the most value currently?

MARIA

There's a very popular answer, which is “taste” — I like and don't like it as an answer, because I think it's really hard to define what taste even means. But I think the part where a machine can't do it well is empathy. When it comes to connecting dots from online and offline user context and figuring out what will actually be helpful, machines aren't super capable of that yet. So in software development, I think this part — understanding users — will still stay with humans. Of course you can make it faster and more efficient: you can run surveys, record all your meetings and ask a model to interpret and find patterns very quickly. But in some cases you don't even talk to users, you observe them — and that's something the human brain still processes better than models, in the context of user research.

NICOLAS

I like how you used the word “taste” — with taste, you can make everything else faster too. You could theoretically use a machine to test a million hypotheses and just find what sticks — the way we tested creative ads at Smartly.

MARIA

The creatives, yeah, yeah.

NICOLAS

But with taste, you might not need to test as much, or you know what to test faster.

MARIA

Yeah. Human brains — and basically machine learning or AI — have the same patterns and basic principles under the hood. What you do as a human is work across a lot of situations, build your craft, learn something, stick with something. We've all been in a situation where — doesn't matter if you work in product management or product design — you look at a screen and something feels off. Something is itching, and you can't even verbalise it at that point, but you feel something is off. That's a feeling, and that's what taste is, at the end of the day — you just know one thing is better than another, and sometimes it's really hard to verbalise. And of course, if you build your internal AI tools with all the context, all the iterations, everything, they can also help surface when something's off. But that's basically the same as what humans do — you build your intelligence in a certain way.

NICOLAS

Before we wrap — was there something you'd like to comment on, or something you'd have hoped I asked but didn't?

MARIA

Since we were talking about data, I wanted to mention — as a message to other people too — that even though I said you can do qualitative or quantitative research, you shouldn't disregard product analytics. It's still super essential. I'm currently struggling with a couple of situations where people say, “we have 550 customers, we don't need to monitor and track anything.” But one trackable action is worth a thousand words — you still want information about how a user acts in certain contexts, rather than only what they claim they do. With modern AI tooling, it's so easy to implement tracking and make sure you have this factual information about the actions themselves. Don't disregard it — think about it from the get-go. Because when people build applications nowadays, you prompt it and get your application in three hours. Remember it's not just about building and shipping it — it's also about evolving, developing, and improving it, and for that you need certain tooling. Tracking, for example.

NICOLAS

And it's likely harder to implement later than early.

MARIA

For sure.

NICOLAS

And I think the other thing about humans is habit — it's easier to form a habit early on than to adopt one later.

MARIA

Yeah, yeah, yeah — and then you have this application, nobody's adopting it, and you don't know why.