Shopify App Store. Guide to revenue. Product hypotheses

In Part 2, we described major product and growth metrics every app developer needs to track, why retention was not included in the list, and why it has no direct influence on the revenue.

People’s demands hardly change

The main task of a product is to test the value hypothesis, which shows how a product can improve the lives of potential customers through a new approach.

To promote a product that is based on a value hypothesis without proof and thorough market research is like trying to build a house without a foundation. If the hypothesis is not confirmed, the reasons could be the following:

• There’s no market demand; you’ve got misleading information about the target market or target audience.
• New functionality copycats those on the market.
• New functionally is cool, but people don’t know how to use it. (Can you share an example?)

What happens in product teams

Many product managers accept the value hypothesis as a fact without testing it. And some do it because they are afraid to test the value hypothesis. The question is: What should you do if the product is already funded but it has no real value? Others are so in love with the implementation of their product that they don’t see the slightest chance it won’t work.

Initially, the team builds its product model based on theoretical data and data from other projects. Next, the team conducts experiments, collects and analyzes data, communicates with users and develops expertise. By extracting information from the product, the team changes their understanding of it and its real model.

But very often in teams, each of its members has their own product model. This happens when the team is not studying the product model, or when the person who does it does not notify the team about the revised model.

One of the main tasks of interacting with the team is to convey to all team members the current product model and to change the perception of the product model among others, when necessary. The real work starts when you collect and analyze data on a regular basis. Before that the team is engaged in convincing each other with various arguments.

How to analyze users who have uninstalled the product

The questions to ask are:

1. What are the weakest points the users “leak” through? How do we find them?
2. How can we communicate with users to find out the reason for their leaving? Have they found the value we offer? If so, why did they leave?
3. Can we solve these problems? If not, then why not?
4. If we solve these problems, will users still use this product?
5. When problems are identified and solutions are invented, how do you understand that the solution is working?

Some questions that should be worked out with users who have stayed with the app, or at least have been using it longer than others, are:

1. What value do they find to stay with the product?
2. Does real value coincide with our value hypothesis?
3. Do we inform users about the real value?
4. Who are these users who have stayed with the application?
5. How and where do we attract such users?

When answering these questions with the help of data and user interviews, you will better understand your product and your user. As a result, the product model will begin to change and bring new knowledge and discoveries. If you qualitatively answer the above questions, then you will be able to form a new set of hypotheses and get a new vector of product development.

In some cases, you will understand that the project should be closed and this is normal. In other cases, going through the cycles of “experiments –> data measurement –> feedback –> experiments” will bring you to a successful product.

The key task of any product is to find the “A-ha!” moment – the moment at which the user realizes the value of the product.

Product workflow stages:

1. Analyze and record the current metrics of the application.
2. Analyze user feedback from comments that users leave when uninstalling the app. Feedback from the support team is also taken.
3. Analyze records of user behavior in the application.
4. Analyze competitors to understand how we differ from them.
5. Draw up a list of features and solutions to develop. After that, do a user survey.
6. Conduct interviews with 3–5 users (stages 5 and 6 may not necessarily be in this order; sometimes we need more data for the survey and we conduct interviews first).
7. As a result, we collect features/solutions that users need. Further steps can be:

• If critical bugs or needs are found, then we try to solve them immediately or postpone them in the plan for a partial or full update.
• If the list of necessary improvements is large, we try to find a compromise – a small update that could improve the churn rate.
• If the feature is not complicated and we can implement it in a fairly short time (within 2–3 weeks), then it is implemented.