At Company S, The developers were incredibly capable of designing and implementing fabulous product. The company was started by all engineering/development people, and we didn’t know how to attract any other kind of marketing, or senior management capability to the organization. So, we had a great product family, designed and essentially marketed by engineering people.
Because we didn’t have real marketing people, we updated the product to became more and more interesting to us, the developers, and less interesting to potential buyers.
At Company S, the initial architecture of the organization created a product architecture we could maintain, but the organization wasn’t extensible. The product was extensible, but the product line was not extensible.
At a recent client, a small cohesive team developed a first generation product. They hired a bunch more people, many of whom didn’t think they needed to make decisions and stick to them.
Every decision was revisited. Their product was so bloated and so feature-full that only about 20% of their original-product customers moved to the new product. They had an extremely difficult time attracting new customers, because any one thing could be done in at least 6 ways, and they way you did it had side effects.
At this client, the organization created a product that looked just like them. Lots of capability, no vision, no organizing force, no ability to make decisions and stick with them.
In both of these cases, we sometimes got new people who were convinced they could make the necessary changes (cucumbers), but because they had to do it inside the pickle barrel, became pickles. This from The Secrets of Consulting.
The people at such clients are well-meaning, but they are stuck, and not able to see the differences between causes and effects. They don’t see the delays in their systems, they see these causes and effects as new information, even if it fits a previous pattern.
For example, there was a common problem: “old” customer buys new product. Customer calls Tech Support, and spends hours and days for a few weeks trying to get the product to do something useful the old product did easily. After a while, customer gives up, and goes back to old product. Customer tries to get money back from sales person, or apply it to future maintenance on old product.
When I saw this, and explained it to development management, I was told I was wrong. Customers weren’t giving up on the product, they were waiting for training, or so I was told.
I tracked the number of support calls over time, and the number of necessary staff, and saw that the number of support calls were going down. I looked at the training classes, and they were running fewer of them, with fewer people in each class.
I suggested maintenance revenue might go down, because people weren’t using the product. I was told I was wrong. I stopped working for them shortly after this, because it was clear to me I was in danger of not being paid if they didn’t realize their leading indicators of falling revenue. That’s why they’re being acquired again.