While working on software systems and products we often find ourselves having to make choices between naive solutions (cheap) and solidly engineered solutions (expensive). It’s a balancing act.

On one side, we don’t want to underestimate the complexity of the solution and provide a solution that underperforms and disappoints. On the other hand, we don’t want to over engineer and provide a solution that has too many features and burn through all the time that could’ve been used with useful iterations based on feedback.

To make this problem even more challenging, our teams are composed out of people with different values. Some team members value up-front planning and edge-case exploration. Other team members just want to get started shipping as quickly as possible and figure it out as they go.

How can you and your team settle on a solution that is as simple as possible, giving you time to learn from feedback and data and iterate on the initial solution, while still making sure it’s complex enough to give it a chance for success?

First, get the team spitballing the absolute minimum that you can do to satisfy the system or product need. The solution needs to be adequate for the problem at hand but should be very rough with loads of gaps. Your team can have a lot of fun with this and it can be quite hilarious to brainstorm the bare minimum ideas that you know will never be shipped! For example: “why do we need a UI, can’t we just give them a shell script?”

After doing this, target the opposite extreme. What is the most you can do to solve the problem at hand. This can also be a very fun activity! How often do you get a chance to kick around extremely elaborate solutions with your colleagues? For example: “we don’t even need a UI, let’s just use natural language processing to get input from the user!”

Now that you collectively settled on the minimum and maximum solutions, you can start getting realistic. In most projects, you’ll find that you can achieve most of what you need to achieve with much less effort than you might think. This is called the 80/20 rule, also known as the Pareto principle. The magic part of any solution is settling on the best scope with the right level of complexity. It always astounds me how easy things feel after reaching this point.

If for some reason the solution turns out to be flawed, you’ll find out soon enough. Don’t fall in love with the solution and just stick to it. More often than not, your plan just needs a bit of tweaking. Whether it requires tweaking or a full-blown pivot, you might benefit from repeating this activity with your team to settle find the correct scope again.

How do you and your team settle on scope? Do you have any similar activities that you can share?