Get the Design Right Before the Start of Development

We are currently working on a data intensive product. We have a great team - top class developers and team lead, a great system architect and I hope a pretty good product manager. The requirements are well understood and we received a well researched specification from the project sponsor. We are working using Agile and although this is a start from nothing project we produced some impressive user flows with demonstrable value even in the first sprint.

So as the product guy I am very happy and keen to demo the product to anybody and everybody.

There is, however, a problem. At almost every Discovery meeting, after every daily and at working meetings in between we change the data model, just a bit to tweak it; (almost two sprints into the development.) I have tried to analyse the situation and reached several conclusions. I don't think that we are tweaking it just for the pursuit of perfection. Almost all the changes are because there were some soft areas in the requirements and because the model isn't yet fully functional. I am sure that in another couple of weeks we will have resolved most of the issues and things will reach some equilibrium.

Secondly I think that the discovery team and developers are so switched on and involved that we are really working the topic. We get involved and we have opinions (and the problems are quite involved and tricky.)

As an aside; this intensive (re-)design method leads to uncertainty, the changes are so intense (and actually quite subtle) that the documentation is less than perfect. Partial explanation is found in different user stories with open editing rights. This makes things just a bit harder for the team. There is plenty of readjusting and rewriting.

My last conclusion is that in this project we needed a more traditional approach that involved a full system design that was analysed, debated over and clarified for a (hopefully short) period of time before the first line of code was written.

A stable well defined design at the outset would have saved us a lot of time, debate and on the fly design and development. It would also have improved the communication and stability through better design documentation.  I am sure that we would have missed a few points, but then the Agile method would have allowed relatively small and painless corrections.

I think that there are many products where more forethought before starting the sprints will lead to more efficient implementation (and necessary corrections) in the development phase, It isn't always easy to do this - often the requirements are still in development or there is pressure to start work, and perhaps in subsequent releases where the changes maybe quite small relatively it isn't even necessary. However, I think that it is a valuable question to ask when initiating product development can we improve the design before we start work? There is a subtle balance to be achieved between over design/slow customer interaction and impulsive coding/multiple revisions.

The Importance of Documentation

As PM&M we spend a huge part of our working day communicating both internally and externally. Despite this, we often get far into a product process and discover that somehow we don't have documentation or that we have very poor documentation. It may not, therefore, come as a complete surprise that we have a poor product definition and a weak customer engagement.

Sure, our creative skills and leadership mission don't leave much time for hacking away producing long word documents, but, as we will discuss in this post good functional documentation is an essential part of our mission and the craft, that can help or hinder the overall business success.

We welcome a guest blogger - Larry Lester - A Sales & Marketing Documentation Guru to discuss

There’s a host of reasons why small, emerging companies (aka start ups) should take documentation seriously. The problem is that most of those that I have worked with – don’t.

First and foremost they should take it seriously for all the reasons that larger companies take it seriously – it is a way of keeping your marketing, development, operations, and sales efforts – and the also the customer – in alignment.

However, for a start up the lack of good technical and marketing documentation – with the emphasis on good, or not having something basic at least – makes survival more perilous than usual. My phone usually starts ringing when these guys are about to crash land. If they have had the good fortune to make a sale, the customer is being nasty and delaying a milestone payment because a full set of technical documentation was supposed to be delivered and has not even been written. Or, if they have only got their foot in the door, discussions are about to collapse as the only marketing material they have to give to potential customers are a few pages of incomprehensible gibberish and a dreadful PowerPoint presentation! “We thought we could pull it off”.

The situation is, in fact, more serious than that. A company that does not maintain product requirement documentation is openly toying with suicide. There are two aspects to this assertion.

1. Poorly documented development is bound to result in a bug-ridden product. If you don’t write about it (requirements) then you don’t talk about it, and if you don’t talk about it, you brush aside the problems. Lack of a standard process and workflow causes product decisions to be made in an ad hoc way. At best, it is inefficient. At worst, it will kill your efforts to make a sale.
2. A good product requirement or a spec can serve as the basis for installation, operation and maintenance documentation. The saving in time, energy and money can be substantial. Somewhere down the road, you will need a technical writer, whether you like it or not. The more solid information you have to provide, the easier your lives will be.

The bottom line: give both technical and marketing documentation the same priority you give to development and sales. All of these processes are fully entwined - together the product should succeed; without any one of them it will be a struggle and potentially a product failure.