Augmenting the Product Development Process

A common concern, and one that I share, is that a sensible product development process will become bogged down in useless detail or busy work. To prevent this, I've found it helpful to augment the development process described with a few key concepts and processes.

Successive Freezing

In the early stages of development I give the responsible team maximum flexibility in managing their work products. However, when the time comes for others to make committed decisions on these products, they must be frozen. As a result, the concept of successively freezing various deliverables becomes important. In this approach, various deliverables become frozen over the product lifecycle.

While product managers may examine a wide variety of markets for a proposed idea in the concept phase, they must usually narrow this down to a specific target market in the business plan. For this release, then, the target market is frozen. It may then be further stratified into niche markets, with the focus one niche as the target for the launch activities.

On the development side, you may choose to freeze the requirements, then the user interface, then the database schema, then the APIs that exist among subsystems, and finally the code itself. Note that freezing is not designed to prevent change. Instead, the term "frozen" describes a decision that can only change through a relatively formal change-control process, described next .

Change Management Protocols

Change protocols refer to the degree of formality associated with changing a given outcome. The most lenient change protocol is none. An example of this is when a developer is free to check out source code, make changes to it, and check it back in to the source management system. A formal change management protocol exists when a proposed change must be approved by a committee.

I've found that many developers become uncomfortable with change management protocols. This is because they often misunderstand their fundamental purpose. The goal is not to stifle creativity (as expressed in desired changes to the product) but to ensure that the right people are informed of the change before it is made so that they can properly prepare for it.

Suppose you want to change the layout of the user interface. Before it is frozen, you're free to change it as you see fit. Once frozen, changes need to be managed, if for no other reason than that you have to coordinate changes to the help system, the end user documentation, and the training materials. There might also be changes required in the automated unit tests created by QA and perhaps in updated reference materials for technical support. That's several different groups that must be notified of a potentially simple change.

More generally , the change management process must include those stakeholders affected by the change to make certain that they understand, approve, and can correctly process it. Candidates include technical publications , QA, product management, technical support, and release engineering. In product-centric organizations, change management meetings should be organized and chaired by product management. In other organizations, they should be organized and chaired by the project or program manager running the overall project.

Documentation Balance

One of the most important things that every manager must learn for herself, in her own way, is that there is simply no universal formula for creating the right set of documents needed for a given project. I've created very successful systems using agile methods and a minimum of documentation. I've also had projects fail for lack of key documentation. At times I've taken great care to build precise requirements reminiscent of a waterfall process, with the kind of success that makes you wonder why everyone doesn't simply adopt waterfall and be done with it. Finally, I've also produced carefully written and researched documents only to find them producing a system that no one needed or wanted.

Lest you think there is no hope and just randomly pick a process, here are two guidelines that have worked well for me. Early releases should be created using as agile a process as possible. While you and your team may have a lot of experience in the problem domain, you don't have experience with your new product, how your target market and competitors will respond to your offering, or whether or not the business model you've chosen is the best one. Agile processes are often the best way to maximize market feedback. Over time, as the product solidifies and the market matures, you're going to spend more time responding to the needs of the market, including the need for reliability and predictability in deliverables. Thus, development organizations with mature products often find a transition from agile to more formal methods to be appropriate. This transition may sound easy, but it isn't, and many organizations face severe, and sometimes fatal, challenges in making it.

It is vitally important to understand how your team wishes to develop their product. Surprisingly, I've worked with teams that completely reject agile methods because they consider them the domain of "hacks" who don't know how to specify and build reliable software systems. These teams demand MRDs and related documents; they have a process and they follow it. As you can guess, I adjust my own preference for agile processes to meet their needs. Forcing a given team to adopt an approach that they don't believe in, either in their development process or in the language they're using to create the system, is a certain recipe for failure.

Recycle Bin

At several points during the project the team may find that they've bitten off more than they can chew. Rather than throw out potentially useful ideas, I recommend creating a recycle bin where they can be stored for future use. A given idea may resurface in a later release or in a future iteration. In a sense, the recycle bin also functions as a pressure valve, reducing (at times) the pressure felt by the development team to get every requested feature into the release.