Avoiding a Ticking B-O-M

Richard Mironov -

In our enthusiasm to get started on software projects, we often jump right into the coding and UI design that make software fun. I’ve done it. A few weeks before final shipment, though, someone identifies a missing item or service that costs the team some sleepless nights — or a month’s schedule slip. Perhaps it sounds like this…

“We’re going to beta on Tuesday and just realized that we need a license agreement for the software installer. Does anyone know who our lawyers are?”

This Byte talks about how a “Whole Product Bill of Materials” can save both you and your customers a lot of grief.

The hardware world has always known about Bills of Materials, also called B-O-Ms (pronounced “bombs”). GM and Honda have armies of BOM specialists who can recite the parts inventory for a transmission plus every supplier’s production lead time.

Among free-spirited software start-ups, there’s usually a good list of the key software modules that have to be written. (Larry works on the installer, Sarah has database access, Vijay owns the user interface…) However, many of the essential parts of a software product are not software. Seemingly little things like toll-free support numbers and upgrade paths are often neglected, but are critical to customer success. A complete Marketing Requirements Document (see MRD template) should have a Bill of Materials but usually doesn’t.

Best practices

I’ve had a lot of success holding a few brainstorming meetings very early in the product planning process, inviting clear thinkers from Support and Operations as well as Marketing and Engineering. Starting with a clean white board, we talk through the mechanics of exactly how a user will get and install our great new software product, then ask for help and handle upgrades. At every step, we list the things that must exist for the customer to succeed on the whole product bill of materials (BOM).

A cross-functional team is key to making this work, including some naive participants as well as very experienced folks. The entire group then walks through each step for the customer, trying to imagine what could go wrong. Here’s the very first step, and what we might discover:

“THE USER DOWNLOADS A TRIAL VERSION FROM OUR WEBSITE AND RUNS THE INSTALLER…”

  • Marketing: “Before getting to the download, the user should have to fill out a web form with some contact info.”
  • Support: “Trial versions should have 30 day licenses and time-outs, so that we don’t support trial users forever.”
  • Naive user: “If the installer doesn’t work, who do I call (since the help files were not unpacked by the installer)?”
  • Operations: “The FTP server might be down. We need a way to monitor the download server, especially if it is hosted somewhere else.”

SoundBytes

One way to disaster-proof your product cycle is with a whole product Bill of Materials effort to kickstart your thinking. In combination with a solid MRD, this template gives you a good start. Don’t let your customers teach you what’s missing from your product.