This is the fourth part of our series about the five elements of software engineering for mobile. Part one was about the main differences and challenges of software engineering for mobile vs “conventional” software engineering, part two was about making the right technical platform choices and part three was about getting the UX right.
This blog post series is based on a keynote talk to computing students at the Imperial College during the kick-off event for their summer group projects, aimed at the development of an innovative web or mobile-based app. The talk should help the students getting a more holistic view about software engineering for mobile and highlight the following five key elements:
- Make the right technical platform choice for your context (Part 2)
- Get the UX right (Part 3)
- Choose the right methodologies in the areas of building a business, customer development and product development (this part)
- Enrich the functionality of your app by integrating Internet-based APIs (Part 5)
- Leverage the power of tools (rather than reinventing the wheel) (Part 6)
In this fourth part I cover the third element “Choose the right methodologies” in more detail. We will publish another part every week, so make sure to check back soon.
Key element 3:
Choose the right methodologies –
In the areas of building a business, customer development and product development
Methodologies can be very helpful. Yet, there is always the risk of over-complication and potentially wasting a lot of efforts by choosing inadequate or heavyweight methodologies. I recommend lean methodologies in three areas:
- Building a business
- Customer development
- Product development
Building a Business
Building a business is the overarching methodology with the objective of being successfully and sustainably present on the market. In this context I like the works of Eric Ries who brought together several concepts from various disciplines and subsumed them under the term of the Lean Startup.
The core idea is to establish a hypothesis, implement a minimum viable product (MVP), test the hypothesis, collect and measure the feedback for the MVP, learn from that, and implement the learnings in the next version of the product. This is an iterative process, where at the end of each iteration a pivot of the original product idea can be executed if the learnings suggest doing so.
You can read up more on another blog post I wrote on “Lean Startup principles and mobile app development”.
The second area is about customer development. Peter Drucker argued that the real purpose of a business is to create a customer. That’s quite simple and plausible as at the end of the day it is the customer who is the source of revenue and pays the bills. So customers need to be developed explicitly. Berkeley professor Steve Blank coined a corresponding methodology with four stages:
- Customer discovery
- Customer validation
- Customer creation
- Company building
These four stages are also executed iteratively and may involve several pivots. Steve Blank’s methodology has some similarities with Eric Ries’s Lean Startup, which naturally lets them combine quite easily. In fact, both worked together in creating their methodologies. Udacity provides a free online lecture by Steve Blank that goes into a lot more detail on “How to build a startup” which covers customer development as well as parts of the Lean Startup.
A further tool which I found very useful is the Business Model Canvas coordinated by Alex Osterwalder. It visually covers nine important aspects about building a business or crafting a business model in general. You don’t have to religiously stick to the nine aspects but it does help to view a business model from various different angles and helps to not forget important things to consider. When going through various iterations – either in the Lead Startup or the customer development methodology, or both – the business model canvas can be deployed to craft various versions.
One of these aspects (and inherently part of a business model) are “revenue streams.” Related to mobile apps, generally five revenue models are established:
- Direct app sales
- In-app purchase (currently on average the most effective revenue model)
- Indirect revenues (Angry Bird’s Rovio generated 45% of its €152.2 million revenue in 2012 based on selling merchandising articles, see theguardian.com)
Based on the business objectives, a decision needs to be made how to generate revenue, based on a selected model. Different mobile app ecosystems have different market characteristics and dynamics. Vision Mobile did a very useful study on “Which apps make more money?” and give practical advice about the various revenue models.
The third area is product development itself. A lot has been written and discussed about product development and software development methodologies in particular. Basically there is a wide range on a scale from cowboy coding — which is basically sitting down and just hacking code without any prior thinking about requirements or how the code could be structured and how the architecture could be designed — to the Waterfall model at the other end of the spectrum. The Waterfall is a highly structured and static process advancing from one closed stage to the next. History and research have proved that neither model works. The truth lies somewhere between these two extremes and there is no absolute correct way to do it. The right product development method depends on the product and business environment. Although “agile” is trendy, a relaxed Waterfall model with feedback cycles and iterations does work when the problem and the solution are known (see Sturdy Development). The more uncertainties involved, however, the more an agile model – like Scrum – is suitable. Here is a practical Introduction to Scrum.
In this part, I discussed the importance of choosing the methodologies. In the next part of our series The Five Elements Of Software Engineering For Mobile (Part 5) I will cover how Internet-based APIs can enrich the functionality of an app.