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.

Which way out? - The Importance of Exit Criteria

One of my fundamental criteria for starting a new product release is being able to define the Exit Criteria.

As a rule of thumb it is being able to answer the following five simple questions with accurate and complete answers (the questions are simple - the answers less so ...)

1. WHAT? - What are we building? What the key features and product values that the release will deliver?
2. WHY? - What are the key benefits that the customer will derive from the product when it is released? What are the values and advantages that the release will bring to the product family/company?
3. WHO? - Who needs the product? If this is a release for the market then define the customer - specific accounts or profile the type of user that the product is targeting. Also state who will help with the necessary integrations, GTM efforts and other internal stakeholders. If this is an internal development effort then who is the internal sponsor and who is tasked with supporting the integration and deployment.
4. WHERE? - Where should the product be delivered? Describe the internal or external deployment scenarios and any pre-requisites that will make the difference between a successful launch and failed one.
5. WHEN? - What is the timeline for this release? When must the product be in the marketplace or delivered internally? 

Once defined these criteria should be critically analysed to ensure that they are coherent and meet the SMART (Specific, Measurable, Achievable, Relevant & Time-bound) criteria. Will they meet the overall objectives? Will the product as defined meet customer expectations? Is the product definition correct? Can it be delivered in the time-available? Is the target customer the correct one to achieve the overall aims? Is the target environment feasible. Answering these questions will often force a rethink and changes, but should result in a clear definition of expectations. The entire team can adopt the final definition adding purpose and clarity. It is also critical in managing any changes that maybe needed during development


Overall the Five W's set out to define what does the product need to do, by when in order to make somebody very happy?

In my experience this is an iterative process, but, answering these five simple questions adds significant clarity to the product objectives and can make the difference between a successful product and a poor executed product that takes significantly more time and resources to develop and then fails to deliver most of what was expected.