Advertisement
On the Job
Welcome. Got a Monster account? Login here.
Avoid New Product Pitfalls
by Jennifer deJong
Monster Contributing Writer
Avoid New Product Pitfalls

Rate this article:
  • 1
  • 2
  • 3
  • 4
  • 5

  • Average rating:

    Total votes: 0

    As the critical link between the customer and engineering, product managers lead the development of new products, navigating the path to market success while avoiding expensive detours or potentially career-ending failures. Product manager Tony Goodhew's advice on how to avoid new product pitfalls: "It's always dangerous to trust a survey of one."

    While no one intentionally conducts market research that way, surveys of one are common, says Goodhew, a product manager in the developer division at Microsoft. Managers developing new products often seek to validate ideas they already have instead of digging deep to determine what customers really want. If you phrase your question the right way, it's easy to get potential customers to give you the go-ahead for your pet idea, he says.

    But what you are really doing is simply eliciting the answer you were looking for. It's dangerous to build a new product around information gathered that way. "In order for research to be valuable to a product manager, you have to understand what questions to ask, how to ask them and who to ask," Goodhew says.

    Example: Microsoft's C#

    When Goodhew first began work on what would become the new Microsoft programming language C#, a key product in the company's .NET application development framework, he was careful to avoid that pitfall.

    Programmers using established Microsoft products were likely customers for C#, but Microsoft's real target was developers using Sun Microsystems' Java programming language, which at the time was widely touted for its "write once, run anywhere" ability.

    When Goodhew began to gather information on the features C# should include, he focused his efforts on Java, not Microsoft, programmers. The obvious question to ask was: "Is the ability to write once, run anywhere important to you?"

    But ask the question that way and everyone will say yes. "It's human nature to say 'Yes, I want everything,'" Goodhew explains.

    Get an Accurate Picture

    To get a more accurate picture of what customers wanted, he listed 10 features the programming language might include and asked survey participants to assign a relative weight to each, allocating a total of 100 points among the 10 features.

    "Write once, run anywhere was at the bottom of the list," recalls Goodhew. "It turned out that the top thing they wanted was a better debugger."

    Goodhew enjoys relating this story, because it illustrates how easy it is for a product manager to build a product based on false assumptions. "You need to understand the implications of the questions you are asking," he says. "You don't need to be able to do statistical research. You don't need to know the mechanics."

    You also need a deep understanding of both the technology and the market. "Your job is to present the engineering guys with a document that says, 'to succeed in the marketplace, we need to build a product that does X, Y and Z,'" says Goodhew. But new products aren't based solely on the product manager's initial findings. That information is then qualified by statistically based research before the product is actually built.

    Tell Customers Why They Should Care

    Once the product is built and demonstrated to potential customers, a third, often overlooked step helps ensure success, says Goodhew: Tell customers why they should care about your product and what it will do for them.

    Goodhew recalls that when Microsoft unveiled the beta version of Visual Basic, potential customers, accustomed to working with character-based programming languages, were wowed by the product's "cool" graphical assembly capabilities. Even though Visual Basic was received enthusiastically, "you have to translate what ‘coolness' means," he explains. "Tell the customer, 'It will increase your productivity, reduce development time and save money.'"

    Since joining Microsoft in 1990, the Australian-born Goodhew, who left the company in 1995 to work for competitors until Microsoft lured him back in 1998, has launched a number of successful products, including the programming languages Visual C++ and Visual J#.NET as well as the Access database.

    How best to sum up what he's learned along the way? "Gather the right research, build the right product, and tell customers why they need it."

    Additional Articles in This Feature:







    Search Lexington Jobs | Lexington Job Posting
    © Copyright 2007 The Dispatch. All rights reserved.
    Privacy Policy | Member Agreement