Product development: Perfection vs. minimalism

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 grouping.

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 thing.

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 off.

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 case.

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.

Mailing example

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 it.

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, how much 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 stage.

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 scarce.

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 the circumstances.

Written by: @otakarkrus