How We Made User Feedback Unavoidable

Many product teams treat user research like a scheduled medical checkup—something you know you should do, but put off until you absolutely have to. When we finally commit, it becomes this elaborate production: research sprints, scheduling through customer success managers, interview scripts, usability testing sessions, Miro boards, and presentations that take longer to prepare than the research itself.

I’ve worked this way at previous companies. It’s exhausting, expensive, and ironically, it often tells you what you could have learned in a five-minute conversation.

But when you’re bootstrapping a platform with three people and no research budget, you can’t afford elaborate processes. You also can’t afford to build the wrong thing. What we discovered by necessity taught me more about getting user feedback than any formal methodology I’d used before.

The heavy process I knew

At a previous company, user research felt like planning an expedition. We’d schedule meetings through CSMs, prepare prototypes, draft opening scripts and question docs. Rescheduling was disruptive. Because research time felt so precious and rare, teams would try to cram multiple participants into sessions to “make the best use of time.”

Part of this complexity came from operating across regions—our Singapore-based product team needed CSMs to act as translators for user conversations in Indonesia and Thailand. While this solved the immediate language barrier, it created high friction and cost for every interaction.

Actual screenshot: Our PM facepalming during a discovery session. I could still carry on as I was already dead inside.

Sessions happened maybe once a quarter if we were lucky, or if there was a massive project.

Looking back, this approach treated user research like a special event rather than ongoing relationship-building. But at the time, it felt like the only way to do “proper” research.

The Conversation Alternative

At another company, we took a completely different approach. We set up Slack Connect channels with every client’s key users and decision-makers, on top of already doing QBRs. Our team messaged them weekly—not so much that it became annoying, but enough to stay connected to their daily reality.

We did go through a phase of signing up for platforms like UserTesting and UseBerry, reacting to company challenges by thinking “everything must be tested.” Setting these up was labor-intensive, and the outcomes could have been answered with common sense and best practices.

But the Slack approach worked differently. Sometimes it was just dropping a screenshot with: “We’re working on X to solve Y problem for you. Does this approach make sense?”

The response comes back within hours, not weeks. No scheduling. No formal presentations. Just real feedback from people actively using our product.

Customer Success, Product Managers, Engineers, and Designers are all in these channels together. When users share challenges or report issues, we’re all there to hear it firsthand. When we ship improvements, they see the immediate impact.

What this looks like in practice

The mechanics are simpler than you’d expect:

Specific questions instead of formal research sessions. “How are you currently handling X?” “What’s the biggest pain point in your workflow?” “If we solved Y, would that actually help your team?”

Quick feedback loops instead of interview scripts. We ask precise questions that don’t require 10-minute responses. We’re not running therapy sessions—we’re solving specific problems.

Working alongside users instead of studying them. We learn about their challenges by collaborating on solutions, not by creating personas and journey maps.

What we found: most B2B customers actually enjoy getting direct updates and seeing how the product improves for them. Think about using an app you rely on, and having the Head of Product reach out directly rather than being filtered through support tickets or annual check-in calls. It feels collaborative rather than transactional.

When necessity becomes advantage

At Staffie, we didn’t choose this approach—it chose us. As co-founders with no support team, our entire team handles customer support through Intercom. We triage issues. We talk to users directly. Everyone resolves problems.

This wasn’t a methodology decision. When your survival depends on keeping customers happy with a lean team, there’s no buffer between what you build and whether it actually works for people.

What we learned from having no choice

This gives us direct, instant access to what users actually face. The user feedback is incomparable to scheduled research sessions. We share the same working context: we know how prevalent issues are, whether they’re actual priorities, and whether new features will move the needle based on hundreds of real interactions.

This isn’t research methodology—it’s operational design that makes user feedback unavoidable.

So we learned the hard way: this constraint produced better user feedback than any formal research process I’d used at larger companies. When everyone on your team feels the pain of customer problems directly, you stop building features users don’t need.

Why this works better than formal processes

Most companies try to retroactively build research culture through training and frameworks. But culture is hard to change—operational design and team structure are more reliable.

When customer problems become everyone’s responsibility, user understanding becomes automatic. No one needs to convince the team that user feedback matters. No one schedules it or creates presentations about it. It’s built into how the company operates.

Making the shift

Unless you know absolutely nothing about your users—which is unlikely if you’re already shipping a product—this ongoing conversation approach will teach you more than quarterly research sessions.

What I’ve learned from trying both approaches: it’s less about changing tools and more about changing how teams think about user understanding.

From scheduled research to ongoing conversation. Set up direct channels with key users. Use whatever communication tool your customers already prefer.

From broad questions to specific problems. Instead of “What do you think about our product?” try “How are you currently solving X problem?” and “If we improved Y, would that change how you work?”

From formal presentations to quick feedback loops. Share rough wireframes, describe what you’re attempting, and ask if it solves their specific problem.

From documented insights to shared context. Get your entire team involved in customer conversations so everyone understands user needs firsthand, not through filtered reports.

What gets in the way

The biggest obstacle isn’t technical—it’s structural. Many companies create layers between product teams and customers as they scale, and sometimes prematurely. Research becomes a formal department. Customer interaction requires approval. Teams lose direct access to the people they’re building for.

I get it. There are legitimate concerns about overwhelming customers, maintaining consistent messaging, and ensuring quality interactions. But there’s a difference between having guidelines and creating barriers.

What if instead of protecting customers from your team, you prepared your team to have better conversations with customers?

What I’ve learned

Many teams try to build user research culture. We baked user feedback into our operations.

When customer problems become everyone’s daily reality, you don’t need frameworks or methodologies. You need solutions that work. You stop building features that sound good in meetings and start building things that solve actual problems.

The result isn’t just better products—it’s a team that understands the real impact of their work because they feel it directly.

What would happen if your team tried this for a month? Pick one key customer, set up a direct channel, and ask them about one specific problem you’re trying to solve. You might learn more in that month than from all your previous research sessions and design ‘workshops’ combined.

———

To receive essays like these directly in your inbox, subscribe to leeyungtyng.substack.com