Management Insecurity or Product Strategy?


In Greg's provocative comment, he says, “The idea that contributor initiatives are a drag on an organization speaks more to the insecurity of the management than to its skills.” I've been noodling that comment since I received it. I agree with Greg that some managers are insecure enough to insist that they make all the decisions about the work that the organization should do, who should do it, and when. But that's not where I was going with my general suggestions about not allowing skunkworks projects to continue. Here are two examples of skunkworks projects that hurt the organizations:

In the early '80s, I worked for a machine vision company. As an organization, we were bad at estimating, managing, and finishing projects. We started having a layoff every quarter. One of the people who'd been laid off kept coming back into work to finish his project. This project had one potential customer (it was a specialized application). The developer wrote the code so no one else could understand it. However, he needed changes to the set of libraries for his application to work. He worked for free, but the work to support his project consumed several people over the course of several weeks, starving other projects of necessary people. Our management wasn't talented, but they had decided on a strategy, and this project didn't fit. But this project stole cycles from other projects, preventing them from success. And the potential customer wasn't willing to pay for it.

A few years ago, a very large client reorganized their product offerings. One of their strategies was to stop supporting old products and migrate customers to a newer product that cost less to support and had more features. The manager could not bring himself to stop supporting the customers for the old products, and attempted to support both old and new products — an impossibility given the number of staff. Here, the first-line manager was the one keeping the skunkworks projects going.

Maybe neither of these is a typical skunkworks project. I've certainly worked on skunkworks projects where the technology was new and exciting, and our current management could not see how to exploit it. That's why I believe every technical person needs some slack time now and then, so they can be thinking of ways to exploit the technology they are working on. As much as I respect the talented marketing guys and senior management strategy (when it really is a strategy), there's nothing like letting a technical person play around with prototypes, a whiteboard, and a few good buddies to develop/exploit a new technology/product. That's what happened in the Graphing Calculator story.

But what I mostly see in skunkworks projects is not exploitation of a great idea or new technology. Most of the time, I see people wedded to projects that no longer fit the organization's strategy — old products that should be put to death. And the more people work on them — even for free — the more those old products cost the company. Greg, I agree with you that managers who feel the need to micromanage everything are insecure and don't belong in a healthy organization. But I don't agree with the notion (not that you said it) that all technical-contributor-led projects need to continue. Sometimes technical people are wrong-headed about their product ideas too.

I wish I knew of a recipe to develop a reliable product strategy. I don't think you can create a real product strategy without input from the technical people (in the form of prototypes, or even partially finished products), nor can you create it without understanding what your known buyers want (product marketing input). The technical people may well create something that breaks you out of your current market — or breaks open your current market to something much bigger. But that comes with hard work on all sides: management for taking the time to think about a strategy and eliminating the dead products; marketing for looking for the needs that exist and the needs no one knows about yet; and the technical people who know how to exploit the technology looking for something new and different. Ignore one of these, and you've eliminated at least 1/3 of the potentially great ideas.

A little slack time for technical people goes a long way towards developing a product strategy — and reducing management insecurity.

