The five strings paradox
In software development, especially when talking about budget and/or time-constrained projects, five characteristics have an interdependent behavior that is usually overseen or disregarded. I’m talking about quality, time, budget, complexity and scope.
The five-strings paradox is a metaphor we use for the relationship between these five concepts.
Imagine each concept is represented by a string where each string is the same length, and the project we are trying to build is in the center connected to all five strings. When you pull from any of them the others are inevitably affected, there’s a delicate balance and influence between the five.
For example, let’s imagine we want to make the project move faster. So we want to make the time string shorter, meaning that we need to pull from other strings: either the project becomes more expensive (more people in the team, or more extra hours); or we make it less complex (eg. single step user onboarding flow vs guided multi-step onboarding); or with fewer features (eg. leaving that subscriptions module out of scope); or lower quality (eg. we don’t build a comprehensive automated test suite).
Flexibility
Some of these threads are more flexible and stretchy than others. From our experience, we know that quality, time, and budget are the most inflexible ones:
Nobody wants a poorly constructed product, no matter how cheap. So we never trade with quality.
Money doesn’t grow on trees, so the budget is quite inflexible too, especially in the case of MVPs.
And the market opportunity windows won’t be opened for ages waiting patiently for us to ship a divine product, so even though time might be a little bit more flexible than the previous ones, every software project has an ultimate deadline that’s non-negotiable.
The solution(s)
So that leaves us two manipulable strings to drive the project to a good port: complexity and scope.
These usually work in tandem mixed up but they are separate concepts and we use 2 powerful tools to steer them:
1) Feature filtering: When building MVPs we classify the features into essentials (the main features that define your product), nice to haves (features that can provide value, but won’t halt the shipping of the MVP if they are not there) and out of scope (features that would make sense to have in the future, but won’t be developed in the MVP). We try to move as many features as possible to nice-to-have and out of scope and focus on the essence of the product.
2) Scope hammering: We try hard to make a feature fit into a given timeframe, without breaking the essence of the feature and always thinking about delivering a complete thing. Always prefer a usable small feature instead of a not usable half-assed complex feature.
Strive for simplicity
We are firm believers that less is more. It’s easier to say yes to everything and end up with a set of features that make the time string longer along with other strings (complexity, scope, and budget most of the time). While there’s no intrinsic problem in doing so, it’s extremely important to find a good balance between them. Especially when building an MVP or any other kind of product where time is a constraint (and sometimes, budget too).
Striving for simplicity is usually a good way of finding such balance.