Today I'd like to address one of the common phenomena which lead to cost and timeline inflation
of projects. Maybe you have witnessed something similar: At the beginning of a project, the team
makes a (rough) analysis of what will need to be done, how complex those individual parts are
and how long (roughly) the development will take.
Say we're creating a simple email client application. The key parts we know of are the message
inbox, message viewing, email writing, sending, and logging into the email account. Just a few
key areas, nothing complicated. At the beginning of this project, the team reckons that spending
a month on each of these areas should more than suffice.
They set off developing. After the login functionality, the product owner prioritises the
development of the message inbox. The devs put the inbox together and after 3 weeks they claim
it is done.
The testers and the product owner inspect it. They fill in the username and password, push the
button and see a list of e-mail messages - it works! But the product owner and the key users
think there is just too little information visible in the inbox's message cells and want to
improve it. So what if we added two lines of text preview instead of one? Or is one better, so
the user can view more messages at once? Or maybe let the user decide for himself and let's add
a setting so that the user can set how many lines of message preview he wants to see.
It's also not visible which people were CC’d. So let's introduce another setting, where the user
can toggle the display of CC'd people in the inbox. There is also no indication if an email has
an attachment or not. So of course, while we're at it, let's put an icon there to indicate
attachments. Also, some mail clients group message threads together in the inbox - that's a cool
thing we'd definitely like to have in our app too! And just like that, there comes message
Let's do all of this now so that we have the inbox completely done and we don't need to get back
to it later.
The perfection pitfall
I think you see where I'm heading to. Weeks pass by and we're still doing the inbox. After 3
months, we have a pimped-up inbox that everyone is proud of. We've taken half the time
originally estimated for the whole project just for one feature area. But what value is the
whole application to the actual users? Still very little. I can just view my messages. In a very
fancy and configurable way, true. But I still can't open the message and reply back. There will
be some sleepless nights later in the project.
Everyone wants to have things perfect - meaning nothing else can be added. It's a
natural tendency of people and I've seen that on projects over and over again. Project managers,
product owners, developers, key users, stakeholders, all of them want to have that perfect
It seems logical to develop features that contextually belong together at once and make that
application part perfect, like doing all inbox-related stuff at once. In my opinion, this is one
of the biggest project traps - it leads to scope creep and the actual project goal drifts
Minimum viable product
Is there a better approach? I believe there is, but it requires discipline. Firstly, we need to
cut the application by user stories (end-to-end use cases), which bring actual value to users.
Is a stand-alone log-in form worth something to the user, if the app then does nothing else? No.
Is a Reply button worth something, if you can't send the message afterward? No.
We need to build something that is useful and usable, not a bunch of independent technical parts.
Only then can we also verify the product's function. We are building apps for the end-users, so
we need to assess the application's quality from their point of view. In other words, we need to
cut the items into the product backlog vertically - across all technical layers, not
horizontally. In such a way, it incorporates all the necessary technical aspects to finish a use
Secondly, we need to know why we're building the product. Maybe you've heard of the minimum
viable product> approach. An MVP is a product with the least functionality possible, but
fully usable, useful, and enabling gathering feedback from users as soon as possible. Put
another way, you can't remove anything more from the product while still keeping the product
useful. We're doing the bare minimum to solve the user's main and most basic need.
Key questions to ask
The team (not just the product owner) must understand from the very beginning the answers to the
following two questions:
- What is the problem we're trying to solve? What is the most basic nature of the problem
we're sorting out for the user?
- Who are the people using the application?
With this in mind, every single backlog item can then be critically evaluated:
- Is this item/function solving the core user's problem?
- How can we simplify it and still solve the core problem?
- Isn't there any backlog item more important, without which the app does not solve the core
problem and is therefore meaningless?
This approach is basically about figuring out what else is there that you do not need to do
now and can leave for later. And doing that in a brutally honest way.
So what could this look like with our e-mail client application? Let's say the target user is a
person who would use the app for his personal email account, not a power-user or a corporate
user. The core need of such a user would be basically to be able to view incoming emails, read
them, and write new ones.
Our aim then should be to develop a trivial application doing just the necessary things to finish
these use cases and to do it as quickly as possible. Does the user need rich text formatting to
send a mail? Definitely not. Does he need marking messages as read? It's a useful feature, but
he still can perform vital use cases without it. Does he need to delete a message? Sure it's
good to keep the inbox organised, but still - even though not comfortably, he can live without
I am not saying you won't ever add features that are not vital. But the initial aim should be to
develop a bare minimum product that does key functions, see how much time we needed,
did it cost, how many resources do we have left, and then decide on what to do next. With this
approach, we increase the chance that before our budget or money runs out, we have at least
something useful that we potentially can put to market. This is how we can approach the project
risks by managing scope very actively.
This is contrary to the common situation, where we have certain areas of the product working,
including nice-to-have features, but we're still lacking coverage of other key use cases even in
a very minimal way. That's bad, because now the product can't be used at all, and resources
spent are sunk unless we invest more to finish the critical stuff. It is worthless at this
Imagine you need to present both variants to the project sponsor after running out of resources.
Will it be easier to say that the application is essentially working, but there are not enough
resources to make it more user-friendly? Or that you have a cool inbox, but the user still can't
send an email?
So once we have the MVP, a good idea is to give it to a group of users to gather feedback from
them as soon as possible. If we still have some project resources left, let's use them to make
the product better, like developing marking messages as read.
On the right way to good quality product
I hope you did not get the impression that I am suggesting building a product with a poor user
experience. That is not true. The basic idea I am presenting is to get the most out of the
resources we have. Let's act as if everything could go wrong and our resources were extremely
And if we build our MVP and see we still have enough time and money, of course, let's add more
and more cool features. But you'll be adding these features in peace knowing that you have no
debt; that if you stopped developing at any moment from now, you made the product most relevant
for the users as you potentially could, with the resources you had; that everything in the
backlog is less important than what the product already contains.
Does this guarantee you won't ever miss a project deadline or budget? Not at all. But it gives
you a bigger chance it won't happen. You achieved the best possible return on investment given