A solution to lack of traction
Oct 31, 2012
Table of contents:
- The Problem
- Why an API?
- An example
- Disposable front ends
- Allow your api to be consumed by others
- Create many opportunities
There is an epidemic of too much noise in the world of Mobile and Web Applications. Every single day, more and more applications are being released, all over the world. Most people will only ever regularly consume a handful of apps, and so, thousands of applications are struggling to get any type of recognition, traction or growth.
The problem is compounding on itself every day that more new applications are released.
Developing an app consumes hours of hard work by designers and developers, requires creating and supporting infrastructure and trying to grow a user base. If the majority of all apps never get traction, this invested effort will go to waste when the app fails to get traction.
How can you protect your investment, invest your resources wisely and create a product that has a better chance of success?
By creating a faceless API.
The Problem
The problem with app development is, more often than not you will only have one shot with a user. If a user lands on your website, or downloads your app, and doesn’t immediately get what you are doing, you have lost your chance. If the user downloads your app, uses it once, and then uninstalls it, you could of lost that user forever.
First impressions count for a great deal. The problem with first impressions is, you only get one shot at it.
The months of hard work designing and developing your application and all of the resources you have invested into it could all be wasted because your choice of wording, design, or your on-boarding process was confusing or did not resonate straight away.
It’s almost guaranteed that your initial vision will change considerably over time. People worry about putting a half baked application live, and instead spend far too long in development. However, this is the wrong strategy to take because you won’t learn the harsh truth until you get your product live. Trying to perfect something in the dark won’t solve the problem of users not understanding your product, it will just make the problem worse when you finally reach that stage.
The real solution is to position yourself so that you have multiple opportunities to make the first impression. You shouldn’t develop a Mobile or Web App, you should develop an API.
Why an API?
When you start the development of an application, you have a problem that you are trying to solve. You probably have an initial vision of how you will solve the problem, what the User Interface will look like, and how the user will interact with it.
The majority of all of this vision is based upon assumption. When you finally launch your product, you might find that your assumptions were actually wrong.
Create an API not a product
An API is essentially an abstraction of your solution. By creating an API first, and a product second, you have abstracted the solution away from the product. This abstraction allows you to create multiple front faces of your API or use the power of your “solution” to find something that really resonates.
An example
Say for example, you wanted to launch a new iPhone application that tracks a user’s fitness and workouts. The problem you are trying to solve is the lack of exercise that most people do on a daily basis. You want to encourage people to exercise by offering them analytics of their activities to show exactly how the food their consume and the exercise they take effects their lives.
You probably already have a strong opinion on what the app should look like, how the user should interact with it, and how they would use it on a daily basis. You might already have an idea for a business model in order to hit revenue. But these are all assumptions you are making of the unknown future.
The abstraction of this idea is the user’s ability to:
- Create new data entries
- Read the history of previous entries
- Update existing entries
- Delete previous entries
None of this abstraction concerns itself with design or development, what the User Interface looks like, or how the user will share with Facebook. At this level of abstraction, all that matters is how the basic API will work.
Disposable front ends
The initial vision for the application might be of a completely social experience that combines a timeline of actives with social interaction.
However, the actual iteration of the idea that takes off might be a completely solo, deep science application that looks into the large data set that you acquire over time.
Each of these two ideas are two completely different products. Each of them would require two very different front ends, but the real root of the application could be powered by the same API.
If you launch the first application into the App Store and it gets no traction, it is going to be hard to pivot into the second iteration because you have already blew your opportunity.
On the other hand, if you just scrap your initial vision, and build the second idea from the same API, you can launch a brand new application that is not tarnished from the first failed launch.
The idea here is to pivot the idea, not the API. In this way, you can have multiple different experiences and ideas to solve the ultimate greater problem, and you don’t tie yourself to a one shot opportunity of success.
Allow your api to be consumed by others
Focusing on an API, rather than a product also has a number of other advantages. One such advantage is the opportunity for growth when having an open API.
When you have an idea for an Application, you have a problem you want to solve. In the previous example, the problem was, “Encourage people to do more daily exercise”.
You create an API that allows users to track and analyse their exercise habits on a daily basis. Next, you find a use case that resonates with your audience and build out an application that allows your users to get value from your API and from your application by solving their lack of enthusiasm for exercise. Hopefully, in the process of finding this traction, you build a valuable business that is able to capture the value of this audience and their data.
When you create a closed application, you limit the possibility of someone else building upon your platform to solve some other adjacent problem. By allowing other people to build off your API, you are enabling them to grow your audience and add value to your business. Yes, you are losing some value from the hard work you put in, but in reality you can’t solve every problem that relates to your area.
By focusing on building a solid API first, you open up the opportunity to work with others and to create a platform where developers or other companies can hook on to the value you have created in order to build a related solution and help fuel your growth. You have already done the work to abstract the solution from your product, you can now look to fuel your growth by being open and allow others to build upon your platform.
Create many opportunities
The real value behind creating an API rather than a product is that you open yourself up to new opportunities in the future. You can’t predict what is going to happen tomorrow, so by giving yourself as many opportunities as possible, you can protect yourself from unforeseen circumstances somewhere down the road.
Your initial vision might be to target consumers, to be social and to partner with established local businesses. But in reality, the successful version of your solution to the problem might be in complete contrast to this initial vision.
By abstracting your solution from your product, you give yourself the opportunity to try many different approaches. Failure becomes a learning opportunity and you can quickly and easily pivot the value of your vision into an adjacent area.
Design and branding is hard to get right. You want to be unique but you also need to resonate with your audience. If your audience does not get your solution to the problem, but you learn something valuable a long the way, you can integrate that new information into the next version of your product that you can quickly build from your API.
On the path to success, you will find many failures a long the way. By building flexibility into your product from the very start, you can mitigate the risk of complete failure, and open up opportunities to discover the idea that really works.
