Since I launched ikooloo on the App Store and Google Play I’ve had, oh, a handful of people ask me why I’ve done this so early and with an unproven product.
The reason for the question has varied wildly. I’ve had people asking out of idle curiosity, people asking because they are generally interested and people asking me with a sense of indignation/disgust, accusing me of breaking some unwritten rule about releasing software.
The truth, as is often the case, is simpler than it appears – I was blinded by the process rather than by what my customer would expect.
The idea of testing an app before you release it fully makes sense right? It’s absolutely the thing to do and you’d be mad to consider another route. This is the way we started but we quickly hit a roadblock. Then another. Then another.
In theory, the standard approach works well – especially with a tech-savvy crowd. Build your app, put it on testflight, get some people using it, iterate improvements build up your beta crowd and try to generate a buzz. Right? Nope.
The three roadblocks we hit were:
- Your app isn’t visible on the app store
- In the case of releasing for the iPhone anyone wanting to test your app has to download the Test Flight app.
- You can’t test payment.
I didn’t believe either of these issues would present the challenges they did and – as I said – the tech-savvy crowd didn’t have too many issues, but for others…
A lack of visibility equals less trust.
Because the app wasn’t listed, people who I knew less well, weren’t used to the process or just weren’t technicall inclinded didn’t appreciate the process and it impacted their level of trust.
Once I discussed this with a few people the lack of a visible listing caused confusion “What? You have an app but I can’t find it on the AppStore?!” but, more importantly, it appeared to put a doubt into some people’s mind as to the quality of the app (they assumed it would be very buggy) and my commitment to the app/business.
Trust is a huge factor when launching a new product and anything that reduces this, even slightly, just didn’t feel right.
An additional app overcomplicates the experience.
The download of the Test Flight app caused a bigger challenge. The conversation went something like…
[ chat and introduction to the app which led me to ask…]
Me: “Would you be willing to test the app?”
Potential tester: “Sure, what do I need to do”
Me: “It’s pretty simple – you give me your email address, I add you to a list, you get an email from Apple telling you to download an app called TestFlight, you download the app and then enter your ‘redeem’ code, which, if it recognises, will result in ikooloo being available. You then download ikooloo and then you have to connect to Twitter or Facebook to actually use ikooloo.”
Most people fell asleep about the time I said ‘download an app called’. I know this because they either said “What? That sounds really complicated” and I ended up doing it with them on their phone or, more likely, they said “That’s fine” and then actually didn’t bother downloading ikooloo or I had to go through it with them on the phone (which is WAY more complex than doing it in person) because it didn’t make any sense to them.
You can’t fully test until people can pay.
One of the biggest mistakes I think startups make is confusing people who say they will pay for people who actually do pay. In the early stages, it’s easy to find people who will tell you what a great idea you have and say “I’d definitely pay for that”. It’s only when you ask people for money that intent becomes action.
We partly hit this roadblock because of the decisions to a) go mobile-only, b) provide a free download and c) handle payments using in-app purchases via Apple or Google.
When testing, both Apple and Google ‘test’ subscriptions using no or very small amounts of money and the subscription lasts hours. I found that people were committing but I couldn’t be convinced it was a real or lasting commitment or belief in the product. It also added more confusion, especially to the less technical.
We could, like many (most if not all) SaaS companies, have built and taken payment via the website. The reason for that is probably another blog and, with these choices made, the ONLY way of asking people for REAL money was to launch the app.
I think if we’d have hit one of these challenges we probably could have overcome it. But, after going through the same process with the same questions, conerns and conversation about 20 times it dawned on me that I didn’t have to do it like this. Why not just release/list ikooloo fully?
And, although it’s very very early ( I literally listed 10 days ago and have hardly told anyone or done any marketing ) I am already seeing the benefits.
It’s an easier conversation.
Now – I just give people a link (here’s one for the App Store and here’s one for Google Play) to download the app. The conversations about ‘trust’ have almost gone away. I still have the gap that every startup has but I’m not adding to it unnecessarily.
It’s an easier conversion.
Giving people the link to the App Store or Google Play means that I can test the experience as it really is. It’s the same on both platforms and the feedback is based on the real experience, not a false one so helps me to understand how I need to improve the on-boarding.
It’s more difficult conversion.
It’s only now that I am starting to have real, informed conversations about what people will and – more importantly – will not pay for. Almost every conversation I had before this was ‘false data’.
It’s true to my customer.
I started with the standard process simply because ‘that’s the way it is’ but, in all of this, I forgot who my primary customer was/is. I became (slightly) obsessed with the process, what ‘product’ did I have? Alpha, beta or MVP as each dictates the process – the reality it is doesn’t matter.
I now have a version of the app that is raw, a long way from where I want it to be (against my ‘vision’ for ikooloo) and, yes, I am slightly embarrassed by it but that’s the whole point. But, perhaps most importantly it’s there and I can test the first/alpha/beta/mvp version in the real world.
So whenever you’re faced with a process that you are familiar with, don’t be led blindly – what’s most important is who your customer is and what are they expecting.
So, am I betting on my beta? You bet I am… What are you betting on?
How did you release your app? Did you follow the standard process or tweak it to your own benefits. Tell me what you did.
Thank you and please get in touch if you have any questions or thoughts!
You beta, you beta, you bet…
The Who released ‘You Better You Bet’ (see what I did with the title there 🙂 on 1981 on their Face Dances album and it instantly came to mind when I was writing this blog. Why not watch this Youtube video of them performing the song a couple of years ago from their Hyde Park concert…