7 Replies to “Management Insecurity or Product Strategy?”

  1. A good source for creating a product strategy is Peter Drucker. I can’t find the specific references at the moment, but I know he talks at length about how to kill old products (and projects) so as to focus the organization’s energies on priorities.

  2. As a product manager (or a software engineer, playing that role, because no one else was filling it) I spent a lot of time, weaving together the overall business strategy of the organization, and the tactical needs of the business units relying on my products to formulate a clear product vision or strategy that addresses both points.
    My product started as “skunkworks”, not sponsored by the business strategy, but required by a tactical need to migrate off of a dismissed hardware platform (VAX/VMS). Because I took the role of product manager, and looked for ways to tie my product to the business strategy, business management started to look differently at the product, projecting it into the future plans.
    Another group with a similar product, had a more underground/underdog vibe within the team, and the product totally focused on meeting tactical needs of the business, almost thumbing its nose a management and strategy.
    It’s not always about sponsorship, but it eventually becomes so. Management needs to see how your product fits into their strategy, else it stays “skunkworks”.

  3. I’ve seen a few of both types of projects: successful bottom-up skunkworks projects and effort poured down a hole servicing project that should have been hung by the neck until completely dead. What’s made the difference is whether the technical side of the house understands the business side and the bigger picture of why certain decisions (such as killing projects) are made. When it’s the practice of the business side to throw decisions over the wall to the technical side without explanation, all manner of mischief can ensue.

  4. I can’t disagree with what you say. Engineers are usually not the best people to decide on marketing strategy, product strategy, or corporate positioning. We are necessarily focused on minutiae and can easily overlook the big picture.

    I readily admit that my goals were not the same as Apple’s. My primary motivation was to serve students and teachers. Pacific Tech’s mission statement represents my values at the time. Maximizing Apple shareholder value was nowhere in my thinking.

    That Apple dedicated so many resources, both in officially sanctioned quality assurance, usability studies, internationalization and localization work, as well as untold unofficial hours spent by enthusiastic well-wishing employees
    towards educational mathematics software – a computer algebra and graphing system for high school students – this I consider a coup of the first order.

    Educational software in general, and mathematical educational software in particular rarely generates much excitement. Upon looking into VC funding for Pacific Tech long ago, I found that the ROI is quite small under the most optimistic projections while the barriers to entry are large. This is not a market that anyone doing due diligence would look upon and decide to invest a great deal of company resources.

    It took a unique set of circumstances for Apple to do so. That could never have happened through any process Apple had in place.

    A common response I received from marketing folks back then was: “I failed calculus in college.” We were very lucky that the folks in charge of PowerPC marketing and engineering at the time all “got it.” Many people dislike anything to do with math as a knee-jerk reaction.

    That it ended as well as it did was miraculous. It felt like walking a knife’s edge. Any number of things could have occurred at any point to derail it. Ending the story with “And then we were escorted out of the building. Nothing shipped, but it *would* have been really cool” leaves a very different reaction.

  5. Responses like this one make it all worthwhile:

    I was struggling through algebra I not long after this program came out (1995). I just wasn’t “getting it”. I know the phrase is cliched now, but this program was just so *intuitive* that after a few days of fiddling I understood almost all the math I’d ever take right up to 1st semester calculus on a conceptual level.

    For me, at least, seeing things in motion (that nifty little value slider) made the concepts just click. Once they were there, the actual mathematical manipulation was much easier, because I was able to visualize “they way this should work out”. My teachers were trying to show it on a static chalkboard, and it just wasn’t getting through.

    I just got my BS in Physics, and without Graphing Calculator, I doubt I’d be where I am today. To the author, if he reads this:

    Thank You.

    Hoping for that is what motivated us at the time, and what is most gratifying now.

    I present this here as a fundamental contradiction. In a well-run organization, what we did would not have been possible. Yet given our motivation and our results, I’m confident saying we accomplished something worthwhile.

  6. You might want to take a look at the process used by the folks at Ideo. I have read about them and even watched a video on how they redesigned the supermarket shopping cart. The key to product design strategy is not technical people or marketing people but folks who can visualize how it will be used. I remember that the first thing the Ideo team did was to rush to the supermarket, take a look at the carts, and then talk to a whole bunch of shoppers on what was wrong with the carts. The suggestions from shoppers were incredible and once they got incorporated in the concept, the design was relatively easy.

  7. A lot of what you’ve said in this post is being pointed out by interaction designers and usability specialists. To put the usability of the product either in the hands of a developer or a marketing person will not help because in most cases a product’s usability is not their prime concern.
    Also, a lot of usability and interction design, especially on the web, is confused with how a certain web page looks. I hear a lot of people talk about “look and feel” when they’re discussing whether a software is easy to use. While looks are important (and Donald Norman has written a book on Emotional Design), the other stuff is important as well.
    What companies, especially in software, are finding out is that if their products are not usable, people are not going to be as tolerant as they were before.
    It’s all about making the user’s experience a positive one and the changes are taking place.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.