Also available to buy in a beautiful limited edition paperback and eBook.This work is licensed under a Creative Commons Attribution 4.0 International License.
In the previous two chapters we confirmed that a market exists for our app and built up a picture of customers in the market: their behaviours, needs and motivations.
Now we need to know how to make an app that satisfies these people. Marc Andreessen, the creator of Mosaic and founder of Netscape, puts it like this:
“The only thing that matters is getting to product/market fit. Product/market fit means being in a good market with a product that can satisfy that market.”1
You can get some things wrong in the development of your app and still be successful. The one thing you absolutely want to get right, as quickly as possible, is the basic set of appropriate features: those that the market wants.
The persona creation process is worthwhile in itself, but the real value comes from the placement of personas into scenarios: situations or stories where desirable or ineffective app features become evident.
Some scenarios are more detailed than others. Task-based scenarios, which place personas into specific goal-driven settings (“Stephen doesn’t have any chilli peppers and needs to acquire some quickly”), are of more use later in the development process when you are testing the design of individual features.
For now, let’s use looser scenarios to get a feel for the kind of features we should consider. For the sake of brevity, I include a sample response for the first scenario only, using the Stephen persona from the previous chapter. This will demonstrate how desirable features are drawn out of scenarios.
You should use multiple scenarios to create a single, normalised master list of potential features.
Consider a day in the life of your persona – waking up, commuting, working, taking lunch, evening routine – and how your app interacts with them.
This is a more focused equivalent of the previous scenario: what is the persona doing immediately before, during and after using the app? The answers will help us align features to the user’s natural workflow.
How does the persona use the app for the first time, the second time and on subsequent uses? Does it gather information and personalise the interface? Does it learn and adapt? Does it behave differently because other users can influence the content and features? Are advanced features phased in?
If the app was human or if it had magical abilities what would the persona expect of the app? What’s the closest we can get to these expectations considering current technologies and the persona’s abilities?
Map out the six phases of how the persona engages with the app:
It’s tempting to make a list of all the features that your users could possibly want, and not release the app until it supports every one. This would appear to maximise the app/market fit and, hence, the chance of success. But there are three major problems with this approach.
First, it’s possible to include too many features. As the number of features increases it becomes more difficult to build a usable product, and the result is often a confusing interface through which the user cannot achieve even simple tasks.
Second, our current feature list is really just a best guess. We’ve yet to test these hypotheses with real users so we may waste time developing dozens of unwanted features. And third, it’s not practical and doesn’t make good business sense. Even if you can afford to do so, there’s no point delaying the launch of your app by months and investing thousands more dollars if you can launch earlier and still achieve success.
The challenge is to determine which features are required for launch and which can wait for a later iteration. You need to build the minimum viable product (MVP):
“…the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.”
To reiterate: building an MVP is not about creating an app that gets the most ‘bang for buck’; it’s not about developing the minimum number of features to satisfy the maximum number of users (the ‘sweet spot’ in the diagram below).
The minimum viable product has fewer features than an app at the sweet spot
The MVP is a much earlier iteration than this. It’s the minimum product that can be presented to the market in order to attract some paying customers and to validate and evolve the research about what they want. Personas and scenarios give us a good idea of how to achieve the MVP; the MVP in turn enhances our findings and takes us to the next stage.
How do you decide which features to build into the MVP?
The interviews and surveys you conducted for persona development make the best foundation for feature prioritisation. You should have a good understanding of what really matters to your users: their principal needs and motivations, and their relative importance. If you developed multiple personas and scenarios, the features that appear most frequently should come higher on the list.
Analysing the common feature set that exists across your competitors is important even if you plan to differentiate on an attribute other than features, such as usability or business model. Determining the base feature set is as simple as creating a spreadsheet of features from each competitor website to establish commonality.
It’s important not to think of this checklist as a set of minimum requirements. As evident from many successful Apple and Google products, the way that it has always been is not necessarily the way that customers want it to be – even if they don’t know it yet. Try combining this core information with customer complaints and suggestions (often publically accessible on websites like Get Satisfaction2) to build an MVP that defines new market space3. If there are common sources of dissatisfaction across all of your competitors, you may be able to use these missing features as your MVP – you only need one.
Google AdWords4 are a great way to quantify market interest for features, although this method does require some spending.
You’ll need to create a teaser page for your app if you don’t already have one. Then, create AdWord adverts for your app teaser page. Each advert should highlight a specific feature. It’s important to limit the focus of each advert to a single feature only: this is a test of the reaction to features, not the app. You can use similar adverts later in the development process to determine the price levels that are acceptable to the market but, for now, the adverts shouldn’t confuse feature testing with price testing. Don’t include prices in the adverts.
Choose appropriate AdWord keywords so that you get the highest volume of relevant traffic for the lowest cost (see chapter 24 for more about AdWords keyword selection).
An example of a Google AdWords advert
Create all adverts under the same Adword Group and configure the group so that the Ad rotation option is set to Rotate rather than Optimise: you want your individual adverts to be publicised evenly so that relative interest can be gauged and used to prioritise feature development.
Configuring Google AdWords options
You don’t need to collect a vast amount of data to extrapolate the findings. Set a low daily budget for your AdWord campaign and limit the duration to one week. If you’ve been able to target cheap keywords (around $0.10–$0.20) and are testing less than ten features, your daily budget needn’t be more than $10. By the end of the week you should hopefully have a few hundred clicks distributed across your feature-specific adverts, which is enough to identify those that appeal most and least to the market.
The landing page won’t fulfil the users’ expectations – after all, the app isn’t built yet. If you’re particularly nervous about damaging your reputation before you’ve even launched, use an alternative domain and app name for this test.
It’s almost certainly better to be honest on the landing page and give the user the opportunity to sign up to be notified of launch, perhaps with the sweetener of an early bird discount. An email sign-up is more valuable than asking them to follow you on Twitter, Facebook or RSS, especially if you build in the capability to capture the referring AdWord/feature for those that sign-up.
There’s an oft-repeated quote attributed to Henry Ford: “If I’d asked my customers what they wanted, they’d have said a faster horse.”
You don’t need to ask your customers what they want; the persona and scenario research has already provided a list. Instead, ask relevant people to vote for and prioritise the features that are the most important to them. You can use the same survey tools and customer identification techniques discussed earlier for persona research, or a web app like User Voice5.
Prototyping is discussed in more detail in chapter 15 but it’s worth mentioning here as a useful process for prioritising features. At this early stage of the project, you may want to use nothing more than paper prototypes: rough sketches of the interface on paper.
Create variations of the basic app interface – it might only be a row of buttons – where each variation has different features in different parts of the interface. Put the sketches in front of your users and ask them to tell you what they’d do, which buttons they’d click, if any. If you’ve mocked up the interface digitally, use an analytics package or video recording device to track the features that they find interesting on each variation. In statistical terms, this technique is called multivariate testing and the results should highlight the features that attract the most interest.
If your web app is targeted at the enterprise market (lower volume, higher price, closer relationship with the customer) then a prototype can even be a PowerPoint or Keynote presentation describing what you intend to build and some interface mock-ups. Get this in front of one or two potential customers and you’ll get essential feedback on what excites them and what doesn’t.
Features are the backbone of your app, and should be determined by user need analysis.
This work is licensed under a Creative Commons Attribution 4.0 International License.