The greatest good, for the greatest number of users… Benthamism and Software.

We talked previously about what big buckets of work we should prioritize over others. Deciding where to spend time and energy is crucial to success. This time however, we’ll talk a little more about how to prioritize the work.

It will sound hokey, but Utilitarianism is one of the most persuasive ethical paradigms to use when building software. Utilitarianism holds 3 principles.

1. Happiness is the only thing that has intrinsic value
2. An action is right only insofar as it promotes happiness, it is wrong if it promotes unhappiness
3. Everyone’s happiness counts equally

In 1779, Jerry Bentham went on to specifically say of Utilitarianism:

“it is the greatest happiness of the greatest number that is the measure of right and wrong”

So how does all of that apply to software, and before you ask — what kind of craziness am I reading, let me start by rewriting those in a way that makes more sense to software.

1. Happiness is the only thing that will keep a user
2. Users will only use your product if it makes them happy, if it makes them unhappy they will stop using it
3. Every user is important

Rewriting Bentham’s quote:

“Providing the most happiness to as many people as possible is what keeps your product in use.”

So how do we use that in practice? How does this 200 year old ethical paradigm help you build good software?

As you start building your product, focusing on pieces that quickly create the most amount of value to your users is the way to do it. Remember, users should include both internal and external customers.

Consider an MVP (Minimum Viable Product), this is the smallest iteration that you can do which makes the product usable in the marketplace. An MVP is about creating the greatest good in its smallest increment.

As you build your product out, you add more and more value and happiness to it. Starting small though allows you to maximize your customer’s happiness incrementally, while maximizing everyone’s happiness. It’s imperative that all users be considered as part and parcel of any product. Often we build products that prioritize customers over the internal agents working on administrative tasks. Doing this adds costs to an organization, or quite simply, unhappiness.

Starting with a small scope MVP allows you to get something quickly to market, allowing you to not only perfect your solution for all users, but also to deliver value piece by piece. It allows you to respond to a changed marketplace with a solution that is perfectly aimed at providing the greatest value to the greatest number of users.

Consider the following — You have a team of:

• 5 developers

You are building a MVP which is:

• 1 new piece of automation to drastically reduce agent workload
• This automation also reduces costs for the company.

You uncover a:

• 21 day process reduction to notify customers
• This process reduces the amount of work for agents

However this find could delay the MVP by a month.

Do you keep building out the automation that’s MVP or do you switch on the other process and pull it forward?

Using the above framework, we can look at a couple of things, but it comes down to what you think would make everyone happiest. Which is more important to the customer, getting notifications 21 days sooner, reducing company overhead, or having the MVP delivered sooner?

The above was a real scenario we experienced, and we decided to switch our priority. We picked up the notifications work; choosing to delay MVP in order to maximize value for all users, not just the agents.

A framework like this helps you to steer the ship, by allowing you to focus on what really matters with any product. That people use it and keep using it. You do this by providing happiness to all of your users, whether they are customers, or the client.