During my time as an engineer, and maybe even more so as a product person, I have heard (and occasionally thought) “Why are we having to change this? we should have just done the job right the first time!”.
The simple answer is that we didn’t know what to build the first time around!
I could end this post here and relax in the knowledge that I have just given the correct answer. However, the conversation never ends there! The follow up to this is often something like “but you are a product guy, you should be able to work out what we need BEFORE we build it!”. If this sounds like something you may say or hear on a regular basis then sit back, get comfortable and enjoy the rest of this post.
The basis of the question
The problems here begin with the fact that this is not an unreasonable question when taken at face value. I mean, really if you are doing work and then changing it surely that is wasted effort and should be reduced or even eliminated.
Along the same lines are the “Measure twice, cut once” kind of people who want to plan everything up front.
I can understand where people are coming from here, obviously if we can design everything up front and we can eliminate mistakes via good design then we can have a smooth path from start to finish of our project. Unfortunately, this thinking is flawed.
The future is unknown to us
Software projects often begin with a requirement gathering phase. This is where someone goes off and tries to figure out the detail of what should be created and a specification of one sort or another is produced.
The quality of the requirements gathering exercise and the detail of the specification is largely irrelevant to this discussion. The fact is that however well this phase is done it will almost certainly be wrong. There are circumstances where this does not apply, if you are making a really simple application or something very specific like embedded systems for controlling a spacecraft for example, but for the normal line of business applications that most of us build I stand by my statement.
The specification will be wrong for one simple reason. Your users do not know what they want until they use it. You will have in your possession one of two things. If you are lucky you have a problem statement for which your users are looking for a solution. Otherwise you have a specification mapped out by a user (or group of them) who do not know about code, usability or any of that stuff.
Being as your users cannot try the software they are asking for they cannot know what it will really be like to use every day!
The Problem Statement
Let’s assume for the moment that the requirement gathering went reasonably well and you have a good understanding of the problem you are trying to solve. You can now go and design some software using all of the engineering and design expertise at your disposal. Perfect, you can come up with something that precisely fits the needs of the user.
In the real world, however, once the users get their hands on the software you have created they will begin asking for changes to it. And you are back into the whole “why didn’t we build it right the first time?” discussion.
User Specified Software
This is even worse, you have made a terrible mistake! Instead of being able to apply the skills of your team and having a fighting chance to produce something good, you went and asked the users what they wanted.
Now you are stuck, your engineers and designers know that the design is flawed before even getting started and your users are excited about their vision being realised in code! The disappointment when they get their hands on it will invariably lead to changes coming thick and fast and you will be back to the question that forms the basis of this post.
Product Discovery and Agile
Okay, so most folk are doing a form of agile nowadays. The reason for this is that the proceeding sections are well known to us in the development world. Build something simple, get it into the hands of the users and get feedback and iterate.
Guess what, based on that feedback you will have to change things, the software will not be right the first time.
What does this mean for us? Simply put we cannot know what the users want before they have enough of a product to work with. As the software is built, we have to keep in mind that the requirements will change (it is in the agile books that “we welcome changing requirements, even late in development”) so make sure that it is easy to change the code!
Product discovery is a series of experiments, each one taking us closer to the optimum solution. Each one subject to change to suit the customers needs.
That is why we did not build it right the first time!
Dan On Agile 
Leave a comment