Reconcile MKTG and ENG... what we want vs. what we can do

Product planning example

Recently, we’ve been working with a client to solve the classic problem between marketing and engineering functions; reconciling customer/market needs (i.e. requirements) with the budget and resource constraints of an already stretched engineering organization.

How do you reconcile what is wanted by marketing/customers with what can be done by engineering with their available resources within the expected delivery time frame?

Most organizations have formal product planning processes that identify customer requirements, translate them to product requirements, which then get translated into product specifications which are implemented in a new product design by an engineering team. This is usually a formal process that generates volumes of documents called PRDs and MRDs, and so on...

But why, at the end of the day does this time consuming process result in the "wrong" products delivered late?

We think this is because a critical step is missing, called reconciliation.The ball gets dropped between marketing and engineering functions. Reconciling product requirements with the operational capabilities of an engineering group typically falls between the cross-functional hand-offs in that place people call the "white space." Marketing delivers the Product Requirements Document, Engineering then decides what they can or want to do and then does it.

Rarely do they engage in an analysis of what can be done based on the resource and budget constraints of the engineering function. Most people want to avoid this conflict; being forced to deal with the discrepancies and being forced to make the trade-offs needed to make the product successful before-the-fact. This 'head in the sand" behavior is more common than you'd think. Since accountability for product success is dispersed across functions, it is hard to change the status-quo.

The question is what requirements provide the greatest benefit (to the customer)?and which requirements can we deliver given our resource, time, and budget limitations?We've found many times that it is an 80-20 answer, in that 20% of the requirements fulfill 80% of the benefits. Which are they and what resources are needed to get them done by a given target market entry date? The process we designed and implemented solves this problem though decision modeling and project planning processes.

The process flow above (5-steps) illustrates the application of this idea. Decision-modeling is used in step 2 and 3 to define, in this case the stakeholders (customers), their relative importance, and a set of alternatives (requirements/needs/wants). The requirements are modeled using constraints to determine the prioritized list based on limitations of people, R&D budget, dependencies, and technical risks. The cross-functional core team uses the FTTM planning process to map out the schedule and resources (over time) needed to achieve the product objectives by the expected market entry target date.

Marketing and engineering functions are forced to reconcile what is committed tobe developed, withwho is available to do it, by a given point in time.This occurs at two stages, first using constraints to model which requirements can be done (based on resources and costs needed to development them) and second when the program is scheduled over time where the gap between the expected target delivery date is compared with the real schedule end date based on what it takes to get the work done. These two steps are critical iterations that cause marketing and engineering teams to reconcile what is actually going to get developed. The other important factor in bridging the cross-functional divide is through the use of a heavy-weight team structure.

The key in program success is always setting the correct performance expectations from day-one within the management hierarchy and with customers and markets.