I like small, frequent product releases. These tend to be less risky, offer more opportunities to learn, and provide potential value sooner. However, this does not mean mindlessly pursuing quick wins, or even that these quick releases will on their own be particularly monumental. There are no shortcuts to making an impact: one still needs time, focus, and patience.
Here I go through three different examples of good things you cannot hurry: the cumulative return on investment, building a comprehensive feature set, and the number of iterations you need to go through to learn and ‘get it right’, as it were.
The compounding returns of iterative refinement
Smaller releases can vary in impact, but a single improvement is rarely a game changer. However, if you keep your focus on a certain area the cumulative improvements can add up significantly. Below is a nice example of this from Pitch, a presentation software which prides itself on its slick design and user experience. Having used them for a while, this is certainly warranted, but they did not get there from one day to the next.
None of the improvements shown in the tweet will on their own have caused much of a stir, but six months down the line one can really see the difference. It demonstrates how sustained focus on a problem can lead to vast improvements in a short amount of time.
There are two key takeaways from this. The first is that it is important to resist the urge to switch from one problem to the next, as this will prevent you from solving a particular problem very well. You should therefore take some care in identifying the right problem to solve.
This takes us to the second point. Know how an individual improvement fits within a larger constellation of work. If one had looked in isolation at any of the minor improvements in the example above, none of them may have been implemented as the benefit from each one would have been deemed too small to make it worthwhile. However, by focusing on the underlying problem, one can start to see how they all jointly address it, and the cost-benefit analysis shifts. The whole is indeed greater than the sum of its parts.
Getting to a comprehensive feature set
As Ben Horowitz writes in The Hard Thing About Hard Things, there usually isn’t a single silver bullet that will solve a hard problem, but rather that it takes ‘lots of regular bullets’. It does mean though that you need to be in it for the longer haul if you intend to make more meaningful progress on harder challenges.
One example of this are the several ways in which people can extract their data from ChartMogul. ChartMogul calculates revenue data for SaaS businesses and, as I wrote at the time, a lot of the value of such a data product comes from people being able to export data and put it to work. However, different people will have different preferences on how they want to extract their data, and they may well require different implementations.
For instance, CSV exports obtained via the UI are easy for anyone to download, but it is a process harder to automate or to interact with programmatically. Conversely, the API endpoints fit this use case a lot better, but these require technical know-how and more work to set up. ChartMogul also provides direct integrations with different tools which can remove some of the technical complexity, but it doesn’t help you if the integration to your particular tool does not exist. An integration to Zendesk will be of little use to someone using Intercom instead.
ChartMogul caters to these different customers and use cases, but it took years for these different options to be created, and they are still being improved and added to. Remember, it is a marathon, not a sprint.
Learning through iterations
Eric Ries’ book The Lean Startup popularised the cycle of ‘build, measure, learn’. The loop is fairly self-explanatory: you build something, you measure how it does, you learn from this, and then you repeat the cycle. The more times you iterate, the more you learn and the better the product ends up becoming. However, one shouldn’t let the limited number of steps in the loop deceive you: the real world doesn’t tend to be as tidy as this. You may have to go through the loop multiple times before you achieve the desired effect, and other work will also get in the way of doing multiple iterations. Furthermore, sometimes it can take a while before you start seeing the impact of your work, which also postpones how quickly you can learn. Perhaps you made a new API endpoint available to your users, but the technical implementation required on their end may cause you to wait for longer before they are able to interact with it.
All of this is to say that the learning itself will always take time, and sometimes there is a limit to how fast you can validate your assumptions.
Enjoy the journey
Building products takes time, especially good ones. No great product got there overnight, and that comprehensive set of features you see in mature products wasn’t all there from the start (think of how you couldn’t copy and paste on the first iPhone). Furthermore, and you can call me cynical if you want, but there will always be bugs and issues to address. This makes it even more important to celebrate your victories along the way and to see how much progress you have already made.
I will leave you with a final tweet.
Ten years in, it feels like we’re just *now* starting to properly internalize the possibilities of the space in which we’re operating. The bad news about Stripe is that infrastructure takes a long time to build, but the good news is that the benefits can compound for a long time.
— Patrick Collison (@patrickc) September 29, 2021
While not all products become great with time, no great product got there overnight.
Leave a Reply