Often, agencies will signal — without even knowing it — that their clients’ money is more important to them than their clients’ success.
How?
Fixed scope projects.
Many app development projects start out with the developer or agency creating a scope document.
This document outlines the timeline, the deliverables and the budget for the entire project from start to finish.
It makes things simple.
The problem is that, for projects lasting longer than a couple of weeks, the scope document almost always ends up being wrong.
And beyond that, it ends up being worthless documentation that hurts both the agency and the client.
Here’s why:
Fixed project scopes are built on (often wrong) assumptions, they discourage continuous improvement, and they hurt your ability to react and respond to lessons you learn along the way.
Simply put, they set you up to fail. The project becomes about the transaction of product for money, instead of outcome for money.
An app development project can be planned based on what we (both the agency and the client) think will be valuable and engaging for users.
A lot of prior experience and expertise go into those assumptions.
And still, no matter how good you are, when you get your beta product out into the field, you learn things about your product and your users that cause you to make changes and shift direction.
That’s continuous improvement, and that’s a very good thing.
If you’re working against a project scope, you’ll be disinclined to deviate from your scope assumptions.
When you change course, you’re no longer within your original scope. At this point, one of two things can happen:
- You stick to the plan and continue building based on flawed assumptions.
People do this because in their minds, they’re set on building what was discussed at the onset of the project, even if it comes at the cost of making changes based on feedback and data.
Developers and agencies who take this approach don’t care about the success of your project nearly as much as they care about building exactly what you agreed on (even if they now know it won’t work). They cover their ass and give themselves an easy answer when you ask them why your app isn’t taking off: “we built what we agreed on.”
That’s fine if you have a project where all you need is something basically functional, but it’s deadly if your goal is to build a successful app.
This is the worst possible outcome, and I’ve seen it happen far too many times.
- You change course. You request a change in scope, timeline, budget or deliverables.
Changing scope is not necessarily a bad thing. Flexibility in the face of new insights and feedback is what turns a seedling app into a product that users love.
But the process of changing scope is toxic and damages the agency’s relationship with the client, whether it’s obvious or not.
The agency will say: “These changes will take time. We can either increase the budget by X or decrease the original product roadmap by Y.”
And the client, if the relationship began with a fixed scope proposal, will feel misled and disappointed.
You’re both right, and yet neither of you win.
Fixed Scope Is Not The Same As Fixed Budget
Many clients are on an inflexible budget, and there’s nothing wrong with that. It's reality. Embrace your constraints.
But fixed resources are always better spent building a more focused, streamlined product and then being able to test, iterate and optimize it, rather than squeezing as many features as you can out of a given budget.
And that’s why our proposals often look like we’re offering fewer deliverables than our competitors under the same budget. We’re stripping down the app to its most important basics and leaving plenty of time for learning and improvement.
In my experience, a more focused product built by investing in testing and iteration is always more valuable (and more successful) than a large-scale app built blind from start to finish.
And that’s the difference between buying a product and buying an outcome.
~ Nick Kishfy (@kishfy)