It’s been a while since I have first started looking for relevant resources about how we can find “a right thing to build” on our own. Almost every geek friend I personally have and almost any colleague of mine at comSysto dreams about building their own product at some point, not necessarily in order to earn a few million (though no one would actually complain about that minor side effect) but rather in order to be able to decide on his or her own what approach and frameworks are to be used and what features are to be built. The motivation that I have just described is probably one of the major reasons why we haven’t yet managed to successfully keep the product in the market unfortunately. While we constantly improve our ability to eliminate waste in our software development process by applying most of the extreme programming practices, following Scrum and Kanban as management frameworks as good as we can and striving to achieve continuous delivery at the end of that process, we have had little or no experience at all about how we can prevent the actual software being delivered to end up being waste itself. Continuous delivery of a software solution for a problem that no one has or no one is ready to pay for at the end is nothing else but the continuous delivery of waste.
One of the first books, if not the first, I have purchased in my quest for the holy grail of product development was the book called “Designing For Growth” written by Jeanne Liedtka and Tim Ogilvie and published by the Columbia Business School Publishing. It more or less starts with a brief description of Apple’s own design process (“wow this might be the only book I’ll have to read” … I though at the time) which looks exactly like this:
After having stared at the picture above for a few seconds or so, I figured it must have been meant as a subtle joke and continued to read further to find out more about the concrete approach to business design that has been nicely described in that book.
It was almost a year and a dozen of more books later that I have returned back to that rather interesting description of the Apple design process pictured above. It got much more interesting after I have tried to describe the approach we have mostly been using to build software products up to that point in a similar fashion:
I guess this one looks kinda subtle too ;).
The first significant difference between the two is to be identified on the left side of the picture already. Instead of starting with a problem to solve we usually started with a great idea for a solution someone in our team or company has had. The solution almost always involved some kind of a new exiting technology (framework, tool, language – you name it!) that one can use now and wasn’t able to use before.
The second difference is obviously the process itself. After enough have fallen in love with the idea described to us in very emotional and honest way, we have usually started building the solution in the right way that we have practiced so many times before: setup our initial product backlog, start with tests first, setup our continuous integration environment, write some clean code together, enable continuous delivery and on top of that use that nice and shiny state of the art technology every one of us loves. Life can indeed be so great and fulfilling at times …
The third difference is unfortunately as one might have expected already the outcome itself. While completely focused on being agile and lean, eliminating waste along the way as much as possible, we haven’t noticed until the very end that the final outcome of our work and effort itself will become nothing but waste.
One could modify the first picture describing Apple’s design process slightly into the following one in order to make it a little bit more expressive:
By looking at the picture now one can easily see many of the artifacts and patterns identified by Lean Startup and Customer Development like: validated learning, minimal viable products, pivots etc. It basically represents an iterative process of not only the product development itself but a process of parallel product and customer development based on feedback loops and validated learning. What we have unfortunately failed to do before, as many other technology driven startups still do, is to leave our comfort zone full of unit testing, continuous delivery, cool shiny tools, frameworks and languages and do much more customer development along the way.
It’s only if you get payed for doing things you love that you will be able to keep doing them in a long term. Otherwise you’ll be forced to give them up since you’ll run out of money eventually.
P.S. One additional note about the initial idea in the process of continuous delivery of waste
Usually there is one major criteria that every idea used in this process has to fulfill – it needs to be really and truly new! Otherwise it will most probably not survive first discussions of the project team about what to build. Well, this is unfortunately another common misconception and it actually increases the risk of delivering a product that nobody wants at the end. One of the possible reasons why there seems to be no similar solution out there is that there is actually no market for the solution you would like to provide. Combine this risk with the fact that the team is most probably to do almost no customer development along the way and continuous delivery of waste is all you’ll get.
Instead of searching for a truly new idea at the start of a new venture one could focus on knowingly choosing the right competitors to tackle. Eric Sink explained that approach in his great book “On The Business Of Software” by introducing the following matrix:
The best approach is to find a competitor who is “big and dumb”, thus is residing in the first quadrant. Choosing a competitor who is “big” makes sure that there is a real market for the solution you are building. You still need to do a lot of customer development along the way of course since you have to be different from you big competitor in at least one important way. You are basically looking for a solution that will serve the needs of a particular niche of the market you are targeting better than your major “big” competitor.
The same matrix can, by the way, be used to rank management staff of your company also. Two colleagues of mine did exactly that just for fun during our last lean workshop. I can’t unfortunately publish all the results of that analysis here but I can at least disclose that I sure did end up being “big” ;).