The post “A tale of Two Products: A product manager less product” appeared to resonate well. As a follow on, I have additional observations on how a typically engineering lead organization (hereafter ELO) suffers without a strong product guiding hand.
First, let’s define what I mean by ELO. An ELO is a relatively small company. They may have a single product, or multiple products. Their sales are very lumpy. They likely have a “core” technology that they re-purpose over and over. They do a lot of ETO (engineered to order) business.
They do have a sales team, but the sales people are likely to be engineers, or former engineers themselves. They love talking bits, bytes, and baud with customers or potential customers. ELOs like to believe that they provide solutions, but what they do provide is usually a few steps short.
How they fall short:
Engineering lead organizations never get to a complete product. They are often great at getting to 80% complete, but then they lose interest in the last 20%. Either they want to return to their core technology and do the next big extension of it, or they have another technology that they want to pursue.
And if they do that, what is left behind? What is that 20% that makes a product complete? It varies, but in my case it is some things that are crucial:
- Usable interface software. Engineers are willing to put up with some atrocious UI and UX. They don’t see why end users can’t just suck it up and use their EMACS macros to align the column and set the imaging resolution. Unfortunately, unless you want to sell only to equivalently skilled engineers (which, not surprisingly, is a vanishingly small market) you need to make the user experience something that maps to low, medium, and high skilled users.
- Documentation. This is one of the conundrums of the world. Engineers love detailed documentation. They will read chip documentation, compiler and CPU errata tables, and in general get very intimate with the hardware they are designing. However, they loathe the requirement to create usable end user documentation.
- Support. Engineering lead organizations typically skimp on technical support. Both in hiring people who can take calls, and give good telephone, to service personnel to repair broken product. Naturally, other attributes of an ELO is a belief that their natural customers will be self-reliant (a very libertarian point of view) and be able to figure it out. They might even put it forward as a challenge to “conquer” the product.
- Continued evolution of the product. ELO’s typically only do follow on changes when they are interested in the next step. They almost never do any survey of customers to learn what would improve the product. They consider a shipped product “complete” and move on to the next thing. Roadmap, strategy, planning are all foreign words. They obviously can’t plan 3 years out, they don’t know what they will want to do by then.
Revenues/sales are stagnant. They do really well until they get to a certain point, but they never grow beyond that. This frustrates a lot of the management, who can’t understand why the market isn’t clamoring for more of their products. This leads to the last symptom:
Sales Channel is more accurately termed “business development”. At an ELO, sales is constantly bringing you an opportunity for something that you don’t currently make, but that if you will build this, we will sell hundreds of them and all be fabulously wealthy. The reality is that you will do an endless string of one off’s, sales will be pocketing bonus and commission, and you will have a catalog of products that you never sell more than one or two of, and - worse yet - will struggle to support long after the sale.
Once you realize that you have a problem, you can begin the path to being market led. Hiring and properly supporting a product management function that is truly market centric is the start. It will not be easy. You will have to learn to say "no". You will have to learn to plan 3 years out, and to concentrate your development efforts to where a market can be tackled.