Our Development Process
You want to end up with a tasty dish but you start with a bunch of (mostly) unrelated ingredients. Going by the recipe makes the process easier for the untrained cook. Following the release of a version to the app store was pretty much the same for us.
There are many posts out there about proper processes, waterfall (Blurgh!), Agile and scrum and many more. But new teams want a simple step by step procedure to just get the app out there. So we worked and eventually the process came to be. Here is a short breakdown of how we release a new feature to our iPhone app and get a well tested version submitted to the app store
The development process
What happens when we want to add a new feature to the app?
First, it worth discussing what triggers adding a feature.
- The product road map, which is updated every now and then.
- The market needs, when a mobile OS get’s a new and appealing API you want to add to your app, new government regulations in your app target market
- User requests — maintaining a direct connection with your users is great. You can learn a lot from it, and especially from supporting your users. Realizing what are the problems your users are facing, what are they asking of you to add to the app can sometime define a feature you didn’t know you wanted
- Data triggered — my personal favorite. Every app needs great analytics to cover funnels, retention, engagement etc. Analyzing the data and asking questions about it should be done on a regular basis. Sometimes the results might show a path in the app the users are taking which you just didn’t think about, and that is a great trigger for a new feature
Now that you have feature you thought about, the next thing is the hand off. A hand off meeting is a short meeting in which you pass the feature to the dev team. It should have some if not all of the following steps:
- Describing the feature
- Describing its purpose (retaining the users, making them more engaged with the app, triggering an in-app purchase etc.)
- Going through the use cases (what to expect the users will do), some features need complicated logic behind them, make sure the dev team understands what is expected in each use case
- Going through the design mocks and making sure all resources for the design exist (Images, cuts, texts, translations)
There are three prerequisites left before you can bash some keyboards and add that awesome feature to your app
- Analytics design — Launching a feature to the wild should be backed with the necessary tools to measure how well it performed. Making sure we understand what we want that feature to accomplish and we know how to measure it. Moreover, features that target improvement on certain KPIs should be launched with an A/B test to understand its true impact on the user behavior.
- Time estimation — You MUST have a time estimation for a feature. Getting feedback from the dev team on how long it would take could drastically influence on the go/no go of the feature or maybe cut down some of its requirements. Time estimation is a trial and error skill which over time reduces the error margin but never eliminates it, so be patient!
- Technical design — This one is located on the border of prerequisite and actual task as part of the feature. We expect our developers to have the task thoroughly thought about so in every step of the way we can get a short report on where we stand and what is left for us to do. In a nutshell, go through the feature specifications, break it down to smaller tasks, give those tasks priority, ask for a design review from your colleague.
Now for the dev loop, we were a small team. No QA testers in existence, so we used the team (product, marketing, sales, CEO) to test our features before the release.
While !(mostly perfect)
What about scaling up?
We are still perfecting our process, but this is what it mostly consist of. Once the dev team will grow a little and official QA will get into gear, the next phase for the dev team is to have continuous integration and regular testing. After that? Most likely we’ll get into the more strict Agile world.