Build Faster Feedback Loops Using Qualitative User Research
Introduction: Why Getting Early Feedback on Ideas or Products Is Useful
If you’re an early-stage startup founder, learning velocity is critical. Being able to test and reject or double-down on hypotheses to help you establish if you’re building the right business and product for the right customer and market is essential.
When you’re in the wilds of pre-product market fit and navigating the idea maze, you need ways to orient and learn whether you’re going down the right path – or about to hit a dead end.
Why I’m Writing About Gathering Qualitative User Feedback
While The Mom Test book by Rob Fitzpatrick is an oft-referenced and useful resource, I thought I’d share a bit about how I’ve approached getting feedback on early explorations as a founder for CodeYam and over the previous decade while working at technology startups. This is a practice I’ve honed over time and I’m still constantly learning, improving, and experimenting.
This journey began when I discovered the Design Sprint book and process developed by the team at GV while working at a startup called Kamcord roughly circa 2017. On and off (as needed) over the years since then, I have been using variations of that process, along with the accompanying GV Research Sprint created by Michael Margolis, to help get unstuck, speed up learnings, and test out new ideas in low-risk ways.
If you worked at a larger technology company, “design sprint” often comes with a very different set of connotations; you might imagine designers blocking off a week (or more!) of time on the product and development team calendars and spending it working on ideas that, while fun or interesting, are never going to be priorities to build. This whiteboard whimsy that leads to no real results is the opposite of what I’m talking about, and using facets of the sprint process to accomplish, here.
Instead, we’re trying to get real feedback from potential customers and/or users of a product (or that might be users of a potential future product that hasn’t yet been built). We are trying to get relevant feedback from a small, representative group as fast as we can to test our risks, hypotheses, assumptions, and to inform how we successfully meet our goals (or fail faster and move on with the learnings).
A Note on Using AI Tools for User Research
New AI tools can likely be a big boost in terms of getting useful feedback faster. However, I’m still experimenting with how best to use those in this process. I will share what I’m doing today, although I anticipate this may change.
That said, as an early-stage founder, it is fundamentally important to be “in the arena” and talking to the people that are, or might become, your buyers and/or users.
Even if your product is meant to be used by AI agents, there’s likely a human somewhere along the way responsible for those agents and/or buying your product and deciding to deploy it. Find and talk to those people.
Use AI tools to sharpen hypotheses and accelerate testing, but don’t use it to replace talking to your human customers or users.
How I’ve Learned from User Research
Some areas where I, often with a small team although sometimes solo, sought qualitative feedback and used elements of the sprint process successfully include:
Testing out new product ideas (happening now)
Testing out value propositions and messaging (also happening now)
Testing out landing pages
Learning about a user group or market
Validating (or invalidating) that you’re actually tackling a meaningful problem / pain point
Getting early signal about willingness to try a product or service
Learning about willingness to pay
Figuring out what parts of a product’s UI / UX are working or are confusing
…among other use cases.
One counter-intuitive insight is that user research is an excellent tool to help you realize when you’ve failed to achieve your objective. Maybe the idea you fell in love with just doesn’t do it for the group you thought would be your customers. Maybe you realize the market is too small or too hard to reach. One of the biggest values of qualitative research is being able to fail, and learn from those failures, faster.
By reducing the amount of time and effort it takes to realize something doesn’t work, you’re extending your runway to experiment and iterate to get to something that is extraordinary.
If you’re a venture-backed startup, you’re probably taking a big, ambitious swing (we are at CodeYam!). Being able to learn through faster feedback loops that qualitative research unlocks is immensely valuable. It helps you make progress, or pivot, faster and with greater confidence.
Whether we’re testing an actual software product or just raw ideas through design prototypes, we’re able to get a “good enough” version of our hypothesis in front of our target audience and learn from their honest reactions.
What This Series Will Be About
This post kicks off a new series (length TBD) that dives into a bunch of connected user research topics; from figuring out who to talk to, where to find them, how to ask the right questions, and how to gather useful qualitative feedback. I’ll be pulling in real examples from CodeYam and past research to bring this all to life.
Some themes I’m thinking about covering:
How to recruit the right people for user research, especially pre-product
Designing a solid research guide
How to run a research interview
Deciding what to test (and when)
How we’re approaching user research at CodeYam
Hard-earned lessons from past research efforts
Speeding up research workflows with AI
Tools we’re using such as FigJam, Craigslist, Superhuman, ChatGPT, Claude, etc. and how they fit into the process
While startups' needs are never one-size-fits-all, my goal in sharing this is to help other founders, particularly those who are pre-product-market fit or conducting R&D to decide if they should pivot or double-down on a strategy or product direction. My hope is this gives other founders and their teams actionable insights and helpful tools to speed up their own feedback loops.
If you’re doing user research to explore startup ideas or make product or engineering decisions and have questions or feedback, I’d be happy to chat. Reach out any time at nadia [at] codeyam.com .
If you’d like to follow what we’re building and exploring at CodeYam, you can also subscribe to our company’s blog.