Arranging the priorities during the product development process is a basic but crucial ability for being a qualified product manager. However, one more annoying problem before this is distinguishing between real user needs and pseudo needs.
Especially when there are too many stakeholders around you, these pseudo needs sometimes sound charming and seem to make sense. The other common situation is that we know this is a pseudo need, but it is from our main customers or boss. Therefore, how to refuse it convincingly and efficiently?
According to my experience, it may be divided into two steps:
The first step: ask the right questions to filter rapidly
1. Back to the need itself: think "out of the solution" and see what the real user needs are.
How well product managers understand their products and customers is often reflected in this stage. The more we understand, the easier it is to see through pseudo needs. However, although this is a question that I ask and answer to myself anytime, it is not necessarily the main direction suitable for discussion with stakeholders at this point, which may make both stuck here for too long.
2. Data-Driven: find data to support this need and judge the urgency.
- User scale: how many users encounter this problem? Are these users in the same category? Are these users paying users? Are these users key users in the future strategy?
- Frequency of scenarios
- Benefits: tangible (revenue, data), intangible (user experience)
- Confirm directly with the users: questionnaire online
3. Effectiveness and efficiency
when considering a solution, I usually think step by step in the following items:
- Prioritise time, human resources, and technical costs
- Corresponding to the current product strategy: product managers who are flooded in the details can easily overlook the importance of strategy. The product managers should grasp the strategy in each stage, propose data support, or adjust the strategy based on the data.
- Competitive analysis: Is there still room in the market? How to be better than other products? The competition analysis report does not need to be a complete version of the white paper, as long as it analyses the key points that you want to compare now.
- Is this optimisation of existing features, or we need to develop new features?
Overall, I would go through data support, effectiveness, and efficiency to do needs filtering in the first stage.
The second step: use tools
However, if our stakeholders still can't imagine the entire picture, what other practical and visual methods could help them? This is the benefit of using tools, which can assist in visualisation and showing overall evaluation.
Radar Chart
Radar charts can display multi-dimensional values, which lead us to glance at each connotation of a subject. So it is a highly efficient tool when our goal is to simultaneously show the values of different dimensions. Also, it can perform multi-objective comparisons in the same graph. From user needs exploration, goods analysis, and comprehensive ability assessment of employees, these kinds of topics with multi-dimension are suitable for interpretation with Radar Charts. Also, we can make Radar Charts through Excel, which is a friendly method even you are a beginner in product management.
How to make a Radar Chart
1. Determine each dimension
Basically, the questions asked in the first step can serve as the dimensions here. The following six that I usually consider, but not a must. How deep/ wide to consider depends on three points:
- The stage of development: this product is on the start-up stage, positive grow up, or needs some breakthrough?
- How much work we need to do: if our cost is not high, do not waste our time analysing too many dimensions.
- Uniqueness: do not forget to consider the uniqueness of the products themselves. It may be a special advantage or a hidden disadvantage. Add this special item to be one of the dimensions.
A. User scale
B. Frequency of scenarios
C. Tangible benefits
D. Intangible benefits
E. Influence in the future: combined with strategy and market.
F. Extensibility: can be reused or added value.
2. Give scores: 1-10, and explain the reasons.
3. Set the weights: the importance of each dimension will change according to the different stages. (If the frequency of users opening our product is now the primary goal, then the weights of "user scale" and "frequency of scenarios" may be assigned high weights at this stage.) However, determining the percentage of weight in each dimension is not easy. Therefore, I usually make several fine-tunings of weights and confirm that the conclusions are still the same after these few fine-tunings.
4. Set the average score of each dimension: such as 6.
5. Calculate the values of threshold and needs in each dimension.
6. Depict a radar chart depending on the scores above.
7. Compare the size of the need area and the threshold area. If the needs area is relatively large, which means that this is a real user need. But in this case, the yellow area is smaller than the blue area, which means this is a pseudo need.
I suggest that when the two areas are very similar in size and cannot be visually measured, it is not necessary to calculate the accurate numbers (by trigonometric functions). It has shown that its urgency and importance are not high, even if this is a real user need. Therefore, ignoring this requirement and choosing to focus on more meaningful features at this moment is a better action.
After going through these two steps, I hope that it has helped you identify real user needs and pseudo needs and visually present the current overall considerations to convince stakeholders.
We have dealt with how to judge between real user needs and pseudo needs. The next goal is to tackle the reasons for causing pseudo needs so that it is possible to avoid its happening from the fundamentals and also consistently optimise the standard process of acquiring user needs.
Let us focus on the role of soft skills and methodology during this process:
Soft skills
Here are two common reasons for causing pseudo needs:
1. Opinions from powerful stakeholders:
This customer is very important, so your boss insists this function is priority one in the next sprint. However, you know this is a typical condition called over customised, which may cause the core path of your product to tilt. However, it may also be a minimum viable product when we are in a start-up team.
> The solution: analyse this is over-customisation or a minimum viable product.
2. Adopt the opinions of users but ignoring to analyse users opinions
Users encounter difficulties during their user journey, so we got solutions from them. This sounds great and useful though, it is a usual reason to trigger pseudo needs because maybe there is a more efficient method to solve it, or the cost is too high, or sometimes you shouldn't get a specific solution from the user. Old example: users only want a faster horse. How can they think of a "car"? Before the invention of the tablet, how could users think of a computer without a keyboard?
> The solution: a standard process for collecting user needs and solutions must be established, including classifying the solution's source and analysing the optimality of the solutions through studying user needs.
There are too many reasons to result in pseudo needs. So the key point is that if product managers have the ability to perceive the real issues behind in different scenarios and react to the situations with excellent communication skills. Then it is possible to find out the solutions.
Methodology
We may have read too many methodological frameworks, whether in books or on the Internet. They do provide a shortcut for us to become product managers. In my opinion, it is a brilliant method to deepen the correct concept of the user needs by sharing different methodologies/ models/ theories of product development through each product presentation. As a Scrum Master, the product managers' responsibility is to share knowledge implicitly with the team members. However, do not expect to use them to deal with the situations of pseudo needs. It is not realistic and inefficient.
Think about it:
- A long, logical, and descriptive suggestion with rich methodologies.
- Ask the right questions to bring out the key considerations currently + "Needs Exploration" through data visualisation.
Which one is easier to solve the current dilemma?
So, next time if you hear that someone says: the stakeholders always do not listen to his/ her suggestions. Observe his/ her ways of suggestions!
Conclusion:
If we do not have the ability to ask the right questions, we still cannot choose the right dimensions for analysis even if we use tools.
Tools are an excellent means of analysis and persuasion, but sometimes we may accidentally simplify key parts. Therefore, cultivating soft skills, methodological literacy, and asking key questions are the fundamental abilities before adopting tools.
Reference: http://www.woshipm.com/pmd/794641.html