20 questions you need answered before you start that mobile app

20 Questions to ask before you build that
mobile app for your clients
Kumulos
Dec 2015

20 answers before you start that mobile app
So your business builds mobile apps for a range of business clients. That's a great place to be right now.
Lots of opportunities.
Lots of potential projects coming your way.
When we talk to busy mobile app development businesses they tell us one of their biggest challenges is getting
the mobile app build project properly scoped. Too many times projects become too organic with new
requirements emerging through the life of the project, sometimes too many ideas on what the app should do
and they find it difficult to really define what success looks like. What we've found is that if you can get good
insight into the project by getting answers to these 20 questions right at the start of the project, its more likely
to be a success, both for the client, and for the mobile app agency.
So it usually starts with your new client coming to you with a great idea for a mobile app that will help
revolutionize their business and reach out to existing customers and a whole new set of customers.
That’s Awesome! But how do you get into the head of your client and make sure you really really understand
what they need from you. Get this wrong at the start and the wheels pretty quickly come off the project.

Can you summarize the Mobile App to
me in just a few sentences?
This isn’t to catch the customer out, it’s to
really see how well they understand the
“essence” of the app. The better they
understand it, the more confident you can be
that they will be very exact and focused about
what the app needs to do, who its focused at,
how they will use it etc.
Who are the target users?
What problem is your app going to solve for
them? Why is a mobile app the best way to
solve this? Could a mobile responsive website
be just as good, or an even better way to solve
the problem? What devices or platforms are
they most likely to use, there are real
demographic differences between android
and iOS platforms that need to be thought
through.

What’s the real deadline?
Is it linked to any other activity (a big
product launch) or tied into a seasonal
campaign? So its usually the case that the
project should have started yesterday. But
at least you can work out what's possible
with the time you have. Work back through
AppStore submission, multi-platform
testing, development, and creative,
ideation to set the expectation early on
what’s practical and what’s not in the time
you’ve been given.
What risks are there with the mobile
app build?
What are the outside dependencies that
could affect the timescales? Addressing this
up front will save you a lot of problems
further down the track. Building a risk
register as part of the project kick-off and
being disciplined to keep this up to date is a
good idea, even for what seems to be a
simple app product. Make sure that for
each risk there are actions and owners
responsible for managing down the risk of
this affecting your successful app delivery.

What’s the budget?
So the game usually is, we don’t have a fixed idea of a budget, we want as much as we can get for
as little as we need to pay. Mobile projects are really difficult to budget estimate, but for you to
scope the project you need at least to work to a range. Defining the scope of work is also really
important. It not just about the physical build. Is there budget for researching the app,
competitors, key functions that users will highly value that will guide you on what the MVP
NEEDS to have for the app to be market ready. If it’s a new clients it could become a tricky game
of poker, neither side wanting to show their hand, but unless you get to a range pretty quickly
expectation management is going to be tricky. If the client can’t give you a range, that could be a
red flag, it may not be a serious project but just a vague idea they are trying to flesh out.
You should also agree what the ongoing budget is going to be once the app is live. There will
probably be hosting costs, ongoing optimization of the app on-boarding and in app use, discovery
optimization as well as managing scaling out back-end systems as app user grows. Knowing how
much ongoing work the app will require could also influence how much you charge in the initial
build phase. You could decide to scale back costs on the initial build and get the app to market
quicker, then work with the app owner to continually improve the app over time. They get an
awesome app that's just getting better and better. You build long term income streams for your
business and long term relationships with your clients.

Who are the key Stakeholders?
Is this who you are working with, or are their
others that you need to know about?
Who is the budget holder?
Who is the Project Owner? Your contact, or
someone else.
What are the decision making stages?
Who need to be consulted at what stage to
move from Ideation, to prototype, to build, to
test, to release?
Who are you going to work with post launch?
Is there a formal process here (you should
hope there is), or is this a more organic
process, and if so it’s point 1 on your Risk
Register, in big, bold, black ink capitals. You
have a risk register for this project.. Don’t
you?
What does success look like at each
stage of the process?
Building this into a number of smaller phases,
with approval “gates” you need to go through
may sound bureaucratic and feels like it could
show you down, but it will, without doubt,
save you time, money and a lot of anxiety
through the mobile app build.

