How we develop a mobile app

I'm often being asked: how do you work? What is your process? To answer this question in detail, I wrote this post on how we approach mobile app development. Below are some of the most common steps we take and milestones we reach in the process of developing a mobile app.

Research and planning

Concept development - taking the initial ideas and exploring how to turn them into an app. This phase involves a lot of exploration, looking at the "state of the art", investigating new technologies, and trying out services or SDKs. We make lots of whiteboard sessions, draft documents and concept designs which we validate technically and commercially.

Single vs. multi screen - one of the key things to determine quite early in the process is whether we are developing a standalone app or a multi-screen experience which spans over different devices and/or mediums. This decision dictates a lot of what comes up next.

Technical Feasibility - we look at the evolving concept and inspect the suggested user journeys to understand what potential technical difficulties may arise along the way. This step involves a deeper dive into implementation details. We may use playgrounds, build rapid prototypes and experiment with various SDKs to get a grasp of what's possible and what's not.

Effort/cost estimation - Following the technical study, and as soon as the concept stabilizes on a specific direction, we start planning out the project. This includes effort estimation of the entire project, broken down to phases and delivery milestones.

Marketing

Marketing before implementation? Yes.

Marketing is the story you tell your customers about your app or service. If you want to deliver on your promise, you'd better figure out what it is that you're promising first, and to whom. Only then you should start building the solution that fulfills that promise.

The main topics we cover in reviewing your marketing strategy are:

Target personas - who is going to use your app, and why? What are some of the specific feedbacks you received from those target personas? We use this feedback as input for product design and prioritization.

Unique selling proposition - what differentiates you from the competition. What does the app do exceptionally well that sets it apart?

Competition - who are some of the most successful competitors in your space and what do they offer that you may want to offer, too?

Channels - how are you going to reach your customers?

The reason we discuss your marketing at this stage is to align everyone's expectations, especially the dev team, on what this app is all about. The clearer the marketing messaging, the more effective the implementation.

Product Development

Storyboards, or wireframes, make the skeleton of the app and define the user journeys, interaction and flow. As such, the wireframes set the foundation for the detailed planning, backlog creation and the team setup.

Platform & Team - do we develop native, hybrid or web? Which platform should we focus on first? We list all dependencies, such as open-source projects, 3rd party services etc. and list the skills and competencies. We then organize the dev team for a kickoff meeting.

Product backlog - starting with high-level epics that are broken down into smaller tasks, the backlog is like a large ToDo list of the project. Creating this list depends on a solid product definition including the wireframes. The backlog requires constant maintenance (aka "grooming") to reflect changing priorities, new features, raised bugs and changed requirements.

Design - the project designer uses several input sources to develop the visual designs of the application screens, including layouts, colors, fonts, graphics, interactions, transitions etc.

Implementation

This is where development actually happens. We use SCRUM, an agile development methodology, using short (typically 2-week) sprints ending with deliverable feature, component, flow or set of bug fixes.

When planning a sprint, we pick a set of related tasks from the product backlog and assign them to the sprint. Developers then work on these tasks, test them and assign them to the product owner for validation.

Each day starts with a 10-15 minute stand-up, where each team members talks shortly about what he did yesterday, what he's going to do today, and whether he is facing any impediments, which must be resolved by the product owner.

At the end of each sprint the team runs a one-hour retrospective to review "what went well" and "what went wrong". This helps the team improve its velocity and performance in the next sprint.

Sales and support

A mobile app isn't the endgame. Once published, you'll have to constantly promote the app, collect feedback, improve usability, add features, fix bugs and publish updates in order to make your app more visible on the AppStore.

We do that with almost every app we develop, and it's perfectly natural. You can't really anticipate each and every outcome during development.

During the first year of life of the app, we collect logs, crash reports, user feedback and analytics data to identify the issues, errors and bottlenecks in the app. The acquisition funnel is not yet optimized and we therefore do not recommend launching large PPC campaigns at this stage. Instead, we use ad campaigns as experimentation tool. That is, limited budget campaigns that we use to learn about keyword optimization, conversion costs and CAC.