User Value Original Theory

The motto "user-first product development" is something you have probably heard at least once if you work with products.

However, there are not many organizations that are able to realize user first as if they were breathing the air. There is a high hurdle to be constantly reminded when planning a product, identifying user issues, creating PRDs, and finally being able to confirm that the product is valuable to the user.

There are several reasons for this. For example, it is not enough to solve the user's problem to make the product viable; if you do not utilize the company's assets and strengths, it will be unclear why the entire company is involved in the project. Conversely, if some asset or strength is not utilized, it will not lead to differentiation. As a result, the company will start thinking in terms of its assets and strengths, and will not be able to verify whether it is solving the user's issues until later.

In addition to differentiation as a product, the business must be viable, and the focus may be on profitability first. As an organizational challenge, in organizations that have achieved PMF, the sense of team unity fades, and the product and business begin to operate as separate organizations. As a result, it is often the case that the business side is not able to build a process that directly reflects the feedback it receives from users in the product.

Even if a process has been established, the goals of the product and the business differ in terms of the realization of vision through the product, the realization of user value, and the achievement of sales targets. Theoretically, the medium- and long-term goals are aligned, but the lead times of the goals are very different, and it is difficult to reconcile them.

Thus, even if we talk about the importance of "user first" in a few words, it is not easy to achieve it because of the structural issues that exist in practice.

Process from discovery of user issues to value creation

I would like to focus a little more on user value, and look at the structuring of the process to realize it.

First of all, user issues are subjective issues based on the user's situation, and are verbalized by the business side, which is usually in contact with the users. Then, as a preliminary step in the planning process, the product manager collects issues from dozens of companies regarding the theme to be addressed, and when the issues are divided into certain user segments, they are found to be highly objective issues that can be seen as common denominators.

Next, rather than just treating the issues as issues, the product manager will consider whether it is possible to provide value to the users through the product in response to the highly objective issues. At this point, the product manager will be thinking about individual, specific issues, but will also be considering issues with a high degree of objectivity.

On the other hand, the final user value is whether the product has substantial value when users use it in a specific and individualized way. We will verify the value of the product by having users use it directly through prototypes, or by selling it as a beta version and conducting test marketing.

The process up to this point is organized along the two axes of subject (business side and product side) and target (issue and value), and the process is plotted as follows.

When we speak of user issues and value, the above process is followed while changing the subject and target from the user's individual specific issues to the realization of value through the product. No matter which piece is missing, it will not lead to the eventual realization of user value, and it is necessary to carefully clear the issues one by one.

Usefulness in Practice

By following the above process, it is possible to understand where there is a leap in recognition, where the baton is not being passed on, and where there are bottlenecks in the final derivation of user value.

For example, if (2) the issues are not abstracted, there will be little consistency between the user's specific issues and objective issues, and products will be planned for specific issues, so the planned products will be less versatile, but more likely to stick with specific users.

However, since the issues are not well abstracted, it is easy to judge that the scope of the product is small and that there was no impact on the realization of the product when compared to the product vision. Product managers should not only summarize the abstracted issues in the PRD, but should also link the real voices of users, such as a list of user feedback and interview notes, directly to the relevant parties. In this way, they can check each other to see if there are any leaps in the abstraction of issues.

Next, (3) product planning that is not done in response to objective issues refers to cases where planning is not based on user issues, but rather on the company's assets and strengths. This is a planning method that is often taken by companies that have a lot of knowledge about the industry and the company's assets and strengths, but because it is not based on the issues, the method of provision is product-out, and even if released, the result is often that users do not follow or the product does not sell at all.

To counter this, PRD should clearly state the background and user issues at the beginning of the PRD, so that it is easier to make an issue-based plan. People like to think of ways to do things, so awareness of the issue is easy to drop, and it is effective to make the process as simple and natural as possible so that people can start thinking about it from the issue.

Furthermore, it may be the case that (2) abstracting the issue and (3) planning based on the issue are done, but (4) not providing value to individual concrete users. This means that although (2) and (3) can be achieved when viewed individually, when the product is finally used by the user, it does not solve the user's individual problem and does not lead to the creation of value.

For example, if the user segmentation is too broad when implementing (2), the product makes logical sense, but is highly abstract, and cannot be utilized by specific users when they use it.

This argument goes along with (2) and (3), so it is a good idea to first have the business side, which is in contact with the users, review the prototype and have some users use it as well. It is also effective to release the prototype in phases, such as alpha and beta versions, and get user feedback each time.

It is also effective to collaborate with the business side at this point in order to align the sense of goals. Although there may be cases where it is not possible to review prototypes due to the size of the project, it is possible to expect a certain level of effectiveness by simply linking a demo with a video or the final PRD.

As mentioned above, by making sure that the linkage between (1) understanding the issues and (2) abstracting the issues, (2) abstracting the issues and (3) planning user value, and (3) planning user value and creating specific, individualized user value, is firmly confirmed, the user first will ultimately be realized.

Conclusion

Starting from the user's recognition of the issue, the baton is relayed through the subject (business side, product manager) and the target (issue and value), ultimately fostering a user-first product and, ultimately, a culture. This process is more difficult than one might think, as the eyes and goals are different, and it is easy to lose the linkage between the two. It is not something that can be achieved simply by raising the slogan "user first," but is a fruit that can only be obtained by a company that has focused on the interrelationships of each of its products, starting from the user's issues.