What are the business objectives for the
mobile app?
Is the mobile app an internal app to increase
workforce efficiency? Is it there to open the
product or service up to a new profile of user?
Will it increase sales from existing customers?
All good, worthy reasons to build an app.
Answers to this question will have a huge
influence on how you build the app, what the
core features and functions of the app, what
platforms it needs to run on etc.
Who will the app compete with?
Has the client done a detailed evaluation of
competitors in the space that you can work
from? Don’t accept the response – “We don’t
have any competitors here, we are the first to
do this?” It’s a common response, but one
that’s usually not true. There may be no direct
competitors doing EXACTLY the same thing,
but that doesn’t mean that there aren’t other
ways that people are solving the problem that
they have. This shouldn’t be an App to App
comparison. So ask the question “how do the
future users of your app currently solve this
problem?” that way you’ll probably get a more
insightful answer.

What design considerations/ constraints
does the Mobile App have to work
within?
Are there corporate guidelines that the mobile
app layout and screen designs need to
conform to? Will this work on a mobile
format? Are there constraints on how it can
appear in the app store. Will this tell you how
the icons in the app store need to look? Will
this limit how the app will pop-out at
someone browsing the store? What scope is
there to push back at the branding police to
get some design latitude to let you do an
awesome job?
Is there scope to have multiple releases?
This is both in terms of what native platforms
you need to build on as well as functionality. Is
it possible to focus on a minimum viable
product (MVP) as version 1 release, with a
feature roadmap? Does it have to be big bang
with all features on all platforms day 1. This
may be desired, but is it REALLY a necessity.
Even if you need to go Big Bang, its still good
to work with the client to define and agree
what the minimum viable product (MVP)
NEEDS to be. That will help focus discussions
around the budget and timescales for launch.

What is the backlog of functions
for the app?
Even if you’re not using an agile software
development approach to building the app,
getting your clients to build a backlog of (non
MVP features) is a very powerful way to get
them to priorities between the essential
functions of the app and those that are non-
core for version 1 release. This has the other
benefit of helping you plan future releases for
the app, big for App Store discovery
optimization and managing your future
project work (and cash flow).
What are the underlying
assumptions?
Is it to work across tablets and mobiles?
Can this be one version that resizes or do
you need a build for both? How back
compatible does it have to be , iOS8 and
later, Android 5.0? Android 4.0?. Does the
app need to work offline? Will it have to
connect with wearables or Internet of
Things devices? What languages is the app
going to be built in? The answers you get to
"Who are the target use of the app?" will
obviously have an influence here.

How is it going to be hosted?
Is there an existing infrastructure it needs to
plug into? What are the security protocols?
Are there any upstream micro-services that
need (or would be good to) plug into the app?
Is there going to be a website (mobile
responsive of course) that will sit along-side
the app and have to share user profile
information etc.? Are there any other vendors
that the app needs to integrate with
(salesforce, SharePoint etc). How are you
going to manage user generated content
and what's the expected upload/download
shape of that content?
What is the monetization strategy for
the app?
If it’s a B2E app, solving internal problems for
a business to improve staff productivity, then
there is still a money angle and a Return on
Investment business case. If it’s designed to
increase revenue for the business, how is it
going to do that? in app purchases?,
subscription model?, will features be unlocked
with staged payment?, is a physical or virtual
product being delivered after payment (so do
you need logistic tracking)?, will there be in
app advertising to monetize traffic through
the app? Knowing this and building the app
around the business goal will keep the client
focused. Agreeing the MVP and building the
Backlog of features acid testing each feature
and function against the business goal will
mean you’re focused on doing the important
things in priority order.

