Lessons from PM & UXR collaboration
Part 2: What we learned from working on a new product project together
This article is a continuation of the case study we talked about working together as a UX Researcher and a Product Manager. It would be better to read that first. You’ll understand more about the project AKA faster horses - a project which helped set an organization’s direction and product vision. We will cover some of the outcomes and reflections from each of us on the project. Hopefully, some of our learnings can be built into your future project.
Outcomes from the project
Validated the direction without honing in on a design direction or specific solution too early
We spent time understanding the needs and mechanics. This gave us an understanding of customers’ concerns about the new concept. We uncovered sources of possible friction.
Insights were shared with the stakeholders identified above and other related engineering teams
They were fully up to speed throughout the project. There were no surprises when the final debrief and report was done.
Our organisation decided to further invest in this direction and adopt it as part of the corporate strategy
As a result, the next step was an in-person workshop. Collaborators flew in from all over the world to one location (pre-pandemic) for a week.
Make sure you know who the stakeholders are - both direct and indirect. If needed, create a RACI (Responsibility assignment matrix). List everyone out and ensure that your stakeholders suggest anyone else. Often stakeholder interviews can also uncover who may have an interest in the project.
Have a knowledge sharing plan. This is going to help you ensure that when team members leave the learnings from the project are not lost. It's not dependent on those who directly participated. We had a few critical team members leave soon after the project. It would have been good if we were more rigorous about documenting this all ahead so that would have been foundational knowledge for the team.
A UX Researcher’s perspective - what I learned
Out of sight, out of mind
When research is asked to cut corners, tends not to be valued as much. This is particularly the case when other people don’t invest time or thoughts into it. By getting the team more involved, the more invested they are. You are bringing them closer to the customer and their needs. Clear needs mean clearer product direction and value which is the priority for a development team.
Always involve your stakeholders. In the kick-off meeting assess the level of proposed involvement from your stakeholders. This will help you structure the project. Create interactive or creative debriefs. It'll have more mileage and be easier to remember than just a research report.
What I learned from working closely with a Product Manager
PMs have the context of the organisation's direction. Including business strategy, product-market fit, target customer and competitors in the space. This information is helpful to have from the outset to help have the full context of the project. You’re not just trying to do a project, you are trying to help conduct work that has impact and makes sense.
Build in a session of collecting existing data, and business context. Interview your PM or other stakeholders. The more the two of you are on the same page, the better.
Think out of the box for methods
The Product Designer we worked with visualised certain experiences we wanted input on. We used what they created for a "visual" card sort. These were cards with multiple factors that needed ranking. It was a great way to get feedback because it was clear and needed little explanation. The more explanation the more of a risk of biasing the research. By using this method, the participants deconflicted some competing needs and interests.
Additionally, we asked our customers to map out their current workflows. This showed us how they work right now including workarounds. Workarounds signify pain points and areas for opportunity. It showed us how they would like to work also. Mapping exercises remove getting caught up in giving design feedback.
Give customers some warm-up or mapping tasks. It helps to give this in advance. Use your interviews to dive into more details.
Predicted product roadmap
A good researcher should aim for their work to be strategic and influential. This research gave guidance on near term direction on this new product. It is also research that can be referred to years later. It’s not just feedback on a singular idea. The work collected needs, and was reported in several formats. We took a punt on this project. At the time we didn’t realise how pivotal and essential it would be. Run every research project as if it’s going to predict a product roadmap item. Tactical research can be up levelled to strategic research.
Always ensure your research report answers the original questions. Go back to your research plan to cross-reference. Then include all the other future/forward-thinking findings and insights also. Consider creating them as separate or different kinds of artefacts. The work won’t date as quickly and becomes more likely to be used on other occasions.
Making the outputs more flexible for different formats and uses
Project directions can change. If the research points out that the direction or product/feature is not needed, it’s not necessarily a bad thing. Writing up the research findings in such a way that can't scale makes the research disposable. It should be reusable and become part of organisation knowledge. That’s the difference between also tactical and strategic research. Tactical research means the findings are usually based on a particular design. They can be made more high level but a concerted effort has to be made.
Treat every part of the project an artefact, even a recording of a debrief. Structure your research to answer essential questions and related high level. Your work will be more reusable and more valuable.
Knowing what value you can bring
A researcher should review the goals and hypothesis to suggest appropriate method(s). It’s important to make sure that the project is visible, with clear updates.
Aim to consistently increase the number of research methodologies you know. It helps to not overly rely on interviews. They only take you so far and not every project calls for it. In this project, my manager suggested a different method and it’s now another one I can use. Set up clear forms of updates based on stakeholder preferences. For example Confluence, emails or a Slack channel.
A PM’s perspective - what I learned
You may not always get the user personas you are looking for
We initially segmented customers based on their user behaviour. When we interviewed them, we found that the data gave us a wrong impression. The interview questions had to be tweaked in the session based on the persona the customer turned out to be.
Create a laundry list of questions. It should have your core set and extras if there's time or you need to change tactics based on your customer. Allow your customers to share their perspectives or take you off course. Be flexible with your questions.
Recruitment is hard for a new concept
What worked was reaching out to customers who are visionary/innovative in their expectations from the product. We also processed customer support tickets and community posts. This helped to find people whose pain points could be addressed with the new concept. We identified and recruited them based on their account manager nominations, usage data, and interactions with our organisation.
Develop some attributes regarding your customer base. Some should be must-haves and others nice to have. Some of these attributes should be easy to measure e.g. logs in 3x day. Others might be based on behaviour or non-measurable attributes. For example, customer tends to be innovative or always looking for the next new thing. The latter will be harder to identify. You can include some questions either in your recruitment screener. Your Success Managers (if you have one) can help with finding them based on their familiarity with their accounts.
Socialise the insights in an easy to understand format to motivate your team
Related to the previous section on flexible and different formats - use insights, raw comments and video clips to engage your stakeholders and teams. Raw comments and videos also lend authenticity to the story. Short of participating in a live interview, this is another way people can hear directly from the customers.
We used the insights to communicate the value of faster horses to the product, engineering, design and marketing teams.
Set up your project in a way so that it is easy to generate these different formats. For example the team got briefed on taking notes in a raw form so we had a transcript for exact quotes. These quotes were also used for customer journey mapping which we had in our “war room”.
We also agreed upon tags and their definition so no matter who is helping they are all on the same page.
What I learned from working closely with a UX Researcher
It is important to kick off a project with a prioritised list of hypotheses that help to define the research plan. We had discussions and meetings to get this listed out and organised.
Spend time finding and reviewing existing research. We were able to tap into existing research insights and secondary research for low priority hypotheses. In some cases, we pushed it back to the next round of research.
Collect a whole list of hypotheses and then prioritise them for the ones the project must answer.
Spend some time doing desk research - find existing research, data and internal organisational knowledge.
Thank you for reading the article! You can help us:
Subscribe using this button
Share this directly with your peers and others who will find this helpful
Share this article on your Social Media (Twitter (we’re @readaskwhy), LinkedIn)