A SaaS company builds accounting integrations for their platform. Multiple customers had asked for them. The team delivered. Usage: flat. Weeks go by. The dashboard doesn’t move.
Five user interviews later, the team understood what happened. Users were looking for the logo of their accounting software – something visual and familiar. They saw a text label. They assumed the integration hadn’t been built yet. One design change. Problem solved.
The research that would have caught this before launch would have taken a week.
Viktoria Korzhova, product coach at Product People, opened her talk at Agile Tour Vienna 2025 with this story not as a cautionary tale but as a precise illustration of what user research is actually for. Not validation. Not checkbox compliance. The systematic reduction of the gap between what teams build and what customers actually need.
Viktoria is clear from the start about what user research doesn’t do. It doesn’t tell you which business outcomes to pursue. It doesn’t replace product strategy. It doesn’t generate features.
What it does: it identifies and validates the opportunities that sit between a customer’s current situation and a better one. In Teresa Torres‘ framing – which Viktoria draws on explicitly – these opportunities are unmet needs, pain points, or desires. User research is how you find them before building, instead of after.
Most teams treat research as a project: something that happens at the start of a big initiative, produces a report, and then stops. The argument in this talk, and in Torres‘ Continuous Discovery Habits, is that this is the wrong shape entirely. Weekly touchpoints, small research activities, the team building the product talking directly to the people using it. Research as a habit, not a phase.
Viktoria organizes the talk around four research methods, each with a specific job. Knowing which to reach for – and which to skip – is most of the skill.
User interviews for discovering problems and opportunities. Surveys for quantifying and prioritizing what you’ve already qualitatively identified. Usability testing for understanding how people actually interact with something you’ve built. AB testing for measuring which version of a solution performs better under real conditions.
These aren’t interchangeable. Using a survey to discover a problem you haven’t found yet produces data that feels meaningful and isn’t. Using an AB test before you understand why behavior differs produces winners that can’t be explained. The method has to match what you’re actually trying to learn.
Nielsen Norman Group research suggests five users is often enough to identify the majority of usability issues. But user interviews as Viktoria describes them aren’t primarily about usability – they’re about understanding the problem space.
The structure matters. You’re not asking people what they want („they’ll say a faster horse“). You’re asking about their current situation, their workarounds, the moments where things break down. The goal is to understand the problem so precisely that the solution becomes almost obvious.
The accounting integration story is a perfect example. The feature request was „we need accounting integrations.“ The actual problem, visible only after five conversations, was that customers couldn’t find what they’d asked for. No amount of requirements gathering would have surfaced. Only watching users try to use the product did.
Surveys are seductive because they scale. You can reach thousands of people and produce a spreadsheet full of percentages. The danger is mistaking statistical confidence for insight.
Surveys are good for one thing: quantifying what you already understand qualitatively. If your user interviews surface three possible explanations for why adoption is low, a survey can tell you which explanation applies to 70% of your users vs 20%. That’s useful. A survey that asks open-ended questions about what customers want, before you’ve done the qualitative work, produces data that’s hard to interpret and easy to misread.
The sequence matters: discover qualitatively, quantify quantitatively. Running them in the wrong order wastes both.
The accounting integration story again: if you’d surveyed customers about whether they found the integrations useful, many would have said they didn’t know because they hadn’t tried them. A usability test – watching someone try to find and use the integration – would have shown the problem in the first session.
Usability testing doesn’t have to be elaborate. Five participants, a task, a facilitator who resists the urge to help. The goal is to observe behavior, not collect opinions. What people say they would do and what they actually do are reliably different – and it’s the behavior that determines whether your product works.
AB testing gets misused more than any other method in the toolkit. Teams run tests on changes too small to produce meaningful signal, or on designs that haven’t been validated qualitatively first, or without enough traffic to reach statistical significance.
Done well, it’s genuinely powerful – a direct comparison of two versions of something, under real conditions, with real users, producing a measurable outcome. The key word is „measurable.“ You need to know in advance what you’re measuring and why it matters, or the result doesn’t tell you anything useful even if one version wins.
The failure mode is using AB testing to resolve an argument rather than to answer a question. That’s a different activity, and it usually produces results nobody trusts.
The most durable thing in the talk is the simplest: research works when it’s continuous, not when it’s a phase.
Teresa Torres defines continuous discovery as „at minimum, weekly touchpoints with customers by the team building the product, where they conduct small research activities in pursuit of a desired product outcome.“ Not a research department. Not a quarterly study. The team, talking to users, every week, with a specific question they’re trying to answer. TechTalk’s Product Owner Key Skills training – covering impact mapping, story mapping, and the techniques that connect user insight to actual backlog decisions – is built on exactly this foundation. As is the Certified Scrum Product Owner program for those who want the broader decision-making context.
Most teams don’t do this because it feels expensive. The accounting integration story is the counterargument. Months of development, delayed adoption, a fix that took one design change. The cost of not doing the research was already paid. It just wasn’t labelled as a research cost.
The methods are learnable. The discipline of doing them continuously is harder – and more important.
Viktoria Korzhova spoke at Agile Tour Vienna 2025. The 2026 edition is live – the full program is available now.
Build your solid foundation through our training and continue developing your leadership and coaching journey.