Abraham Lincoln has been quoted saying: "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." As it turns out, he probably never said that at all. But I still think we can learn something from that advice, despite its uncertain origins.
Preparation
In its most literal sense, the expression reminds us that time and energy spent in preparation tends to pay off by allowing us to do the actual work more efficiently. In the physical world - as in the tree chopping example - this may seem blatantly obvious, but it turns out that applying that thought to software development isn't quite as simple.
Maybe we're about to add new functionality to a large, existing code base. Preparation might include figuring out which refactoring steps will be necessary, so as to avoid heading down a dead alley. Or we might find that we need to introduce a new 3rd party library, or integrate an external service which we know little about. If so, proper evaluation of the available options might pay off dramatically: We don't want to be two weeks into your work to find out that the approach we chose isn't viable for legal reasons, or that our new module won't fit with the overall architecture.
For many of us - including myself - this can be hard. It takes real mental effort to say no to the urge of jumping right into an "interesting" piece of work. We might be attracted by the shiny new technology we want to put to use, by the pleasant anticipation of a customer using the new feature, or simply by the basic human urge to create. Often the solution that initially springs to mind is so simple and obvious that we're convinced that any additional planning would be a waste of time. But as it turns out, taking a step back to reflect (privately, or together with our team), and approach our work with a freshly sharpened axe usually pays of. My humble guess at least is that it does, more often than it doesn't.
Doing the thing right
In agile methodologies we use dedicated planning meetings for that kind of stuff, and for good reason: Different people on the team bring different perspectives to the table, and might think of different things we haven't yet considered. It's enlightening to have QA, tech support, and sometimes even marketing and sales people on board when discussing how a new feature will look like. Those folks often have a more customer and market focused point of view than the developers, which helps spotting potential weaknesses in the proposed solution before the first line of code is ever written. At that stage, we can make the required changes quickly and easily. Plus, having talked to everyone on the team beforehand we can be confident that there's more common understanding, more alignment, and more agreement on what we're doing than if we had just started to build the first thing that came to our minds.
Doing the right thing
Above and beyond planning to make sure that we build our product in the right way, there's an even more fundamental aspect to sharpening one's axe that needs some consideration: What good is the worlds sharpest axe if you use it to chop down the wrong tree? Or worse, if you approach the tree from the wrong angle and it ends up falling on your roof?
In the context of product development, that's where the role of product manager comes in. You can have the best technical team building the best product, but if the problem it's addressing isn't one that anybody is willing to pay the right amount of money to have solved, then the whole endeavor is doomed. Of course, trying to answer questions like "How much are people willing to pay for this?", "How many units will we be able to sell per month?", or "How many new customers can we acquire in a quarter?" seems like reading tea leaves, and in many cases it is. But the point isn't to answer any of those questions accurately, or even in a scientific manner. The point is to approach them more like Fermi Questions (think "How many piano tuners are there in New York City?"), which are not aimed at getting a correct answer, but learning something by applying a systematic approach to the question.
Just by forcing ourselves to actually think about how many potential customers there might be in total, how many of those we think we could reach with reasonable marketing efforts, what percentage of those would then actually buy our product or service, and what price they may be able and willing to spend, we can already learn a lot about the problem we're trying to solve. If we want to build a highly technical product for example, one which will be of use to software developers, we might conclude that the amount of money they would be willing to spend to have that particular problem solved is close to zero. That target persona is used to leveraging free and open source solutions, or building their tools themselves, rather than spending money on commercial offerings. Of course there are notable exceptions to that rule: JetBrains for example seems to have found a commercially viable model serving that exact market. We might then turn our thinking in that direction: What are they doing that works? Could we replicate that for our product or service?
Of course, all planning, guessing, and pondering only takes us so far. The next step after we have made some basic assumptions is to try to validate them in the real world. Is data on the size of the potential target market available? Can we run an experiment to see how many of our potential customers would click our online ads? How many of those clicking the ad would be willing to sign up for a waiting list or newsletter? This is the point where the concept of validated learning, borrowed from the Lean Startup methodology, can really shine: Without having to invest a single dollar in product development, we can already learn a lot about the commercial feasibility of your product idea, just by running some cheap experiments.
Alignment
Once we start to honestly engage with the questions from above, we're also forced to think through our ideas more from and end-to-end perspective. That again can help impatient people like myself to resist the urge to jump right into problem-solving mode, and instead take a birds-eye view of the entire endeavor for a moment. Doing that can pay huge dividends when it comes to prioritizing our work - a topic I touched on in my previous post.
Let's say we're building a SaaS product, and plan to sell it directly through an online channel. The end-to-end process that generates value (that is, revenue for our business), could look roughly like this:
- Customer learns about our product
- Customer visits our website
- Customer signs up for a free trial
- Customer actually uses the free trial
- Customer finds the product so valuable that they decide to buy a subscription
As technology focused people we may be tempted to spend most of our time and energy on work that benefits step 5 (and beyond) of that process: We want to add a myriad of features to the product so it'll become the best, the greatest, and the most valuable. What use is all of that though, if the first time user experience is so bad that most potential customers wont make the conversion from step 3 to 4? Or if the features we offer are so diffuse that once they're in step 4, they don't see that value we provide, and refuse to convert to step 5?
Again, those considerations may not be as fun as implementing "Awesome Feature #17" from our endless development backlog, and prioritizing to work on them can be a real mental strain. It can also feel unproductive because we're not generating any value by silently sitting in a corner and thinking. But by honestly engaging with the end-to-end process that will lead to revenue we might again gain some interesting insights: We might learn for example that our product is too expensive to be sold online, so why bother with the whole idea of the online trial? In that case, our efforts would be much better spent in building an excellent team of field sales people, rather than polishing first time user experience for unattended usage. Or we may find out that the online ads required to drive people to our website are too expensive, and we would end up losing money acquiring customers that way. Again, small experiments that generate actionable insights can help us turning that guesswork into a more reliable process.
Conclusion
We covered a lot of ground in this post, and for good reason: Sharpening one's axe can mean very different things in different contexts. Depending on our role it can mean just a second of pause before writing that first line of code, or rethinking our entire business strategy. Regardless of the scope of our actions though, I'm convinced that a second of pause, reflection, and preparation seldomly hurts. And that's not only true in wood cutting and software development, but a valuable lesson for life itself.