What are the data points that your client will need to get from the app?
Baking the measures, metrics and benchmark objectives into the mobile app at the design stage will help make
sure that the mobile app build phase delivers against the key measures of success. If you don’t define the key
metrics, that underpin the tangible measures of success for the app at outset, how will you focus the decision
on MVP features? Also mapping out the analytics and metrics during the build will save the agony of trying to
retro-fit these late in the day, or worse be duped into judging the success of the app based on what’s easy to
measure, rather than what are actually the true measures of success. Core to this should be measures of
recency, frequency, duration & lifespan.
Clients want to know
 How many downloads?
 On what platforms?
 Ratio of push notifications activated?
 How many that download are actually fully installing?
 How many active users you have (is this growing)?
 What features are being used the most?
 Where are the dead areas of the app that need re-thought?
 How frequently is the app being used?
 For how long (use session length)?
 How many transactions (sales) have completed?
Mapping the actual against expected, looking at the variance them working a plan to close the gap between
actual and plan is what it’s all about. As long as these are defined up front of course. You’ve got a huge role to
play here, and a huge opportunity to generate on going monthly recurring revenue from the initial app project
to help the owner of the app optimize and improve the commercial performance of the app.

Are there other apps that the client likes
that can be used as inspiration for how
this new app should look?
This isn’t about copying or plagiarizing
someone else’s design, this is about using
completely unrelated apps to help get you into
the head of your client and understand how
they are thinking. It’s easier if your following
an already predefined UI/UX design and
corporate guidelines, but it’s still important to
do this, if only to help you decide how
essential it is to build a native app so it
accesses all the rich handset functionality.
How is the app going to be found when
it’s ready to go live?
If it’s a B2E app, this may not be that
important, but for B2B and B2C apps getting
found in GooglePlay and the AppStore is going
to be important to draw users to the app.
Don’t think this is an afterthought. Its not. You
have to think of this at the design and
development stage. Make sure it conforms to
design guidelines of each store it’s listing in, if
it doesn't follow the rules its going to be tricky
to get it listed. You also have to carefully
think about future releases, this has a huge
influence on discovery. An App that's
continually being developed will rank better in
the store. Also make the icon impactful so it
communicates the value and purpose of the
app is really important.

What about post launch? What’s the ongoing plan to learn & improve?
There needs to be one, right?
No matter how awesome you are as a mobile app development agency you’re just not going to
get everything right first time. You’re also probably not going to be able to deliver all the features
your client wants, within the budget they have to spend and the timescale you’re presented with.
The clients going to be very very focused on the first delivery point, getting the mobile app live.
That’s natural. But your job is to coach them to think longer term. Get them to think about the
MVP, get them to build the backlog gets them in the mind-set that this is an ongoing project. The
first phase is version 1 launch. This means you get them thinking early about the ongoing phases
of releases as well as the promotion of the app.
Making sure that there is good data coming from the app is also critical. Using data & analytics to
know how the app is performing and the recency, frequency, duration and lifespan is what your
client had expected will help your client prioritize the remedial work that will be needed to get
the app downloaded, used, and reused frequently.

Bonus Question - Question 21
So lastly, and consider this as a bonus
question, given we are through the 20
questions promised in the title.
What dependencies are there, that we
need to consider before we can get
started with your new app?
Its good if you can get the client to clearly tell
you what needs to happen before they sign
the work order and kick the project off. Do
you need to run an ideation workshop (to
make sure an app is actually what they need)?
Does a purchase order need to be signed off
by the budget-holder? Are you both covered
by a Confidentiality & Non-Disclosure
agreement? In short, what are the barriers to
starting this project in the next hour?

Of course, no set of questions will be the same for every project and every client and every
mobile app use case. Hopefully this gives you good coverage of the main points. Asking the
questions, documenting the answers and playing these back to the client in the format of "You
Told Us This... so we will therefore do that" will make sure you are both on the same page. Better
this than stumbling in to bear-pits through the project.
There’s also another free, confidential mobile app project scoping tool that you could benchmark
your customer app project against.

20 questions you need answered before you start that mobile app

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (6)

Recently uploaded

Recently uploaded (6)

20 questions you need answered before you start that mobile app