Category Archives: Lean Startup

Talk: “The Wheels of Value Model: Driving Product Ideas to Their Fullest Strength”

The Wheels of Value Model is a tool for driving product ideas to their fullest strength by systematically unearthing critical product assumptions. Instead of identifying assumptions for each element of a business model it generates a closed value chain among the right actors and ensures that you do not miss important links. By doing this you can rapidly see what you need to validate. This talk explains the main elements.

Presenter: Prof. Dr. Jürgen Münch
When: 16 Sept. 2015, 10:15 am
Where: Pori, N4SQ3, Yyteri Hotel, Finland

wheels of value excerpt

How to Find out Which Features to Implement in Popular Smartphone Apps?

In the world of smartphone applications, there is a rich set of user feedback and feature suggestions which are updated continuously. Especially for smaller development teams, prioritizing these requests is of utmost importance. The prioritization is usually done based on techniques which rely on methods that are built upon predictions and customer interviews such as “Would you buy that feature?”. However, predictions can be wrong and customer interviews suffer from contextual biases.

We developed an approach that allows us to find out about the real business value of a feature. The approach is based on mock purchases and allows product managers and developers to depict the real business value of a feature without having to implement it. Hence, the approach allows feature prioritization based on facts rather than on predictions. The rationale behind the approach is to eliminate contextual biases. On top of that, the approach allows us to experiment with the feature pricing.

approach

Figure 1. Approach.

Figure 1 depicts six elements of the approach:

Product Backlog: Each user is assigned only one of the features from the backlog that are to be tested. Thereby, potential contextual biases can be reduced to a minimum.
Description Page: For each feature, a custom description page is created which describes the feature and contains a button to load the feature’s price.
Purchase Page: After loading the price, the amount is displayed on the page and a purchase button appears.
Acknowledgement Page: After purchasing, the user receives an acknowledgement about the feature not having been implemented yet. Moreover, the user is then asked whether he or she likes, dislikes, or very much dislikes the approach. On top of that, he or she can provide a custom message in case he or she needs the feature urgently or wants to complain.
Questionnaire Page: In case the user cancels the purchase (i.e. wants to move away from the page after having loaded the price), he or she is asked why he or she did so. Users can choose that they are not interested in the feature, it is too expensive, they were disappointed by other in-app purchases, or they do not spend money on apps. They can also provide a custom message.

The study was implemented in an app called Track My Life which is used by Nokia CEO Stephen Elop and the Finnish Minister for European Affairs, Alexander Stubb amongst others. The app is a GPS Tracker that automatically collects the users’ location information in the background and analyses the data upon opening the app. Thereby, it can answer questions such as “How much time do I spend at home, work, and on my way to work?”. On top of that, it provides statistics such as how many kilometers the user travels per day, week, and month, and which places he or she spends most of his or her time at.

Moreover, the app leverages user feedback by providing several mechanisms e.g a Zendesk and Jira client to provide feedback to the developer.

The study started on April 5, 2013 and ended on April 23, 2013. Prior to that, the implementation of the app in both the iOS and Windows Phone version was done. The implementation took about 1.5 days per platform due to specialities such as the possibility to enable and disable the study remotely and converting feature prices to the users’ local currencies in price intervals which correspond to their smartphone operating system’s pricing intervals (i.e. convert 1€ to flat 70 rupee rather than to 71.54 rupees). Figure 2 represents the implementation of the approach on iOS (left) and Windows Phone (right).

Implementation

Figure 2. Implementation on iOS and Windows Phone.

Finding the Right Features to Implement

Figure 3 depicts the number of purchases that were made as well as the hypothetical revenue attached to those. Each of the six columns represents one feature at a given price tag. In total, there were two features being investigated, each of those at the price tags EUR 1, EUR 3, and EUR 5. As an example, SSF represents feature one and the number 3 represents that the base price (i.e. the price that was converted into the users’ currencies) was EUR 3.

revenue

Figure 3: Number of purchases and revenue.

As anticipated, figure 3 depicts a correlation between the number of purchases and the price of a feature. Moreover, it allows us to compare the two features and also allows us to make judgements about the feature pricing. For instance, EUR 5 for the HF feature yields a lower total revenue than EUR 3. In contrast to that, the maximum revenue for SSF seems to be at an even higher price tag than EUR 5. Moreover, the revenue created with SSF is higher than HF.

tooexpensive

Figure 4: Number of users who said that they did not buy the feature because it is too expensive.

Figure 4 shows the number of users who regarded the feature as too expensive when surveyed about why they cancelled the purchase (i.e. tried to navigate back from the feature’s description page after loading the price). It underlines the point that there is a correlation between a feature’s price and the number of purchases and also that fewer users are willing to pay for the feature HF at a price tag of EUR 5 than for SSF at the same price.

14% of the users were unsatisfied (i.e. selected I dislike the approach) or very unsatisfied (i.e. selected I am very annoyed by the approach). However, the wide majority of users understood the purpose of the experiment.

We showed that the approach allows us to find out about the real return of a feature and allows us to find the ideal price of a feature.

The study is described in the following article and will be presented at the Lean Enterprise Software and Systems Conference in Galway, Ireland (December 1-4, 2013). The reference for the article is the following:

  • [PDF] [DOI] Alexander-Derek Rein, Jürgen Münch. Feature Prioritization Based on Mock Purchase: A Mobile Case Study. In Proceedings of the Lean Enterprise Software and Systems Conference (LESS 2013, Galway, Ireland, December 1-4), volume 167 of LNBIP, pages 165-179. Springer Berlin Heidelberg, 2013.
    [Bibtex] [doi] [url] [pdf]
    @inproceedings{LESS2013b,
      author    = {Alexander-Derek Rein, Jürgen Münch},
      title     = {Feature Prioritization Based on Mock Purchase: A Mobile Case Study},
      booktitle = {Proceedings of the Lean Enterprise Software and Systems Conference (LESS 2013, Galway, Ireland, December 1-4)},
      publisher = {Springer Berlin Heidelberg},
    series = {LNBIP},
    volume = {167},
    pages = {165-179},
      year      = {2013},
    doi = {10.1007/978-3-642-44930-7_11},
    url = {http://link.springer.com/chapter/10.1007/978-3-642-44930-7_11}
    }