Guest contributor David Howard: Agile development isn't product management

(Editor's note: this is the first post from Vator.tv contributor David Howard, a former product marketer at Cisco Systems and Alcatel who is now a San Francisco-based marketing consultant to tech companies. We met him at the kick-off mixer for the UC Berkeley Haas School of Business student business plan competition, which Vator is co-sponsoring.

In this story, Howard sheds some light on the growing trend toward Agile software development, which emphasizes speed rather than documentation, and why it's important for companies not to confuse the process with product management.

His next post will be about why you should never choose a company or product name that scores less than eight points on a Scrabble board.)

Agile software development promises many benefits, and organizations must continue to innovate not only in product but in process and apply those innovations that deliver. I’m all for better code delivered faster, on time and with fewer bugs.

But many people seem to mistakenly believe that this new software development methodology is a product management methodology. Such a misunderstanding of what Agile development can and cannot do can lead to breakdowns in product management discipline and generate incomplete products or even product failures.

If you believe like I do that product management is really a business management function and not exclusively a software development or engineering function, then Agile development should be viewed as only one component of the organization’s product management model.

What makes product management a business function? And why is Agile development not the same as managing product development? From my product management toolbox assembled over the years, I can identify several product management tasks that originate from outside of the software development group and are therefore out of the scope of an Agile software development model: 

<!--[if !supportLists]-->·          <!--[endif]-->Requirements development and business case.

<!--[if !supportLists]-->·          <!--[endif]-->Field and beta test programs.

<!--[if !supportLists]-->·          <!--[endif]-->Pricing plan, gross margin analysis.

<!--[if !supportLists]-->·          <!--[endif]-->Sales order entry and product initialization.

<!--[if !supportLists]-->·          <!--[endif]-->Product technical documents and user manuals.

 We could go on to review many other product management deliverables outside the scope of Agile development, such as positioning statements, marketing collateral, training plans, regulatory or export certifications, or the need to have a firm, committed, stake-in-the-ground list of features to support advanced launch planning, but it should be clear that Agile development occupies only part of the product manager’s mind. Let’s shift now from the perspective of the product manager to the perspective of the product itself. Ted Levitt’s concept of “whole product” marketing, popularized by Geoff Moore and Bill Davidow. If you adhere to the “whole product” philosophy of technology product management, you may view the final output of the Agile development process to be the core or generic product, around which the product manager must wrap the expected, augmented and potential product.

The whole product beyond the core product may consist of customer service and warranty provisions, for example, or system integration, support, partnerships and interoperability, company and product brand equity, training and so on. Most are fruits not of the software development model but business management efforts by the product manager.

Joe Bentzel, in his recent book Asymmetric Marketing, rejects the classic whole product model and chasm theory but still advises marketers to wrap their core technology in “compound sets of services and intangibles.” – services and intangibles that come from outside of the software development process. If Agile development is to continue to flourish, it’s important that firms adopt it when and where it fits, and ask no more of it than it can deliver.