How to use HMW and affinity mapping to plan your product roadmap
Google sprints truly helps solve big problems in a more collaborative approach but sometimes its difficult for stakeholders to shell out that amount of time and yet guarantee a great immediate/long term outcome.
So here is my take on doing a yearly, half-yearly & quarter planning, thus building your product/business roadmap.
Step 1: Identify all the key stakeholders and let them know how responsible they are for their valuable inputs and feedback.
If you are a B2B SAAS company, make sure to involve the clients as well. They are well aware of their product, user needs and about your product’s shortcoming and competitors USP’s
Step 2: Between the PM, EM and product designer, split out the stakeholder interviews. (The activity is fairly simple and can be conducted by any enthusiastic moderator keen on solving company problems).
Step 3: Inform the stakeholders well in advance about the upcoming interview. Give them time to collect their thoughts, ideas, problem statements by themselves and from their respective teams.
Step 4: On the day of the stakeholder interview, collect all their problem statements in form of “How might we? (HMW)” These are your topmost burning problems to be solved at the various User Journey stages.
HMW is a great approach to identify problems and not jump to solutions.
In case of company-wide system design based problem identification, we can collect problems over a service blueprint, to cover all user/customer Actions, front stage/on stage problems, backstage and support interactions. This help look at a bigger picture.
Examples of HMW
How might we set the right expectations of a customer support bot?
How might we enable users to communicate and converse in their comfortable language.
How might we ensure the user doesn’t leave after a certain message?
Step 5: After you have collected all of the HMW’s, you can then do a quick affinity mapping and group the problem statements together to form the workable problem statements along with the various hypothesis.
Step 6: Refine and define these workable problem statements and measure them on a 2*2 impact vs effort matrix.
You can measure the impact of a the workable problem statement by the number of times a certain problem statement was emphasised upon or requested for and effort required is an approximate judgement of research, design/solution, validation & development.
What you now have is a roadmap of problem statements with the ready to define PRD/BRD (workable problem statement and its possible hypothesis along with their priority.)
These scenarios are your base hypothesis which not only need to be validated by user research or data analysis but also need to be worked upon to provide a quantifiable output.
This is also the instant where you can share previously tried/tested methods and solutions or any other resources that might help any member working on this project get aligned.
If certain hypothesis are of great impact and effort, and these could lead to possible new features, then it should be assigned a good amount of time for validation via data and user research.
Step 7: Plan user research to validate this hypothesis and do a data analysis basis of the current quantifiable metrics to see how can we measure the performance of a feature or problem statement.
Once you identify and understand all the metrics you can work with the PM to decide which metric is our final goal to improve. It can be multiple metrics too.
Step :8 Get started with the product design work of research, define, sketch, decide, prototype and validate. (Ref to my other article on how to tackle the cross functional design-product collaboration & design project planning)
This activity ideally should be done yearly, half-yearly, quarterly to make sure the whole team/company is aligned and working towards the same goal. Also, it helps pivot basis of the burning needs and also make stakeholders equally accountable for the direction of work for product/team/company.
To achieve the right goals, its important to:
Diverge >> Converge >> Diverge >> Converge
This should happen not only at design level but also at product/business level. It helps prioritise the right problems and build a product/company roadmap.
In earlier times a BA (Business Analyst) would take up such roles and responsibilities but now the trends are moving in the direction of a service designer/product designer role(What’s the buzz about? Chime in your thoughts in the comments below)
What approach does your team/company follow? Would love to hear about it.
