Five Mistakes Clients Make with an Agency
when Building Mobile Applications
There are numerous articles about mistakes agencies make when working
with clients, but those lists tend to be quite big, addressing everything, from
communication style and understanding the business, to skipping steps in the
design and delivering untested builds. At Five, we’ve been continuously learning and
enhancing the way our agency works over the last eight years, and
there are still things we could and should improve.
The client *was* always right.
I won’t go into differences between “good” and “bad” clients or try to
educate you on how to be a good one. I also won’t repeat the basics, such
as “be careful with the change requests during the project” or “trust
and listen to your agency.”All agencies are aware that “the
client is always right”, but the agency has been hired due to its
specific expertise and knows the ins and outs of the business. And I actually
genuinely think it’s the agency’s job to get the client to listen,
whether through the right arguments (such as user-testing data), strong
presentations based on previous industry experience, or simply high hourly rates
(according to the old secret of consulting “make them pay you a lot, so
they have to listen to you”).
Over the years, I’ve seen mistakes that our clients repeat over and over
again. Some have been quite frustrating, and some luckily do not have repercussions
(if we don’t count the “I told you so” moments). Here
are five mistakes that can have the greatest impact on a
project and yet can be easily avoided.
1. Asking the wrong questions during the RFP process.
The first thing that could go wrong is, obviously, choosing the wrong
agency. We’ve had clients turn us down during the request for proposal process
just to return a couple of months later unhappy with the agency they
chose. Why?Because they asked the wrong questions during their
early vetting process and put too much emphasis on completely irrelevant
matters.
The goal of the RFP process is to meet the agency, see how they work and
what makes them special. It’s a two-sided process: not only do you (as a
client) pick the agency, but the agency picks you as well. For
example, don’t make them compete on price early on because most of
these estimations are a shot in the dark, and pay attention to the
questions they are asking. Don’t be blinded with the brands they’ve worked with
and case studies they’ve published — maybe it was their A team, and you’ll get
to work with a C team.
„The goal of the RFP process
is to meet the agency — see how they work and what makes them special.“
Also, be realistic with the proposal deadlines if you
want them to do their homework, research your business, and come up with a
detailed proposal. Don’t ask for it by tomorrow EOD just because you have other
agencies in the pipeline.
The pressure is on you.
There are a few types of questions we are always asked, and it’s not
something that will make or break the project. For example, asking the
question “What is your hourly rate?” first is pointless
because that question is totally irrelevant. Maybe our rate is $50 but
we’re extremely slow and inefficient, and maybe our rate is $500 but
we deliver bug-free, easily maintainable code weeks ahead of schedule within a
fixed budget and with lifetime support. What you should really be asking are
questions like “What could you do with a $150,000 budget?” or “What
is your typical project budget?”, if you want to keep your
cards hidden.
Five questions you should ask (in a subtle manner):
·
Where do you see pitfalls and problems?
·
Do you see this project as an important reference for your agency?
·
What is your typical project timeline?
·
How do you manage projects, and how can we sync our two orgs?
·
How do you handle change requests?
2. Making the wrong budget allocation.
Most clients expect a fixed budget at the beginning of the project. And
that’s fine — it makes perfect sense from the client’s perspective.
However, it’s unrealistic. The typical input for the budgeting
process is a written specification for the project. But a two-page Word
document with a bunch of bullets can’t possibly be enough to scope out the next
four to six months of work, right?
Even if the agency is willing to commit to a certain fixed budget, it’s
not necessarily a good thing. As the project moves forward, you will begin to
clarify your expectations on certain features, and if that falls outside the
scope the agency planned for, they will push back. It’s simple math and it will
work against you. You want the agency to do the best for you and your project,
and push to maximize quality rather than to minimize the extra work. So
how do you reconcile these two interests?
Ask for a budgetary estimate at the beginning.
The agency is expected to have experience and be able to say whether the
project will be somewhere between $50,000 and $70,000,
or $100,000 and$120,000. But lately we’ve started to
budget projects in three phases:workshop as the first one, design phase as
the second one, and development as the third one. And you can do
a 100% accurate fixed-price estimate only after you’ve
successfully completed the prior phase. So we deliver the fixed-price estimate
for the workshop (more about that in #3) and do a budgetary estimate for the
next two phases. And it works.
Crunching the wrong numbers.
Another problem is incorrectly allocating the budget for the
project. We’ve seen clients spend all of their budgets on the first version
of the app and completely forget about the version 2, changes and updates, or
marketing. If you’ve just raised the funding for your project and let’s say you
have it fully allocated for the app development, plan to spend a maximum
of 60% on v1 of the app.
If you’re in the planning process and you’re allocating the corporate
budget for the app, plan to allocate 100% more for marketing,
and version 2 + changes to be applied after you’ve learned from the v1 results.
3. Not communicating business goals (or even worse, not
having them).
It sounds so obvious, but the majority of our clients actually
don’t know their business goals before the project starts. And those goals
should shape the whole project and affect where we focus most. We simply need
to understand your business goals and what drives you forward.
“It sounds so obvious, but
the majority of our clients actually don’t know their business goals before the
project starts.”
First, ask yourself the following, and then communicate it to the
agency:
1. Why are you
doing the project? What’s the motivation behind it? What drives it?
2. What are
the key metrics you will measure? Is it revenue, user base, time spent in the
app, monetization, brand awareness, or something else?
3.
What is the criteria for success? A year from now, how will you measure
the success of the project?
Be the hero.
You have to understand one of the concerns each agency has: it’s that
you’ll cut the project at some point if it doesn’t bring the expected results.
Maybe it will be your CFO who will simply look at the numbers and decide to cut
the funding. Maybe it will be your CEO who will not have you spend any more
time on this as it’s not bringing value. Our goal as the agency is to make you,
the project owner, a hero within your organization and to help you move up the
ranks with the success our joint project will bring.
Design Sprint
“Our goal as the agency is to
make you, the project owner, a hero within your organization and to help you
move up the ranks with the success our joint project will bring.”
And that’s why we push for workshops at the beginning of the
project. We do Design Sprints, a five-day onsite workshop during
which we talk about your business goals and see how they evolve into specific
app features. That’s when most of the learning happens and,
interestingly enough, when clients learn about themselves as well,
each stakeholder’s motivation and expectations, and that sets the tone for the
project. After the workshop, we’re confident we can estimate the design phase,
as only then are we all on the same page about what we’re actually building.
4. Not allowing enough time for the creative process.
Clients tend to push for first app builds, as they
want to see progress and show it within their company. But the reality is that
the first production-ready lines of code won’t be written two months into the
project (we might do a coded prototype or two of some advanced features). And
there is a simple logic behind this: agencies tend to spend a significant
amount of time during the design phase fleshing out all the product details and
making sure everyone is on the same page.
In the design phase, changes are more than welcome, and there is a
steady review process where everyone is asked for feedback and that feedback is
incorporated into the final designs. Changes in the development are
expensive, and in the UX phase they don’t cost more than a few clicks.
“The reality is that the
first lines of code won’t be written two months into the project.”
There are several steps that need to be completed before moving into the
development phase, and it requires time and commitment from the client as well
to provide input, clarifications, guidelines, and feedback. Make sure
you’ve completed all of these steps:
1. Complete
wireframes (UX) with all the flows. Cover all the states (errors, empty states,
messages, micro copy, etc.).
2. Wireframe
prototypes (e.g. Invision).
3. User
testing of the key UX flows.
4. Designed
screens with style specs.
5. Designed
prototypes.
6. Animations.
7.
User testing of the final designs.
Take user testing seriously.
It can be done within your company or it can be done within the agency,
but for real results, spend a day at a user-testing facility. After
completing the UX phase and after completing the UI phase, we bring in a
minimum of six external users to the facility and validate all the
assumptions. In between we do simpler and faster internal user testing, and
sometimes we do a week of user testing with 30 users (six per day is our
optimal plan).
If you do the design phase correctly and without skipping steps, the
development phase will be a walk in the park — no surprises and punctual to
a day.
5. Underestimating the backend work and API.
“We have an internal team.
We’ll take care of it.”
We’ve heard it before and know it’s a red flag. On the
other hand, the truth is that there is no one better than the internal team to
take care of the backend. It ties into the business logic, databases, servers,
and opening it up for an agency would require too much work. And the agencies
aren’t too keen on it. We don’t want to spend months learning the intricacies
of the client’s internal systems.
But the reality is that those clients’ internal teams are burdened with
work and have too much on their plate. In the past three years, all the delays
we’ve had in delivering our projects were directly related to delays by the
clients’ internal teams in charge of the backend and the API.
API first.
In a perfect world, no front-end work (mobile apps or even
web apps)should ever start before the API has been delivered and tested.
We’ve yet to see that happen, as it typically all starts in parallel. Clients
and agencies agree on a rough spec, and, more often than not, the agencies
build their mockup API to be used during development. And the premise is
straightforward: once the real API is done, we’ll just switch. And it
never happens painlessly.
Building efficient APIs requires committing significant time and
resources. It requires planning from joint client-agency teams, and it, plain
and simple, requires staff hours. It’s easy to underestimate that work. We’ve
seen it a bunch of times. And now it’s the single most important thing of which
we warn all of our clients. Start early, communicate often, and have
the agency test it out as soon as possible. Treat it on the same level
as you would any other project. It’s not an add-on to an external project. It’s
not you just providing support. It’s a full-fledged project requiring a
technical lead and at least couple of weeks. So plan for it.
“Start early, communicate
often, and have the agency test it out as soon as possible.”
Help us build great apps!
Or should I say, help us help you. Ask the right questions, allocate
your budget correctly, communicate your business goals, allow the creative
process to flow, and never underestimate the backend work and API. Having the
right agency and keeping these five things in mind, you might just get out of
the limbo of constant frustration and witness the process of building
some great digital products.
Let me know if these pieces of advice worked for you, and share your
own!
