top of page
  • Writer's pictureMolly

How to distinguish between real user needs and pseudo needs?

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!



  1. 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.

  2. 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.



Recent Posts

See All


這裡的改版,指的是UI/ UX的年度調整,意在提供更符合趨勢的使用者介面,以及更順暢的使用者體驗,當然也可以藉此機會加入新功能,但我認為這不是主要目的。另外一個關鍵是,趁此機會將整年累積的「債」清理一番,無論是技術債,還是當時任何「不得不」的設計方案。 回到改版本身,不是所有產品都需要這樣的改版。有些產品,處於衝刺期,不斷地迭代、增加與完善功能可能更有意義。通常需要這種年度改版的產品,較是屬於平台


數據採集——追求數據品質的開端 有賴近年的AI熱潮,目前已落地的AI應用服務可說是都達到了階段性的成熟。在不可能總是期待演算法大幅進展的情況下,要在這樣的競爭態勢中脫穎而出,數據的質量更是成為兵家必爭之地。另一方面,因為許多應用場景高度相同,同一領域中的AI服務出現嚴重同質化的現象,這更加劇了對於數據質量的追求,以期許藉此能讓自家產品在這片同質化中突破重圍。 其中,大數據的觀念醞釀已久,人們對於「


bottom of page