How to Do User Research for SaaS Without Slowing Down Your Team.

User research doesn’t slow SaaS teams down. Skipping it does. Most product teams I work with in Belgium still treat research as a separate phase they can’t afford, or skip it entirely because “we are the customer.” That assumption is one of the most expensive mistakes a product team can make. This article lays out a research approach that fits inside your sprint cycle: three to five user interviews per release, in-product feedback, analytics to find friction, a shared insight repository, and a clear rule for when to go deep. You don’t need a dedicated research team.

All great products are built on a foundation of user research, before launch and throughout their lifetime. The depth of that research often depends on the size of your team, the size of your budget, or simply how committed your organization is to getting it right.

Yet, in my experience working with many companies in Belgium, real user research is still rare. Too often, it’s seen as something that slows things down. Business teams assume they already know what users want, especially when the product is built by people from the same industry. “We know the customer because we are the customer.” It sounds convincing, but it’s one of the most misleading assumptions a company can make.

As a product experience strategist, it’s my job to help teams understand why user research matters — especially when they think it doesn’t. Once they accept that challenge, the next step is to design a research process that actually fits their reality — one that supports the team instead of slowing it down. Because let’s be honest, very few organizations have the time or resources for long, expensive research cycles.

So how do we start small? First, let’s clear up a common misconception: you can start small, and you should aim for simple — but remember, there is no such thing as simplicity in life.

Identify the challenge

Before diving in, ask yourself whether you truly need user research. If you’re building a straightforward, informational website and working with limited time or budget, then honestly – just build and ship the damn thing. Although user research is always valuable, in some cases, it might not be essential. However, if your product goes beyond that – if it involves users interacting with features, completing tasks, and expecting tangible value from it – then research isn’t optional. It’s the foundation for building something people will actually use and love.

Before we started with design, we gathered a designer, a developer, a product owner and the client in a user workshop to map out the features.

Start with just enough

Forget about big, formal research processes. If you’re not used to doing user research, starting large will only slow you down. Instead, focus on lightweight, high-impact methods: run three to five customer interviews per release cycle, test quick prototypes, or embed short in-product surveys during onboarding. Focus on observing real user behavior rather than relying solely on assumptions. The idea is to create a continuous learning loop—small, frequent tests that inform design decisions—so you build empathy for your users from the start and refine your product iteratively.

Make research a habit, not a project.

Instead of treating user research as a separate step, build it directly into your product cycle. Each sprint can include one or two quick user calls focused on a current problem or feature. If you have a customer success team (even if it’s just one person), make sure they’re proactively gathering feedback – that’s their core mission anyway. After every release, run a short 15-minute retrospective to reflect on what users loved, ignored, or dropped. Small teams thrive when research is continuous, not occasional. Learning should move in sync with development, not trail behind it.

Empower everyone to be a researcher.

You can’t afford a dedicated research team – I get it. But you can equip everyone on your team with basic research skills: how to ask open-ended questions that go beyond yes/no answers, how to spot behavioral patterns, and how to quickly synthesize insights using methods like affinity diagrams or card sorting. The goal isn’t academic rigor, it’s shared empathy. When everyone on the team truly understands users, every decision improves. This is exactly how the biggest companies stay ahead.

Integrate research into the flow of your work.

If you want real feedback from users, you need to meet them where they are. Start by using product analytics to identify friction points. I’ve used tools like PostHog or Mixpanel, and they work wonderfully well for this. They enable you to define specific events and track if and how users interact with these events. Complement that with lightweight feedback widgets embedded in your product that ask simple, direct questions; I’ve used Featurebase and Hotjar effectively for this. Whenever possible, record and analyze support chats, they’re often goldmines of user pain points. The key is that research shouldn’t slow down your work; it should inform it, seamlessly guiding your product decisions.

Build a research repository.

Don’t let your research findings get lost in Slack threads or buried in old emails. Capture them in a simple, shared space where everyone can access and update them. On most projects I’ve worked on, we used Confluence, but I’m a big fan of Notion — even a plain Google Doc works. At minimum, track what you tested, what you learned, and what your next steps are. This keeps insights alive, builds institutional memory, and avoids unnecessary bureaucracy.

Know when to go deep.

When something truly mission-critical arises (like redesigning your onboarding flow), it’s worth going beyond lightweight research and planning a deeper validation process. I’ve found usability testing especially effective: create a minimal prototype with interactive links for the scenario you want to test (always make sure all the links work!). Contextual inquiry also works well, whether through surveys, moderated usability tests, or focus groups. The key is balance: keep most research lightweight, but reserve time each quarter for deeper, high-impact validation.

Conclusion: make research a habit, not a hurdle.

User research doesn’t have to be a slow, academic exercise reserved for big tech companies. In SaaS, speed matters, but so does understanding your users. The goal isn’t to choose between learning and shipping; it’s to build a rhythm where the two feed each other.

Start small. Talk to users regularly. Test lean, often, and with purpose. Integrate insights directly into your sprint cycles, so learning becomes part of building, not a separate phase that delays it. Over time, you’ll see that the most efficient teams aren’t the ones skipping research; they’re the ones who’ve made it second nature.

Do less “user research,” and more researching with users. That’s how SaaS teams stay fast and smart.