It Isn t Like That

It Isn't Like That

Experienced readers may feel that this interpretation of the product development process has several flaws. Rather than allowing any of these flaws to prevent or distract you from reading further, let me try to address them now.

It Is a Waterfall Process and Those Don't Work

True, the process presented is reminiscent of a "waterfall", but there are several substantial differences. The most important is that the traditional waterfall described the development phase and related primarily to engineering, not product management. The stages associated with it (requirements, analysis, design, implementation, and test) rarely had sufficiently tough evaluation criteria applied to the work products to fix or address them if they were found lacking in some key measure.

Companies that have effective product development practices are most well known for the manner in which the results of each stage are subjected to strictly defined "go/kill" criteria. The overall process is referred to as "stage gate": After each stage, there is a gate, if you do not meet the gate's criteria, the project is killed . These are usually precisely defined financial criteria, which differ dramatically from the very loosely defined criteria for results of a waterfall process.

The careful examination and then termination of a project are what most strongly distinguish a stage gate process from a waterfall process. Software developers often mourn the termination of a project. Product managers who are using a stage gate process celebrate it, because it means that the overall process is working. The proof of this is that well-run product-focused companies may kill a project even during beta testing if it finds, despite prior market research and acceptable development costs, that the product does not meet the needs of the market! Examples abound in the retail sector, where countless thousands of new food products and packaging ideas are introduced into small, target markets and then killed before their launch into larger markets.

It Presents All Stages as If They Were of Equal Importance

This is not my intention . While all of the stages are important, the two most critical stages are concept proposal and product proposal/business plan. To a large extent, the results of these stages drive the rest of the process. It is product management's job to do the hard work associated with these stages to ensure lasting success, which ultimately means creating a sober, credible concept proposal and business plan that demonstrates that the proposed product can become a winning solution.

It Doesn't Detail Any Time

The amount of time associated with each stage is far too variable to make any estimates as to how long any one stage should take.

Where Is the Iteration?

When software developers think of iteration, they tend to think of iterative construction practices, like XP or SCRUM. When product managers think of iteration, they tend to think of a variety of techniques that enable them to sharply define the product before construction begins, such as primary and secondary market research, focus groups, and test marketing on prototypes . The differences and their effects are profound.

The single biggest differentiator of success in new product development is the amount of homework done before construction is initiated. A successful product will have a full and complete business plan, with clear and sharp definitions for the product, its core features, its target market, the planned-for business model, and so forth. Of course, any of these may change during construction based on new data, but before construction begins the product must be defined.

I am not advocating a return to waterfall construction practices, as my experience with them is that they don't work. Perhaps the following analogy will help me make my point. Imagine that you are an explorer and you've just crossed a mountain pass and entered a strange new land. You have at your disposal a variety of gear that can help you navigate mountains , valleys, deserts, rain forests, deep lakes, and fast-moving streams. You also have a small, single-person helicopter for reconnaissance. Do you just jump in and start exploring, or do you fire up the helicopter, take a look around, and plot your course?

Good explorers fire up the helicopter and plot their course. They know that to the North lies mountains, to the East is a lake, the West has a desert, the South, a rich and deep forest. Armed with this knowledge, they can plot a course: first South, then West, then East, and then, finally, North. Along the way they can prepare the gear they will need, handle issues associated with the terrain as they are navigating it, and build detailed knowledge through exploration.

The same goes for product managers. The foundational definition of a product could be 48 high-level use cases, organized in 6 groups. None of the use cases are defined in any detailed way, but their collective structure provides a coherent definition of the desired product. Before any single use case or group of use cases is constructed , the product development team (product management and engineering) detail them (generate more detailed requirements, create or update necessary design documents, and so forth) so that they can do a good job creating the system.

It Doesn't Prescribe a Development Process

That's correct: Personally, I prefer to use agile development processes. As a manager, I prefer to use the processes that my team believes will help them succeed. From the perspective of the product manager, overall product development process and decisions are usually more important than the idiosyncratic development process followed by the development team.

It Doesn't Identify the Level of Collaboration Between Groups within Stages

So what? Collaboration between product management and engineering/development is essential to creating winning solutions. There should be constant communication among these groups. Figure 2-1 shouldn't have to show this.

Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
ISBN: 201775948
Year: 2005
Pages: 202 © 2008-2017.
If you may any questions please contact us: