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."
Since I've been spending a lot of time talking with people about Agile, I've felt the need to concoct new, vivid metaphors to explain Agile. Of course, you can often best explain something by contrasting it with what it's not, and in this case, it got me thinking about the frustrations of non-Agile development:
In my last post as a product manager, sales training did not top my list of favorite things to do. The problem wasn't the sales team, which was composed of bright, motivated people, with a genuine interest in what was coming next from the development team. Instead, the problem was with the format of sales training.
Who looks forward to three days of non-stop PowerPoint? Not me, and certainly not the audience. We had to come up with a better approach, particularly as the company expanded into new technology areas, such as records management and scanning. Therefore, we experimented with a few new ideas. Some worked, others didn't.
One of the moderately successful experiments started with the assertion, "Scanning isn't as complicated as people think it is. I bet that I could put a bag on my head, pretend to be the most stupid end user imaginable, and I could still understand scanning. Someone just needs to explain the basics in the most practical terms imaginable."
I suspect that there are two reactions to this video:
"Oooooh, cool! Now I want a Prime Computer!"
"Who the heck is that guy?"
Count yourself on one side or another of this dividing line of humanity. I bet some enterprising company could take this commercial, digitally alter it to include a different product, and still reach people in Category #1. (At least, consumers in Great Britain, and the attendees at the San Diego Comic Con.)
One of my dream projects is to compare product management in the technology industry to similar jobs in other parts of the economy. For example, there are people with the job title "product manager" in the biomedical industry. How different is their work from a product manager at IBM or SAP? (I know a little about our cousins in other industries, but that's not the same as doing the research.)
We also have the product manager-ish position of business analyst in IT departments. How similar are they to product managers?
Fortunately for me, we have analysts at Forrester who study this breed of cat. Mary Gerush just published a document, "Find And Grow Great Business Analyts," that includes the current status of the job responsibilities and requirements for business analysts. The similarities are more striking than differences, which leads one to naturally wonder how much product managers can learn from business analysts, and vice-versa.