Basic User Research Framework for Product Development.
The earlier a product team invests in user research, the better it is for the product's development. From the earliest stages of trying to discover pain points and opportunities before you even know what you're going to build, to the later stages of improving retention for a product already being used by many, research should be an ongoing process embedded in the product team's process.
I wrote this initially in an email to a new product team to help them better understand the different kinds of data they should be looking for in their research and discovery efforts. I realized that it would also be helpful to many companies that may not have the budget to hire a dedicated user researcher, nor the personal expertise to properly incorporate research themselves.
At a basic level, you can break down research into 3 segments.
- Learning about your target market and the problem space. (discovery)
- Learning about the way your product is actually being used and about your actual users and their needs. (in-app analytics and user feedback sessions)
- Learning from people who have used your product and made the decision to not use it moving forward. (exit interviews)
These need to be ongoing at all times, and teams should invest early on into creating some kind of research database where you can store quotes, statistics, screenshots, transcripts, etc. Make it a regular process to analyze the data and tag it properly. There are many dedicated tools for this, but free tools such as Airtable and Notion will work wonderfully as well.
As much as possible, especially when you have limited resources, invest in automation. Don't try to remember to email someone when it seems they are no longer using your platform - build in triggers such as automated emails that go out after 2 weeks of no activity, or if you prefer to do things manually, set up an internal email or dashboard that sends you a list of inactive users to contact regularly.
Here are more details about the kind of data you should be looking for at each stage.
Discovery
You’re aiming to learn about the people and the environment. What goals are they accomplishing, what challenges are they facing, what needs do they have? How are they currently solving the problem, what tools are they using, what are their personal systems and mental models?
The people you’re talking to at this point in time don’t know about your product, they don’t really have an opinion, they are just aware of their own situation and context.
In-app data and user feedback sessions
You’re aiming at seeing how people are using your platform. How is the platform actually fitting into their workflow? Where are they getting stuck, what changes do they wish to see in the platform, how can their experience be improved to meet their goals better, is the platform actually working for them?
At this point, the people you’re talking to and observing are trying to fit your product or service into their process. They’re adapting their own personal systems to incorporate your tool into their workflow. They are imagining new ways of working for themselves, and envisioning new futures for the way in which they solve their unique challenges.
Exit interviews
You’re aiming to learn why people made the choice to stop using your product. Was it something about the way your product worked that didn’t fit into their system? Was it something external that kept them from integrating your product into their workflow? Was the problem not painful enough for them to learn to use a new tool? Is there a “competitor” that they prefer and why?
At this point, the people you’re talking to have already used your product and seem to have made a decision that it is not a fit for them at this moment. The reasons they made that decision are what should be your goal to learn, because it may clue you in to a number of things that are important for your product to succeed. Don’t try to convince people to stay, try to learn. Keep doors open and ask for permission to follow up in the future when you’ve made changes reflecting on the feedback you’re receiving.
Conclusion
Most importantly, if you haven't incorporated research into your teams process yet, it's not too late. The sooner you start capturing critical data, the more your product becomes responsive and adaptable to changes in the market, evolving user needs and expectations, and progress from your competitors.
If any product managers or user researchers feel that there is something critical that should be added here, please comment and share!
Good luck!
