Adding a fake feature to validate % of users willing to pay for a feature that might take 2-3 weeks and cost up to $3000.
A crosswords app I have worked on a while ago began to get traction and we thought that it might be a good idea to monetize it.
People left 1-2 star reviews saying that there were too few levels. At that point, we had around 10k+ downloads. We decided to add more levels but not for free anymore.
Our users used to pay around 4$ for a print version of crosswords and this gave us a bit of confidence moving forward.
My role was to find a way to test if people would pay for a digital version of their classic crosswords game.
My first instinct was to build this and see who pays for it, but after researching the effort required to build this for both iOS and Android and some ROI estimations I needed to find a cheaper way to do this.
This led me to create a fake feature test. It worked like this:
When a user completed x number of levels, show them a popup asking them to unlock access to new levels by paying $3.99 with 2 options yes and later. If they tapped on yes they would get a message thanking them for their interest and saying that will be available soon.
Of course, this still required dev work but thanks to Upwork I’ve managed to find someone to help me add this paying 35$. I decided to start with the Android version.
How so cheap? How do we register all the data? Where do you store it? And so on…
Well, I have created a Typeform where I created the logic and then embedded that as a WebView in the app. Ran it for a few weeks to collect more relevant data.
Got like 179 responses and the ratio was around 70% for “Pay later” and 30% for “Pay now” which was not great but encouraging enough to make me move forward with implementing an in-app purchase model allowing people to unlock new levels by paying a flat fee.
More about how I added the in-app purchase and how it went in another article.
Leave a Reply