Your App is not a Xmas Wishlist

Thomas Jaussoin
Lunabee Studio
5 min readMay 25, 2016

--

Focus is key. 1 app = 1 (awesome) feature. And here is why.

At Lunabee Studio, the 2 co-founders and I spent time in Asia, Europe and the US.

We worked on large and small software projects, with large corporations, medium ones, and startups.

There are many cultural differences between all these regions and structures. There are also variations in terms of mindset, and obviously structural and organizational differences between a large corporation and a startup.

But there is something pretty universal when you start working on product features: this is what we call the Christmas Wishlist syndrome, which is a nightmare for mobile Apps.

What is the Christmas Wishlist syndrome?

It’s when you want to please everyone, and fantasize on what your users will expect in your product.

I guess it can apply to all types of products, but let’s focus on what I know: software, and mobile Apps in particular.

The Christmas Wishlist represents the superset of all requirements/features/ideas that your project’s participants wanted (dreamed of) for your future users (that you don’t have yet / don’t really know).

It starts when you decide to involve too many persons to participate to brainstorming sessions. And icing on the cake, it starts running out of control if the “product owner” can’t refuse bad ideas from top management and key influencers for (bad) political reasons.

So at the end of the day, you end up with a large list of features/services, with no particular coherency, nor any logical grouping. A big mess.

Let’s see how to fix that.

The ninja team: high velocity

Before starting anything, the best way to move forward is to create a small core team (max 4 persons), with a deep knowledge of the underlying service and business. They have carte blanche.

Second step, you need to define what the top service of your app is. It must be obvious and super sharp. Let’s talk about the (fancy) Minimum Viable Product now:

MVP: “P” stands for Product

At this step, you define the Minimum Viable Product. It’s obvious to say, but we’ve heard so many wrong interpretations of what a MVP is: the “P” stands for Product, not Prototype (nor Player ;) ).

Let’s quote Eric Ries to have the official definition:

A Minimum Viable Product (MVP) is: “[the] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort” — Eric Ries.

What does it mean? You’re going to create the first product you can “test” with your customers (learnings would be biased with a prototype).

This is the first step to start interacting with your users and analyze their reactions using your product. And you will then iterate based on their feedback, comments and ideas.

On mobile, your MVP must be super concise, clear and straight-to-the-point, because …

… you have 10 seconds

Here is a simple recommendation to help you selecting the “core” service of your app.

When your user opens your app for the first time, imagine you have 10 seconds of his attention to convince him. It’s what I call your app elevator pitch.

In 10 seconds, your user must understand how your App is going to solve a problem or what new service is proposed (the famous “painkiller or vitamin” metaphor for startups).

80% of mobile Apps are opened only once (source: App Annie 2015): only 20% of them managed to convey both the right message, and the right “first” experience in the App.

So, in real life, if you don’t manage to pitch your App in 10 seconds, and have a positive reaction from your audience, rework it to make it more obvious.

Optimize your 10 seconds

Something like 2 years ago, everyone started to create “onboarding” screens in their App. It was fancy to do that, probably because some famous Apps did that. It’s a “UIPageViewController” from a technical standpoint (a kind of deck going from the left to the right) with a marketing message on each “slide”.

Sometimes, it makes sense. Most of the time, it does not.

Let me explain: users don’t give a damn about marketing messages. So you’re going to waste 10 seconds of your users’ brain, before they actually use your App.

Our recommendation is to make it super short (e.g. “Get to all your files from anywhere, on any device, and share them with anyone.” — Dropbox), and have your user experiencing your App as quickly as possible (in these 10 seconds or so) so that they can feel it.

In other words, the best way to get users on board is to have them using your service. Easy to say, hard to execute: you need to spend a lot of time refining the “first time” in your App so that the user can understand both the service, the value and the coolness of your App.

Next

If you already have a Christmas Wishlist, simply trash 90% of its content, and keep the unique service/feature that everyone in your Ninja team want. This is the feature you need to perfect. Focus on that. Deliver it. And iterate.

___

If you liked this article, thanks for clicking the ❤️, and feel free to comment 💬

Lunabee Studio is a company creating premium mobile Apps in the Alps. We love mobile UX, iOS and Android. Follow us to keep up with our latest publications and news.

--

--