Having a strategy for your app is critical. You have a great idea, and even bigger aspirations for your goal. A strategy will focus on how to make the biggest impact as quickly as possible while saving as much money as possible.
There are thousands of factors that need to be considered when trying to implement your idea. The first is timeline. Is it critical that your app is on the market as soon as possible? In most cases your answer will be yes. Does the app need to have every single feature perfectly polished? Surprisingly most people answer yes to this question when the real answer is no.
Having a polished app costs a lot of money. In the end it may not be what your customers or clients want.
How do you know what your customers wants? The answer is know your customers and use them to gather information that will benefit you.
In order to create a strategy we will ask you a few questions about your customers that you may already know. As well as a few questions about your app. To give an example we will let you know a few little fun facts.
*When selling an app to make money, users who own an iPhone are more willing to purchase an app than a user with an Android phone. [statics from Time Magazine]
*For every one iPhone on the market there are 4 Android phones. [statics from Time Magazine]
If your app is going to be a paid app, then you should start off with an iOS (Apple) app. If your app will be free, it will be better to start off with an Android app. This is again a small fraction of your mobile strategy.
In order for us to help you the best, we use an agile development methodology. Agile has been around a very long time. What agile does is break the development cycle into a complete cycle the constantly rotates. Instead of doing all aspects of the development in one go, we break down the development into segments called sprints. Each sprint is 3 to 4 weeks and even after the first sprint you have a fully functional app. So why so many cycles you ask?
The first step in the agile development cycle is to gather the requirements. For the first sprint this is the foundation of the app which covers what is the minimal requirements to get the app off the ground. For the second sprint the requirements come from step 6. Keep reading to find out more.
The second step to the cycle is the planning stage. This is typically done in house with no customer interaction needed. During the planning stage we plan the first sprint to make sure that we can meet the requirements in the time line given. If the planning sees that the time is not enough we will increase the duration of the sprint. At this point we allocate our resources and get ready to work.
Step 3 is the design phase. For the initial sprint we will standardize all of the process flows and come up with the optimal way of building the app and its surrounding processes. Later on during the next cycles we will pull the design elements from the requirements that have been gathered as a result of step 6.
The 4th step and the longest out of all other steps is the development phase. This is where we go into action and put all that planning and designing into action. Our development phase goes hand in hand with testing as we do automated testing on all of our projects as well as use our in house QA (quality assurance) personnel.
For the 5th Step we will release the cycle. Remember at this point all features planned for this release are completed and ready to go. Now your customers are in control and they will be able to use your app.
The final step and the most import is the Track and Monitor. Now that the app is in your customers hands we are able to track their usage with our built in analytics. At the same time you can gather feedback directly from your customers on the app. Based on all of these results we can build a list of requirements for step 1. During step 6 we will know what works and what does not. This way we can fix what does not work and add what your customers feel is missing.
Now that the cycle is complete we can start all over again. Due to the fact that each cycle is the minimum that needs to get done based on the requirements, you will save money by not developing what is not needed in the first place.
The strategy of letting your customers dictate the path of least resistance in the long term will save you both time and money.