Chapter 5. DEFINING THE PRODUCT

At its core, a product definition is not a knowledge or resource issue; it is a relationship issue. When you and your development team build strong relationships with marketing staff and with your customers, defining the product becomes much simpler. Open and regular communication with members of other teams can help you align your development goals with company goals. In addition, developing trust among corporate divisions as well as between the company and its customers can result in a quicker consensus on the most appropriate product definition.

Some of the most difficult relationship strains occur between marketing and development teams. Establishing a positive relationship between these teams can be challenging, because the roles played by marketing and engineering staff are very different. Marketing's function is to understand customer needs and promise the solutions required to meet those needs.

Engineering's role emphasizes the practical aspects of building products efficiently and then supporting them after they are built. With a strong relationship between the two teams, they can work together to devise the best and most balanced solutions to meet the customer's and company's needs.

This chapter covers the basics of defining a product. You'll learn about crucial relationships, study example processes for creating product definitions, read about what goes into a product definition, and learn a bit about prototyping and how to use templates to help define a product. In addition, you'll learn how products are put together and how different partners in the relationship perceive the product.

Creating a refined product definition can be a challenge for companies for several reasons: The number of options surpasses the company's ability to build them, information is lacking, and the relationships between marketing and engineering are weak. However, if the marketing and engineering teams' relationship can be improved, they can work together to define the product through a process of high-level reviews and quick cost assessments.

Creating a joint and cooperative definition doesn't necessarily imply that engineering and marketing have completely overlapping responsibilities and authorities in product definition. Some companies give engineering the final word, while others give marketing the lead role. When the marketing team is strong, the marketing-driven approach usually works the best. In either situation, cooperative behavior produces the best results.

During the initial product definition process, short daily discussions between marketing and engineering encourage more rapid closure on choosing the best options to pursue. The daily discussion becomes a continuous conversation that allows iterative refinement of the requirements and ultimately the definition. The teams can analyze the feature costs, timeline, and definition in stages—be they quick overviews, intermediate level reviews, or fuller definition reviews. At each stage, the teams work together to select and eliminate options through thoughtful analysis and data collection.

Ideally, the marketing/engineering evaluation works as follows: First, engineering works with marketing to define preliminary quick estimates of product size and scope. Next, both teams agree on how to pare down the list. Remaining items are analyzed with more detail. Then this process is repeated until both teams agree on a final set of product definitions, costs, and timelines. Figure 5-1 illustrates this filtering process.


If a trusting relationship does not exist between the marketing and engineering teams, the steps in the process will degrade. For example, if marketing treats preliminary quick estimates from engineering as full commitments and pressures engineering to meet those commitments, engineers will probably stop providing quick estimates. Engineers create quick estimates based on limited information; these estimates are unsuitable for accurate budgeting and scheduling, but fine for establishing ballpark costs so that the initial direction can be set. Providing quick estimates as cost ranges emphasizes the uncertainty involved, but the analysis is insufficient to use in creating an accurate project schedule.

Once mistrust has soured the engineering and marketing relationship, the very expensive process shown in Figure 5-2 ensues. In this case, both teams treat conversations as mini-contracts, eliminating speculative discussions. All feature and project ideas require extensive evaluation before engineering will provide any type of estimate, and engineering devotes considerable time to precise, in-depth estimates. Marketing has to invest substantially more time in fully defining every idea before presenting them to engineering. Worst of all, engineering must create detailed estimates for all of the options before presenting them to marketing.


Why do so many companies choose such a wasteful approach to product definition? Past bad behavior usually drives defensive relationships. If in the past, engineering produced quick estimates based on initial ideas, and then marketing insisted that these numbers be treated as final, engineering has little incentive to provide quick estimates in the future.

When operating under a successful approach, however, engineering and marketing can collect more information and refine definitions for the ideas that will be implemented. Figure 5-3 illustrates the pyramid of information associated with refining a definition. Each layer reflects more product information.

A refined definition starts at the top level and focuses on the customer's needs. As the definition process continues, marketing and engineering produce a more detailed description of the product: detailed requirements, high-level implementation descriptions, detailed concept models and prototypes, and then the functional specifications. Then engineering considers the product architecture, examines the requirements of the product's construction, and prepares a detailed description of its features and user interface. Finally, engineering and marketing together flesh out the complete definition of the product offering.


The process is challenging because the teams must make product decisions based on incomplete information. Decisions involve trade-offs between features, timelines, resources, and implementation approaches. Making sound initial decisions requires not waiting until development is building the product before thoroughly analyzing what needs to be built. If questions about the technical feasibility of specific functions of features arise, a senior engineer should be asked to create simple prototypes for these technical areas before building the software. Prototypes are discussed in detail later on.