Posted by Tom Grant on November 26, 2008
Over the last couple of weeks, I've been involved in several conversations with a common theme: What's a product?
While that might seem like a profoundly dumb question, it's not. The definition of "product" can be pretty elusive, and not just in the technology industry. Do you define a product as a clearly identifiable thingamabob that vendors sell, such as cars and ERP systems? Or are customers the real measure of products, based on the business problems that the product is supposed to solve?
While I'm sympathetic with the intent behind the customer-based definition, I think it's better to choose the vendor-based one. Customers have business problems that require solutions, which include one or more products. (Usually more than one, in the tech biz.) Vendors may be very good at providing one of the solution components, but they often run into trouble trying to do everything, even for clearly identifiable business imperatives like "keep us from getting sued for non-compliance."
Once you know what you're dealing with, the next step is to figure out when you're dealing with it. That's as true of products as it is of dark matter:
- If different groups in the company can't explain what it is, or what it does, or for whom, then it's probably not a product.
- If you have to go to extraordinary lengths to support it, it's probably not a product.
- If no one is responsible for the roadmap, it's not a product.
- If it's not possible to calculate the profit and loss for something, it's not a product.
- If you're having a hard time obsoleting something, it may be a product.
- If your partners complain that they don't have training and collateral for something, it may be a product.
- If you have to develop a supported configuration matrix for something, it may be a product.
And that's just the short list. If you know other ways to know products by their signs, feel free to add them to the Comments section.