When a shortcut, isn’t

16 Dec

Continuing from last week’s theme of trying to ensure that product launches are successful from the beginning, this week’s theme is about taking shortcuts in your products — and when those shortcuts backfire.

This is an experience I have lived through over and over again as a product manager. Imagine the scenario: a key launch date or customer milestone is approaching with the deliverables incomplete, and the team needs to make the choice between communicating a slip (or missing the milestone), or deciding whatever is available is ‘good enough’ and getting it out the door.

Many times, in my experience, taking such a shortcut backfires and causes more work and damaged relationships in the long run than sticking to the original plan.

For example, if a customer is hungry for a software release and they are sent a build which “should” be okay but isn’t completely validated. When the customer inevitably stumbles across a bug which should have been found, everyone is unhappy and has to go into scramble mode.

In another example, skimming through checklists and other control points during factory setup of a new product can be tempting, especially if many similar products have been released previously. Fixing a factory issue during mass production could be downright catastrophic.

That is not to say it is always easy to decide when a ‘shortcut’ is okay and when it is not okay – nor is there always a ‘right’ decision. 

 Helping the team to decide when a shortcut poses an acceptable risk (vs whatever demand is pushing for the shortcut) is part of the “Art” of Product Management. Here are some of the questions I ask when faced with such a decision:

  • What will go wrong if this shortcut backfires? (upset customers, re-doing steps)
  • What will go wrong if we postpone  the deliverable so we have enough time to ‘do it right’? (missed revenue, customer relationship)
  • What is there to gain by insisting that no shortcuts are taken? (better customer relationships, if nothing – maybe a process can be streamlined)

Have you taken a shortcut in your products which has been wildly successful? Or do you find that shortcuts are a shortcircuit to ensuring you need a do-over?


2 Responses to “When a shortcut, isn’t”

  1. TimThePM December 16, 2010 at 9:37 am #

    The only “upside” we’ve ever experienced from taking a shortcut is the extra month or two’s revenue. However, this is always overshadowed by the negative personal impact it has on the developers and the support staff in our company. Shortcuts just aren’t worth it.

  2. Geoffrey Anderson January 28, 2011 at 8:43 am #

    Like you, I used to do Hardware (measurement and test equipment). The volumes weren’t enormous, hundreds of units a month, but the products were complex, and had many potential failure modes.

    EVERY time we took a shortcut, it fared badly. Once it was selecting a consumer grade, off the shelf webcam (to save a week or two of selecting and testing a suitable industrial grade solution). Saved less than a man month between the selection and the integration/SW development. Mayby $50 a unit in costs (on an ASP $150K product). However, the second batch of camera’s we got were different, used a different mount geometry, and had a “newer” USB chip, and naturally, our SW broke.

    Ended up retrofitting 500 units in the field. Add the $50 per unit, with the ~ $1200.00 in real costs for the service call, and this greatly impacted our break-even point.

    Ever since, I have been a skeptic when engineering comes to me with a “quick and easy” design change.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: