Gates as Gatekeeper

How do new product development contributors (such as designers and developers) maximize their effectiveness with high profile management representatives at project review meetings? 

Gates

In new product development, major project review meetings may be called gates. This designation is used in methodologies such as Stage-Gate. Typically, new product development teams are required to make presentations to management representatives every one or two months during development. These meetings are required to continue the funding for development of the new product. At the end of the review meeting, the gatekeepers provide comments about the project and make one major executive decision:

• GO - Project funding will continue. Additional work is approved.  
• Conditional GO - Project funding will continue after amendments are approved. 
• STOP - Additional funding is not approved. Additional work is not approved.
• WAIT - Funding and/or work is suspended. Additional information or a change in external conditions is required before a Go/Stop decision is made.

Gate meetings may provide an opportunity for the team to request feedback and additional support. 

HiPPO

Often, there is one prominent executive that must be favorably impressed for the project to continue. From the development team's perspective, the perceived competence of this prominent executive can range from low to high. This executive may not be involved in daily project activity. This executive's assessment of the project can be termed HiPPO. This acronym is Highest Paid Person's Opinion.

How does a new product development team ensure that the project receives a favorable assessment? In the case where the team is doing outstanding work, the team should strive to address the preferences of the reviewers. 

Some reviewers demand impressive analytical data. Sometimes, aggressive financial projections are required. Some reviewers are more likely to provide a favorable assessment when they hear a requisite number of their favorite buzzwords. In 2008, popular buzzwords included green, innovative, and de-duplication.

If the team's performance is problematic, consider postponing the review. Attempt to resolve some of the issues before the review meeting.

Bill Gates' Reviews

At Microsoft on 30 June 1992, Gates functioned as a gatekeeper for a new version of Excel. At that time, Microsoft had approximately six layers of management. Gates transitioned from his day-to-day role at Microsoft at the end of June 2008.  

Joel Spolsky is a co-founder and the CEO of Fog Creek Software. In the July 2008 issue of INC magazine, he recounts his preparation for an Excel project review meeting in 1992. Spolsky states "We used to have these things called BillG reviews, at which Bill Gates personally went over every major new feature."

The day before the review, Spolsky sent Gates a few hundred pages of project specifications. In addition, Spolsky investigated details of previous versions of Excel and Microsoft BASIC.

As the review progressed, Gates' questions became harder and more detailed. He asked a question about compatibility between the code of Excel and BASIC. To the surprise of almost everyone in the room, Spolsky provided the correct, informed answer. He knew the details because of his research the previous day.

Spolsky reports "Bill Gates was amazingly technical, and he knew more about the details of his company's software than most of the people who worked on those details day in and day out." According to Spolsky, Gates "didn't meddle in software if he trusted the people who were working on it."

HiPPOs and what to know

Since Gates was confident about the team's progress, the development team resumed their planned development activities immediately. 

Since both Gates and Spolsky were programmers, the dialog was concise. The highest paid person's opinion was venerated. 

Often the development team is technology-centric. Often the HiPPO is sales-centric, marketing-centric, or business-centric. Here are a few suggestions:

• Designate someone to take notes. Comments may range from directives to ceremonial placeholders. If a question can not be answered during the review meeting, assure attendees that the issues are being recorded and will be addressed appropriately.
• Evaluate comments using the project's major objectives. In the case of the launch success objective, welcome diverse comments and make appropriate adjustments. 
• Some comments are not project-centric. An attendee may be scouting for resources for another project. Some activity may be gamesmanship. 

An abundance of opinions are expressed in new product development review meetings. Some opinions may begin with a phrase such as "I know" or "I am sure." Someone will paraphrase what they gleaned from a recent article or book. Expect to hear opinions that reflect popular topics. Often, it is easy to have a preferential bias to the opinions of the highest paid person. It may be difficult to differentiate an impromptu comment from a decisive comment.

Resolving Conflicts

Conflicts will arise. There are several keys to resolving new product development conflicts. Briefly summarized, these are:

• New product development is best approached as a complex adaptive system. NPD is non-deterministic. Results are not guaranteed. 
• Often, the application of survey data can be misleading because of context differences.
• Experimental results from your prototypes trump opinions, anecdotes, and metaphors. In addition to the core product, this includes the design of the user interface and sales/marketing items such as advertising strategy.  

Conditional GO and Conditional Acceptance

An unconditional 'GO' decision at the end of a review meeting is rare. In practice, a more likely outcome is a 'Conditional GO' decision from the review team. 

Your team should analyze proposed project adjustments within the known constraints. The additional assignments should prompt the team to re-evaluate project commitments. Until your team has evaluated the implications of the additional requests, the acceptance of the additional work must be conditional. Previous deadlines or resources allocations may be invalid.

If the new request requires that your team commit to more work, don't agree immediately.  Don't give the impression that the original estimates were inflated. Don't commit to working more nights and weekends. Don't risk a potential drop in quality without careful analysis and the input of your team. 

Before committing to new requests, it is OK to spend a few hours to evaluate the new request and study the implications.

Listen to Gates as Gatekeeper [10:24 minutes, 5.1 MBytes, (m4a)] Apple QuickTime / iTunes is required]