I have encountered this problem over and over again; Software teams who aren’t capable of designing the product they are trying to build.
I get it, designing the product can be difficult and boring work. You need to have long discussions, you have to write stuff down (God forbid), create wire-frames, flow charts, and it might be that your pet “pony” feature doesn’t make the cut. It’s just so much easier to avoid all this and to just jump in and start banging out code so it looks like we’re all very busy and making good progress. Initially this will seem to work, because you go from nothing to something, but for long term productivity this just won’t hold up and sooner, rather later, it will all come crashing down.
But I’ll let you in on a little secret; If you can’t create your product on paper then you can’t create your product in software.
So, there I said it. Sure, you can just jump in and bang out pages and pages of code, build screens, fiddle with servers and what’s not, but what are you actually working on? What are you working towards? Where are you now and where are you going to be in a year, a few months or even a few weeks from now? Which features need to be implemented first and why? And even more important, how “exactly” are these features going to work? How do these features make sense within the context of the product, the customers and sales? What dependencies are there between features? Should we implement some features in a simpler form first? You want to have these questions answered BEFORE you start building your product, not WHILE you’re building your product.
At this point you might start pointing out examples of a bunch of guys who’d just made things up as they went along and became gazillionaires. But the truth is, you’re not them and for every bunch of guys who did became gazillionaires by just making things up there are hundreds, if not thousands, of other guys who failed miserably and whom you’ve never heard of.
Why is having a plan so important?
A plan, or product design, allows you to communicate with the team about what it is you are building in a consistent way. The human brain is a funny organ. It seems to fill in the gaps that where missing or it has the ability to swap out one thought for another without realising it did so.
When you have a meeting with the team about the product and you don’t write things down, the following will happen; After the meeting everyone goes their merry way and later when it is time to work on what was discussed in that meeting, not only will you not have all the details ready to actually start work but everyone involved will have a slightly different recollection of what was discussed and everyone will therefore have slightly different expectations. A discrepancy that will be amplified by the passage of time.
Let me illustrate a common scenario; A developer starts work on a feature and since code is going to be written, he or she, begins by breaking down the feature into logical steps. You see, when you’re writing code you’re working on the lowest possible level of detail and you need every tiny bit of detail to be able to actually write the code. While breaking down the feature into logical steps they discover that it’s unclear how exactly the user interaction with this feature is going to take place and therefore how “exactly” the UI is going to be constructed. So, the developer asks the question; “Hey, how is such and such feature going to work?”. Presto, everyone in the room jumps into design mode and people will either come up with the most elaborate ways of solving the problem at hand or will creatively invent entirely new functionality and features on the spot. What was estimated as a two day job has now become a three week death march. This happens because there is no context of scope.
Not having a plan WILL lead to unmeasurable scope creep.
By creating a plan you can easily solve the majority of problems you will run into. A lot of time goes into building the boilerplate of a product, the things we take for granted or assume to be obvious. Obvious until there are numerous people with various tastes, ideas and expectations involved, then suddenly things aren’t so obvious any more. It then seems that that button can be placed in an endless variety of ways, and which is the correct one? By creating a plan you’re forcing yourself and the team to go through the entire product, from start to finish before you actually start implementing it and it will allow you to solve most of these problems before any code is written. When you build a product there will always be problems but by making a plan it will allow you to solve most of them before hand so that when you do encounter a problem, it’s likely to be a genuine issue.
The other benefit of a plan is that you can now communicate “consistently” what you’re building. If you don’t have a plan, the perception of what you’re building will change over time, since nothing is concrete. Like I said earlier, the human brain is a funny organ, it will just fill the missing gaps and after a while it will take those filled in gaps as permanent fixtures, as if they where always there. Building a piece of software can take a long time, many months if not more. During this time you will be influenced be external impulses, your insight into the problem domain will increase and you will start to see things you didn’t see earlier. If there is no frame of reference, everything will continuously be shifting without you actually being aware of this. This is dangerous territory to find yourself in.
To communicate consistently about how your product will work “in detail” will also help you when you bring new team members on board because you will be communicating the same details over and over again rather than the flavour of the week. New arrivals will be introduced to the same detailed feature set as everyone else is working on.
Can a plan be changed?
Of course. But by having a plan that consists of a number of documents etc, it will be more difficult to change, and for good reason. Once you have a plan you have to go through a process to actually make changes to it. The changes have to be discussed and someone has to write down those changes. Making changes now becomes more difficult which means that things aren’t likely to change all the time and on a whim. A plan will create stability.
Ideally at least one person on the team has ownership of the plan. We usually refer to this person as “the product guy”. You need to have good technical insight, understand how user interfaces are build and the ability to communicate through the written word. If you don’t find enjoyment in writing things down in minute detail, then this is probably not a role for you since you’re basically programming on paper. As a product person you represent the product and you need the ability to curate functionality which means you need the ability to understand the product on an intimate level, inside and out.
Not having a plan is setting yourself up for failure. Having a plan will allow you to communicate about your product and it’s features in a consistent way. Having a plan will drastically reduce scope creep and it helps developers and designers to focus on building the features rather than having to work through a series of unnecessary puzzles on a daily basis. Having a plan will create stability during your development cycles.