Less is more - "You're better off with a kick-ass half than a half-assed whole."
The art of deciding when to stop.
Introduction
One of the muscles that big companies used to workout when they were smaller is the practice of delivering quickly and often.
This is also true among human-beings, when we start some endeavour we tend to focus on some tasks. As we evolve and become proficient, we change the way of doing things and put the focus on other things, dismissing the tasks we originally started doing. It is like a muscle, as you keep moving it and train it, it keeps fit, and it costs you less to lift things.
The analogy could be the same in companies that used to deliver often and quickly to customers, and what used to take days / weeks, now it takes months / years.
What I would like to discuss today is how the habit of making trade-offs when building things, could help you to deliver value sooner.
Why does this happen in the first place?
I was listening the an episode of the 37signals podcast, where they were discussing “how to master the art of timely product delivery, without sacrificing quality”, and in order to do that you must know when to stop.
There will always be more features and things to build than the time available, therefore is super important to be deliberate on when to stop, take the plunge and deliver.
Some of the symptoms that I’ve seen over the years that exacerbates this situation of not taking the leap are:
Do you really understand the underlying struggling moment?
I love the image from Shape Up where it outlines the importance of setting some boundaries when it comes to tackle a specific moment.
Sometimes we take the request from customers, support, or sales too literally and we jump automatically to see how the solution would look like in the current product.
I want to recall you that your job as a PMs is to ensure the team works on the most important problem, unpack the whole problem, and detect the rabbit-holes that could render the work endless.
One huge advantage that we had at Nexthink was that our product leadership team was obsessed with making sure we have a clear definition of the problem space and we have a clear answer for, what is really broken here?
Fixed scope, variable time
History has taught us that when we start to postponing things, an we want to keep improving, enhancing, or adding things, because it is not “done” yet, we tend to delay the delivery.
That is one of the reasons that in my opinion, estimates are not used for the job they are supposed to. If your team tells you that “this work will takes us 3 weeks to complete”, you hit the 3 weeks milestone and what happens?
Most teams don’t stop to reflect whether or not they have completed the most important thing and omit what is a nice-to-have. They forget the estimation, and take the scope as something sacred, and keep cranking on, without asking themselves whether keep working on it has diminishing returns, and the work is ready to be shipped.
This is Fixed Scope, Variable Time, not the other way around.
Good is relative
If I ask you, Do you prefer a juicy piece of stake or a slice of pizza? Probably neither of those options. The ultimate meal might be a ten course dinner. But when you’re hungry and in a hurry, a slice of pizza is perfect. When you work without constrains and unlimited amount of time, there will always a better version.
Coming back to the previous example of using estimates, I believe there are too bendy to work as a constrain to force to define a good version. We will see different alternatives to address this issue.
What can you do to avoid it?
At Nexthink we were maniacally focused on preventing the previous symptoms, and I’d like to comment on some of the tools and dynamics we have put in place to not falling into the trap of keep going in circles without pushing the product to our customers are:
So tell me what you want, what you really, really want
As I’ve previously mentioned, as a product team, we were in charge to explore the problem space and understand really what was the main use case for our customers. We used to use a mechanism that resembled the Spice Girls, tell me what you want, what you really really want. It was a way to force us to assess if we were going into the bottom of the real issue and not keep the problem at a shallow level.
With time we started to refine a bit the questions we were asking ourselves to ensure we were unpacking tons of unknowns and decisions that would drastically affect the scope.
Instead of asking what could we build?, we veered the conversation towards At what point specifically does someone’s current workflow break down without this thing they’re asking for?
Fix Time, Variable Scope
This is one of the main principles of agile. That’s the reason scrum suggest a time-box, Shape Up works within 6-weeks cycles, and so on. Without getting into the details of my personal preference, we had something similar at Nexthink.
The premise we had was to define a 5-weeks cycle (4 of pure development and 1 of alignment) where every team knew that at the end of the cycle whatever was ready was going into production. We had 10 times a year (roughly) to deliver a compelling solution to customers’ problems.
Without getting into the nitty-gritty of the process, setting an enabling constrain forces you to make trade-offs and clearly defined what is the core to the product and what is peripheral or unnecessary and how much time and attention the subject deserves.
It may sound simple and sometime demoralising having your manager and the leadership team pushing you to deliver. But delivering creates momentum, and you will go faster since the moment the product gets into your customer’s hands, you can start getting feedback. There is nothing more exciting that see how to improve / change your product for the better.
Good is relative
I think we can agree that the best version of something, especially in product development, is bit an illusion. It will always depends on the constrains we are playing with.
We haven’t formalised at the time I left, but we have started to have conversations with the leadership team, when an initiative was presented, how much time we were willing to dedicate to this. We had conversations about the expected value, and why X timeframe and not Y. In those situations is when we pulled the most creative solutions from our team.
There three important things you clarify within your team and the product leadership team to avoid running in circles and :
- Assign a budget to particular initiative. How much are you willing to spend on it
- List of constrains you are playing with, either if it’s a specific deadline, event, lunch from another team, whatever
- Expose the trade-offs the team has considered to deliver a specific version of the product. Why are you making them?
- Visualise where the different parts of the product are (we used something similar to the Hill Chart in Basecamp to make this decisions). This will help you to make decisions and differentiate between the must’s and nice-to-haves
Other tools that could help you to think in the must vs nice-to-have are:
Target Quality Framework by Shreyas Doshi
or the famous Good, Better, Best (I came to know it thanks to Jeff Patton).
Conclusion
My idea with the article was to push you to break the cycle of keep iterating without delivering.
Sometimes is difficult to know when to stop, but if you think you must build the most perfect piece of software, you are too late to getting feedback, so cut your ambitions in half.
Don’t forget that you are better building half a product, than a half-assed product.