5 ways user researchers can improve their value inside product teams
Improving the user researcher’s impact inside their product team is a common (and sometimes fiery) discussion I keep finding myself in. For researchers, we often talk about what good “outcomes” mean, how our work is (or isn’t) being absorbed, or where within the process we’re struggling to make a difference.
Last fall, I set about digging into this more constructively – I conducted a few internal activities at our Sydney office where I could get a good cross-section of product team member representation. After analyzing the results, I decided to kick off 2017 with a list of actions embedded researchers like me can take in the hopes of not just improving our impact, but building a stronger relationship between product teams and qualitative user data.
1.) The must-do first step: Change your internal dialog
In order to accomplish the rest of what I’m sharing in this post, you’ll likely need to adjust your perspective on how you view the work environment around you. You’ll also need to claim ownership of your impact and how your contributions affect the product and product team members.
What I’m suggesting here is to identify where your ego may be getting in the way of you furthering your work, and where you could gain some traction in imperfect situations. I’ve had about twenty career years to mature the cross-checking of my ego — and even after all this time it still creeps up in the most amusing ways.
What does it look like when I silence my ego?
It’s an alluring notion — applying your research skills in highly visible situations where you could potentially make huge changes felt across the company. It’s also misleading AF. Even the greatest attorneys typically have only a few newsworthy cases in their careers. The rest are their bread-and-butter cases. But the attorney’s skills are just as needed and just as important for those clients.
Because I want my work to have high value, I decided a while ago that I would be chronically disappointed if I continued to set my sights on nothing but high profile work.
So I reminded myself that a.) “high profile” is not the only place where my work is needed and b.) the work isn’t about me, it never has been. How sad and conflicting would it be if I became a user researcher who only wanted to do the work if it made me something greater? I then changed up my dialog…
Instead of asking:
I decided to take more accountability and reframe the question:
Once I assumed more personal responsibility for the “impactful me,” the more momentum I experienced in finding out where I could flex and apply my skills to service my team more completely.
2.) Turn the empathy you have for your users towards your product team members
Product teams moving quickly can often experience insecurities around the problems they’re solving. Sometimes there’s little assurance changes being made to features are valuable for end users. Don’t spend time trying to advocate for change at a higher level without getting to know your product team’s development process intimately.
By examining your product team’s process at a deeper level, you’ll see the journey through their eyes — discovering their needs, their gaps, and their gripes. You’ll then have a focused view into those areas where your work can help reduce risk, improve decision-making, and build confidence.
How did I approach it with our teams?
While in Sydney, I conducted a few journey mapping exercises with engineers, PMs, designers, and extended product team members. While participants filled out their journeys, I kept the quiet perspective of observing where the need for qualitative data was surfacing.
After analyzing the findings, I was able to pull together a series of product development journey maps including the following master map:
Getting a view like this together helped me see where I could now consider supplying qualitative intel across the development cycle. It also brought to the foreground key questions team members have such as:
How do I know this problem is important to the user audience?
How do I know this problem should be prioritized over another problem?
How do I know the work we’ve done has made a difference to our users?
It’s one thing when I ask myself these questions when approaching my work. But when I consider them through the lens of my team members, I feel more driven, more purposeful, more motivated in pulling together information that gives them answers they need.
3.) Start building the qualitative story by examining data from customer touchpoints
If you haven’t done so already, it’s time to identify the different touchpoints your product has and who’s collecting customer information during those periods. Ask for access to whatever tool your coworkers are using to store that data and begin searching for themes. If for some reason you can’t get your hands on that info, interview those in contact with customers directly. You may get lucky and have them present you with a report on their observations.
What are some examples of touchpoints?
- App stores
- Social media
- Customer support
- Product trials/demos
- Loyalty program
- Sales team
If you’re not sure how to identify your product’s touchpoints, check out this article by SurveyMonkey.
Pro tip: Make it a point to schedule a recurring time each month for you to dedicate towards gathering and reviewing this information. This will keep you up-to-date on trending expectations and pain points and ahead of the product development cycle.
By gathering this intel we start building a more comprehensive qualitative story for product teams. Subsequent research assignments become more focused and their outcomes more meaningful.
4.) Consider your next research assignment as you would a user — it has a journey too
Our work and our assignments actually have a journey. And if we think about it like that, we’ll want to follow their outcomes through the stream of the product development cycle.
If you’ve ever asked yourself “Why were my research findings not used?” this mindset will help you track down the answer. Based on what you find, you may learn something new about the business — a strategic shift that could be temporarily drawing focus away from downstream considerations. Or you may find your insights are needed but development resources are limited. Whatever the reasons are, you’re now much wiser. That sort of wisdom has a way of refining your techniques moving forward.
On the flip side, if your findings are being used, excellent! You’ll now want to know how they’ve made a difference, either for the business and/or the users.
How do you start tracking your work?
The next time you take on a research assignment, identify which stage of the product cycle you’re stepping into.
- Find out what nagging or lingering questions or concerns your teammates have about users. What assumptions have been made? I particularly enjoy talking to developers — they tend to care deeply about if what they’re building is important to users.
- Dig into the analytics or other quantitative data that’s available to you. How do the numbers map to the use cases your team has created? How does the prioritization of features being worked on look in relation to this data? What additional qualitative research could shed more light on interesting user stats?
- Construct your usual research plan but this time, include follow-up actions you’ll take when you look at the next stages of the development cycle. What behavior change do you want to see from users? What does success look like? Review this info with your team and start thinking of how you’ll collect and share those insights.
One way to help keep you focused on work that will give your team the most value…
Create a running user research backlog.
- Be sure to include what user problem research is going to help solve and how success will be measured.
- Have a place where you can capture what your team is prepared to do if the research shows opposing findings to forward momentum.
- Have your team vote up work they think is valuable so you’re making sure you’re taking on work that is both valuable and can be monitored post-release.
After you’ve started tracking your findings, you’ll soon realize there’s lots of work to be done in addition to conducting research. This is an excellent position to be in — understanding how much of what you can do is truly impactful for both end users and product teams.
5.) Be confident and clear about the role you play inside your team
Don’t relegate your job function to “Assignment. Method. Summarize. Share. Repeat.” You’re more than just a method. You’re the source that can bring a user story together, informed by both qualitative and quantitative data to help influence change. But it’s not the job of our teammates to know what to ask from us and when. And we don’t need to wait for others to tell us what we likely already know we should be doing.
If you’re not familiar with self-actualization, I suggest exploring it and what it may mean for your progression as an employed researcher. Sometimes we become distracted by things outside of our control and lose sight of where we can be immediately effective. It’s usually there when we stop actively investing in those other skills that make us invaluable to users, indispensable to teams, and incomparable in the job market. And that equates to the self-sabotaging of your own career.
So if you’re up to the challenge, read this post again except this time with the perspective that this is an invitation to invest in yourself. And feel free to join me in 2017 with this journey because I’m holding myself accountable for what I wrote here — and for my own impact. And I know that I will, in fact, fail a few times.
But if you’d like to go about this together, I tend to make a fantastic ass of myself so at the very least you stand good odds at coming out looking a bit better than me.
Did you enjoy this post? Want more of the same? Consider following Designing Atlassian.
