Introducing Productboard Pulse. Exec-level insights into what your customers need, powered by AI.
From my personal experience, every great product team should have a user researcher (or a team of user researchers). While Marty Cagan and others talk about the triad, I’m a fan of four-legged stools, not those three-legged tippy camping chairs (no offense Marty) 😀. And frankly, researchers (and even great data people) just make everything better for product managers. So here’s to multi-legged stools!
As Steve Portigal said in his fantastic book Interviewing Users: How to Uncover Compelling Insights, “To design for users, you must begin with a deep understanding of users. If you don’t already have that understanding, you need to do some form of user research.” And as you may know from our content on Product Excellence, creating deep user insights is critical to keep a pulse on what’s important to your customers, seize critical opportunities, and avoid wasting time building the wrong features.
For this particular article, I’m going to focus on the needs of dedicated research teams — those working on broad research efforts rather than specific feature-level product discovery. While there are aspects of productboard that can work for every type of research team, the needs of individual teams can vary. Here are some ways I might distinguish between research teams and their use of productboard:
Broader user research teams
Feature-specific teams doing discovery
For dedicated research teams doing broad user research, there are often some common elements that are created and produced as part of research work. These may include:
So, where do you put this all, and how can you make it both accessible for your research team and helpful to product teams? Here are some ideas:
Within productboard, create a Product dedicated to your research team. For my example, I’m going to call this Customer Research.
Within that Product, organize your major research areas as Components. These could be areas in your company, product divisions, major research areas — the sky’s the limit. In this example, I’m just calling them Research Area A, Research Area B, etc.
Within those Components, use Features to represent each of your research studies. It’s best to come up with a standard way to name them so everyone can find them easily.
Within the Feature Detail, list your brief (or a link to it), add your raw notes and data (or a link to it), and attach relevant files and assets (or a link to it). Apply all the great feature attributes you would for any other productboard feature like releases, owners, teams, objectives, custom fields, and tasks. And don’t forget to use statuses to reflect the state of the work your research team is doing.
On the Features board, use columns to help provide a system of record for all your work, progress, assignments, etc.
Now here’s where it gets cool — turn findings to Insights
At the end of your research, there are findings. These are the actionable items that help to summarize the research undertaken and key learnings.
First, add the Insights to productboard. Leverage tagging, owners, and comments to help product managers get the full value of your work, and to add an extra layer of data when it comes to establishing user impact scores and prioritizing the product roadmap. Maybe you want to use a tag to identify research overall, the type of research, or the audience. Then you can use Collections to organize easy ways to get to that research.
Second, attach each Insight to the relevant research study (the features you set up earlier). That way your team and anyone else looking for a holistic overview of each study has access not only to the inputs and raw outputs of your research work, but also the output and actionable next steps — all in one single location.
Third, each Insight can be reviewed and processed by the product team and linked to a hierarchy they use for prioritization (you did know that you can link insights to multiple components or features in productboard, right?)
Use the Roadmap board to show the state of the research work your team is doing. Help others on your product team and across the organization get transparency into the status of your work, timelines, and progress towards objectives.
Use Release Groups to better organize on a cadence that’s relevant to your team and their work.
But what if I prefer to use my own tools to house research?
It’s perfectly fine to not use the above. You can opt to simply push insights from your research as key takeaways for your product team and store the broader work and conclusions elsewhere (e.g. Google Drive, Dropbox, Sharepoint, etc.).
What you can do in these instances is to look for ways to automate the sharing of insights with the product team.
I’d love to hear how you are leveraging productboard to conduct better user research. Feel free to drop me a note at scott.baldwin@productboard.com and we can find a time to chat!
