Building fast doesn't mean building right

There's a version of the AI story that product teams are being sold: move faster, ship more, iterate in public. And on the surface, that sounds like progress. But if you've ever watched a product update land badly – features quietly removed, user behavior misread, trust quietly eroded – you'll know that speed without direction isn't momentum. It's just noise.

Mateja Milosavljevic, Lyssna CEO and Co-Founder, sat down with Ramli John on the Product Leaders Lab podcast to work through exactly this tension. Drawing on his background in UX design and a recent undergraduate degree in psychology, Mateja shared his thinking on what it actually takes to make good product decisions in an era where building has never been easier and getting it wrong has never been faster.

Metrics only tell you half the story

Most product leaders know they should be doing research. The conversations about why it matters have been had. The case has been made. So when things go wrong – when a deprecated feature causes a backlash, when an update alienates your most engaged users – it's rarely because nobody thought research was important.

Mateja's take on this is direct: 

He uses a concrete example to illustrate how this plays out: a product team notices that their CSV export feature is barely being used. Metrics suggest it's safe to remove. But when you look more closely at who is using it, you find they're the most engaged power users, the people doing the most meaningful analysis, and the ones most likely to flag the platform's limitations. Remove the feature and you've quietly removed one of your most valuable feedback loops.

The metrics were technically accurate. But they were only telling part of the story.

The Sonos situation from late 2024 is a bigger-scale version of the same pattern. “They wanted to modernize their mobile application, they wanted to simplify things, but in doing so, they ended up changing a bunch of behaviors and functionality that people actually depended on,” shared Mateja.

The backlash was significant enough that both the CEO and CPO left the company.

The lesson Mateja draws isn't that simplification is wrong – it's that teams get into trouble when they only look at one signal. What users say in interviews, what they actually do when you watch them, what's coming through support, what's surfacing in sales calls: these are all different lenses, and you need more than one.

Research isn't urgent until it's a crisis

There's a specific trap that Mateja names here, and it's one that will sound familiar to almost anyone who's worked on a product team under pressure: why research keeps getting pushed to later, and why "later" often never arrives.

What tends to happen instead is that research gets unlocked by a crisis. A feature gets pulled, customers complain loudly, support tickets spike, and suddenly there's urgency to have conversations that should have happened months earlier. The feedback is useful, but you don't want to rely on that pattern.

So how do you build research into a habit? Mateja shares the analogy of exercise: “most people would probably agree that getting into shape is important, but it's not often considered urgent, right? Unless you're having some sort of health emergency, until something forces the issue.”

Those that actually stay in good shape are the ones who build it into a routine, not the ones who sprint after a health scare.

“Strong product teams work in the same way. They make customer exposure just the normal recurring part of the process. So every project needs to have some amount of discovery and some amount of validation, just baked in,” shares Mateja.

“If you're on a tight budget or a tight deadline, it's still not negotiable. You have to do some amount of research. And so the question is not are we going to do it, but how? How are we going to get it done in the allotted budget or time that we have?”

This matters especially now, because the constraints that used to naturally slow teams down – engineering and design capacity – have loosened significantly. AI is removing those bottlenecks. What replaces them is judgment: the ability to make good decisions about what to build, not just how fast to build it.

Who you talk to matters

One of the patterns that gets flagged: teams tend to hear from the same people over and over, and mistake that for a complete picture.

The loudest voices are usually the ones running into problems. "Happy customers are usually the ones that are just busy getting their work done and getting on with things, and you're not as likely to hear from them as the ones that are running into issues,” shares Mateja. 

Which means if you're only listening to incoming feedback, you're systematically over-indexing on friction and under-hearing what's actually working.

He breaks down four groups that are particularly easy to miss:

• Happy, active users: They're not complaining, which means you're not hearing from them. But they're the ones who can tell you what's actually working.

• Prospective customers: People evaluating the product who haven't decided yet. Sales conversations are an underused source of insight here. At Lyssna, the sales team share highlight reels of calls across the company, making that perspective available beyond just the people who were in the room.

• Churned customers: Valuable, but time-sensitive. The longer you wait to reach out after someone leaves, the less they have to say. Mateja’s advice: get to them near the point of churning, not weeks later.

• People who have never considered you: The hardest group to reach, but often the most revealing. They can tell you how the market actually perceives your product, including things your active users are too familiar with your product to notice.

Make research feel reciprocal, not transactional

Compensating research participants is a common point of tension. Mateja's take: he's in favor of incentives, but with a specific framing – make it reciprocal, not transactional.

What you want to avoid is a dynamic where the incentive becomes the whole point, and the conversation loses its authenticity.

He gives the example of Lyssna's own pricing research: recruiting people who had never used the product specifically to get an unanchored view of how they'd respond to different pricing options. A monetary incentive made sense precisely because there was no existing relationship to draw on.

Contrast that with Lyssna’s community of existing users, where early feature access is often a more meaningful incentive because the value to those users is actually shaping what gets built. The incentive matches what they care about.

Speed is not a strategy

There's a version of the "vibe code and ship" mentality that positions rapid experimentation as inherently good. Being able to spin up prototypes quickly and get to something tangible is genuinely useful, but according to Mateja, here’s where the logic breaks down.

He points to Google's recent developer tooling changes as a visible example: “They had an anti-gravity CLI thing, and they've now wound that back, and now they have a new thing.”

Each change was made in rapid succession. From the outside, it looks less like iteration and more like a team that hasn't done the upfront work to understand where they're actually trying to go.

What Mateja is describing is something we see consistently too: teams that let AI-assisted speed replace discovery, not support it. The ones who are getting it right are using AI to move faster through the execution work, not to skip the understanding work that should come before it.

What this looks like in practice

You don't need a formal research program to start. Mateja is clear on this: building the research muscle is incremental, and the options available to most teams are broader than people realize.

Review historical metrics, look at what support conversations are telling you, and get recordings of sales calls. Run unmoderated studies. Watch session playbacks. Split test after launch. These aren't expensive or slow – many of them are already happening in your business, they're just not being treated as research.

The shift is treating discovery and validation as non-negotiable parts of every project, regardless of the timeline or budget. Not "are we going to do it" but "how are we going to do it given what we have."

And if you're only able to do one thing right now: temper your confidence accordingly. Know what you haven't done. Name the gaps. So that if something does go sideways, you already know where to look.

Whether you're navigating a roadmap decision, rethinking how your team approaches discovery, or just trying to make the case for research when everyone's under pressure to ship – the ideas in this conversation are worth sitting with.

Listen to the full episode here: Episode 10 - The Speed Trap