When Everyone Agrees with an Idea, Shoot it in the Head

SniperThe scenario usually unfolds like this: You’re in the break room, hallway, or meeting with a group of Executives and a developer, development lead, or VP of Development. It’s 2-weeks, a month, some period of time between feature lock and your ship date, and the VP of Engineering or programmer perks up and says something like:

“…Remember Feature X everyone wanted but we didn’t think we had time to implement? Well check THIS out!”

Then s/he dramatically spins their laptop around to show the World the result of their 48 hour Mountain Dew infused code fest – the Feature You’ve All Been Waiting For(tm)! The Executive lets out a belly laugh and hands out backslaps and guffaws, the VP of Development looks smug, and the developer has a nervous eye twitch and keeps stammering something about “that last build.”

You, the Product Manager, look at the feature and think:

“Well how bad can it be? It’s obviously been implemented, we’ll run it through some test cycles, pull the Marketing material we already wrote off the shelf and go with it.”

STOP! Pull the handbrake! You’ve just fallen prey to one of Product Management’s most lethal enemies: Optimism. I’ve fallen for this trick more times than I care to recall, because I am an optimist by nature. I want to believe that a feature is ready to go, I want to believe we can have it tested and ready in a month, and I want to believe that all the support functions like Marketing and Sales can react as quickly to a sudden change near the end of the project as my team can.

Welcome back to reality – it’s not, we can’t, and they won’t. You have to be a pessimist sometimes in Product Management, because no one else will do it for you. Sales certainly won’t – their chins touch the floor from leaning forward so far. Executives are a mixed bag: if it’s their idea, “Wow, it’s so easy!” If you’re bringing a new idea to them (especially Development), “hmmmmmm we’re going to have to look into that one.”

Recognizing this pitfall is easy. When everyone in the room is nodding their heads in agreement about an idea, that’s your cue to stand up and say “I think we’re making a horrible, horrible mistake that will lead to Johnny’s death.” Then point to the developer dramatically. It doesn’t really matter if his name isn’t Johnny, he’ll still get paranoid. Then remind everyone that “Development Done” is the end of the beginning of the product or feature, not the ready to launch indicator. You can make your own list to rattle off, but here is a start of other items you can remind the team you need to consider, in no particular order:

  • Positioning
  • Competitive Analysis
  • Requirements
  • Specifications
  • Collateral
  • Website
  • Tradeshow stuff
  • Tech Support implications
  • Operations and Inventory implications
  • Lead-time for parts sourcing (in the case of hardware)
  • Price sheets (if you’re going to charge for this feature)
  • Legacy product testing
  • QA
  • Many, many more…

So if you see everyone agreeing to an idea, stand up and shoot it in the head. If you don’t, that bullet will be traveling towards your head in a month or so.

Previous Post Next Post

2 Comments

  • Reply Bruce McCarthy May 24, 2007 at 7:04 pm

    I had a very good VP of Engineering once who made a habit of saying no to developer features – features that worked on the developer’s machine but hadn’t been planned for, tested under all circumstances, etc. – over the objections of product management.

    I’m a much wiser PM now than I was then and I’m glad he taught me what to watch out for.

  • Reply bob corrigan June 23, 2007 at 11:57 am

    Yes, we’ve all fallen victim to the classic blunders. Getting involved in land wars in Asia, going against Sicilians when death is on the line, and believing that a feature you can “see” is a feature that will work.

    Except sometimes “seeing” is Good Enough. Try this.

    Say “thank you” to your developer and tell your executives that you’ll be happy to take your “developer” version and start walking it around.

    “It’s good enough to show, but as it hasn’t been tested, it’s not good enough to use,” you explain. “Unless you want to hold the release to put it through the same QA and beta that the rest of the product has gone through, of course. Your call.”

    PM owns the process. The second you fail to champion the process, you lose, perhaps permanently.

  • Leave a Reply