From Zero to One with a Mobile App: Product Management Case Study
Executive Summary/TL;DR
Going from an initial idea to the first publicly available version of a mobile app requires a multitude of steps, which are covered in this case study: starting with discovery efforts such as research and prototyping, over into alpha builds, closed and open betas all the way to invite-only and open public releases.
Introduction
Disclaimer: For the sake of confidentiality and anonymity, all details contained in this case study (especially PII such as names, addresses etc.) are fictitious and don’t contain any details about the respective client. If you’d like to learn more, reach out to me directly.
In this case study, I’ll detail the process of work that I did for a client that started with the notion of adding a mobile app to its offering, all the way to the public launch.
Of course, it started with the idea of creating a mobile app — which always should firstly prompt a number of questions regarding the why, what and how of this desire.
Problem Statement
This should be your first reaction to someone saying “we should build an app!” Photo by Oyemike Princewillon Unsplash
Discovery
The very first questions to ask regarding planning a mobile app are:
Why do we need a mobile app? Put more precisely, why would the specific characteristics of a mobile app benefit our intentions (also, why now)? This answer cannot be trivial, such as “everybody uses their phones nowaways” and “everyone does apps right now”.
What should the app (not) do? It’s important to consider early on what the app should make possible (and for the sake of focus, what’s beyond it).
How are we/the users benefitting from this app? Similar to 1., but more focused on the outcome than the input – product-market fit, if you may.
Planning
Aside from all the necessary discovery work, we also had other questions to answer, such as:
Who was going to build this app? We obviously didn’t have any mobile app developers on staff.
What phases did we intend on covering? We couldn’t just “build & release it”, it does make sense to consider possible steps and junctions.
How long were we approximately looking to take for these phases? Timelines aren’t popular with the Product crowd — I believe they should be. Time is a scarce resource, and you should rather be flexible on scope and firm on time than the other way round.
Solution
Mobile App Characteristics
The mobile app format definitely has its upsides and downsides. Photo by Raymond Pang on Unsplash
Now, here’s a little cheat sheet of sorts — while each case is individual, generally mobile apps have the following strong and weak points:
App Advantages
Apps are firmly installed on people’s personal devices, so they enable a deeper and more tied-in connection to the user than e.g. a website.
Apps can provide a lot of possibilities to provide a very tailored, immersive and customized experience.
Accordingly, apps work best with a company’s or brand’s loyal constituency (‘super fans’).
App Disadvantages
Building, maintaining and updating mobile apps is much more resource-intense than a regular website.
Given the limited hardware and screen real-estate, apps are usually not useful for ‘power users’.
A certain amount and type of users are averse to installing apps on their phones and will not install it (or only begrudgingly do so if they really don’t have another option).
In summary:
Apps work best with strengthening ties with your fans, and work worst with your casual/skeptical constituency.
Given that the client wanted to pull their ‘inner circle’ closer, the app as a means of technology checked out as a valid concept.
App Features
Photo by Niclas Illg on Unsplash
Leading with the obvious — using a mobile app to merely offer a logged-in version of the mobile website was out of the question.
While we maybe would’ve been able to get a couple of people to install it and raise impression/retention metrics by being able to push updates to people’s phones, this wouldn’t just be a rather substantial waste of time & resources, but also an embarrassment for the client’s brand and reputation.
We had to find at least 1–2 tangible benefits exclusive to the app — which prompted extensive user research we had done by an agency.
App Benefits
The agency’s research revealed a lot of interesting information (which unfortunately I of course cannot share here, but trust me!).
We were able to learn what kind of benefits the (potential) users were expecting, and they overlapped well with both the client’s core competency and the intention behind the project —
people were basically saying that they would love to hear more from the company (about specific things)!
Accordingly, our plans of ‘keeping our friends close(r)’, both expressed in attention and revenue goals, were aligning nicely.
Prototyping & Alpha Build
When the concept was done and we had contracted an agency to build the app, we set out to build an ‘alpha version’.
The purpose of this step was to exercise on the concept work and technical evaluation by building a first ‘proof’ of it—essentially blending concept and implementation work in an efficient way.
This version was not disseminated, not even internally, and was only available by the team working on it, as well as the C-level stakeholder.
Closed Beta
As we progressed, we defined a state at which we felt ready to open the app up to a beta crowd.
As we didn’t want to test on end users before a public announcement and we needed qualified feedback, we defined the client’s staff as the beta population, sending an announcement & call for participation around internally.
Fortunately, it wasn’t difficult to reach our target of 50 beta users, staff members were happy to join in & provide feedback.
With platform tools provided by Apple and Google for their respective App Stores, it’s quite easily possible to distribute a closed beta and collect feedback — both technical (e.g. crash statistics) and written.
Invite-Only Release
Photo by James Bruce on Unsplash
After further iteration with the beta group, we approached confidence to release to the public when the C-level stakeholders were satisfied that all the necessary parts were in place.
The big question left was: should we do an open release, or an invite-only one?
While an invite-only strategy can have the benefit of building hype and providing an additional safeguard regarding who’s being let onto the app, it definitely also is an obvious deterrent (as not everyone can sign up) and can impede (or even kill) a release’s momentum.
Weighing our options, we decided for an invite-only strategy.
Invite-only releases are a little bit more complicated than beta releases, though — app stores generally don’t enable you to limit who’s able to download an app (but there are workarounds), and the app being downloadable but logins being invite-only (and needed to use the app) might also be a bit of an odd presentation.
We used a short invite-only phase in which we unlisted the app and required a login to use the app, which was only available for 200 people. After that, we opened up login and registration to everyone.
Results
Photo by Jakub Żerdzicki on Unsplash
By proceeding the way that we did, we were able to successfully launch our app:
We were able to stay within our time frame expectation as we had continually (re-)negiotiated with C-level stakeholders and thus release on time and on (said re-negotiated) scope.
We mitigated a multitude of risks (e.g. bugs, lack of product market fit, flopped marketing) by iterating constantly.
We got thousands of users within the first week (which was the target — long-term target was actually a three-digit amount of DAUs).
Most fundamentally, nothing broke (at least not substantially).
Conclusion
If you’re looking to build an app from 0 to 1, feel free to steal this template — otherwise, I’d recommend you to bear these 3 essential things in mind:
At the outset, one step forward means taking 3 steps back: ask yourself the why, what and how of the idea. If the result is that an app doesn’t make sense for your case, that’s completely valid! Actually, I’d find an educated recommendation to not pursue something highly preferable to a rushed and/or biased one to do it — and even if your stakeholders might not act the part in that very moment, they ultimately do, too.
Make sure to familiarize yourself with the mobile app-specific release & management tools early on, such as Apple’s App Store Connect and Google’s Play Console — they provide tools for versioning, provisioning, managing submissions, analytics and much more.
I can’t repeat this enough: Stay flexible on scope and firm on time. For more why this is the only sensible approach, feel free to check the respective chapter in Basecamp’s Shape Up:
Thank you very much for reading!
If you’d like me to help you with a similar challenge you’re facing, I’m a Freelance Product Manager & Consultant for hire — feel free to reach out to me at hi[@]bertrandrothen.com