The Heretech

The limited lifespan of many component technologies

As anyone who has worked on component technologies can tell you, the time in which you should treat your product as something that can stand on its own is limited. The tricky part is figuring out when that transition should occur—and that's where people in product marketing and product management can really earn their paychecks.

"Just give me what I want, even if I don't know what I want"
Collaboration-ish, social media-esque technologies will reach that point. But is it here yet? One company in this business, Jive, seems to think so. Their Social Business Software (SBS) suite bundles discussions, social tagging, blogs, and other capabilities in what used to be a smorgasbord of capabilities. Pass down the line and fill your plate with whatever components you want to consume.

Of course, this model presupposes that you know what you want. Unlike Swedish meatballs and macaroni salad, you may not know your own taste for dashboards, polls, and document collaboration, which may be as mysterious to some users as the menu at an Eritrean restaurant's lunch buffet. And if you can't decode the menu for yourself, you certainly can't be trusted to pick out the right components for other people.

That's the cue for some companies to switch their product strategy and marketing approach from products to solutions. Instead of the befuddling list of 100 items, just package related components into the Meat Lover's Special, or in the case of Jive, "solution architectures" like Employee Engagement.

"Give it to me when I want it, even if I can't tell you when that will be"
Without giving a thumbs up or down on Jive's specific approach, they provide a good example of how important this timing issue can be. If Jive were to wait too long with a solutions strategy, the market might pass them by. Competitors with inferior products might do a better job of explaining how to use them, which will attract users and customers like iron filings to a magnet.

On the other hand, Jive might jump too early into the solutions business, with tragic results. When you start thinking less about generic technology, and more about specific use cases, you make product roadmap and feature design decisions much differently. For example, if you want to capture the medical records market, you can't just build a generic approach to roles and privileges. You have to design access control lists and other security components in a way that will serve how practitioners and patients share information with insurance companies.

Unfortunately, back when HIPAA first started getting momentum, some companies tried to steal a march on their competitors, but they marched swiftly in the wrong direction. As it turns out, there wasn't a single correct way to conform with HIPAA privacy guidelines; instead, organizations had the latitude to figure out the HIPAA puzzle in their own ways. Instead of bringing to market a one-size-fits-all "HIPAA solution," these vendors had built themselves a one-size-fits-none straitjacket. Oops.

"In other words, your job depends on reading my mind"
Product marketers and product managers, therefore, are a key resource in technology companies for seeing over this horizon. Is the technology well-enough understood, and widely-enough adopted, that the shift to a solutions strategy is imminent? If so, which among several different solutions is the one that will generate the most business?

These are questions with huge ramifications, beyond just next quarter's sales. For example, a small company that has done a great job building a best-in-class component technology may be ripe for acquisition. Or, it may be kidding itself about the possibility of finding a buyer, if bigger companies don't see the kinds of solutions into which these components will fit.

Clearly, a group of smart people sitting around a conference table aren't going to reach the ultimate answers. Research into a combination of technical and business issues will be necessary--which, again, is the raison d'etre of the PM team.

[By the way, this week's podcast, to be posted soon, features an interview with Mike Marfise of Jive. We don't talk about this particular issue, but Mike has a lot of interesting things to say about a particular solution area, innovation.]

The difference between enthusing and embracing

Games without frontiers
I've said before that other parts of the technology industry could learn a lot from the computer game segment. Hollywood-sized budgets and revenue, real deadlines for getting product sold through retail channels, short shelf-lives for products, very high quality standards--these characteristics of the game biz tend to focus the mind on what's important.

But they don't immunize you from mistakes. Case in point: the game Demigod, which you may have seen in your local Target (that's the retail reach of the computer game industry, after all). Demigod's publisher, Stardock, designed the game around the assumption that a big chunk of the customers will want to play online. They also made some technical assumptions about how that should work, which proved to be wrong.  "One bad design decision and one architectural limitation" nuked the servers supporting online play. Ouch.

Shock the monkey
When all the electronic dust settled, Stardock had time to review some important statistics about Demigod's customers. In their annual report, Stardock's CEO admits their collective surprise that only 23% of their customers ever tried to log into the online servers. Of that fraction, a smaller fraction played at least one game online.

Unfortunately, that meant Stardock's investment in the development, testing, marketing, and support for the multi-player "experience"--to some extent, at the expense of the single-player way of playing the game--was reaching only a tiny minority of their customers.

How could a company make such a bone-headed mistake? By listening to industry gurus.

No self-control
In 2008 and 2009, computer game industry people were, by and large, fascinated by the brave new world of online gaming. After all, who wouldn't want even a tiny slice of Blizzard's mega-million dollar success with World of Warcraft?

The excitement over multi-player, online gaming grew to such a pitch that various industry professionals and luminaries started talking as if single-player games were already a thing of the past. (Here's a mild example, and here's a more feverish one.)

In hindsight, it's pretty obvious why single-player games haven't died. Not everyone wants to play online. Not every type of game is particularly well-suited for online play. (Here's a good example.) And certainly, few games are designed exclusively for online play, in the way that World of Warcraft is.

Some companies tried to explore the opportunity without the same "burn your boats behind you" approach that Stardock took with Demigod. The fourth version of the hallowed Civilization series put a great deal of emphasis on online play...But it was also a damn fine game in single-player mode, too.

Shaking the tree
As it turns out, the Internet connection from your console system or PC does have other important ramifications for the game industry, without having to believe in the Borg business model (always connected with other people, all the time). Many game companies are trying to make money through "downloadable content" (DLC), which open up new game options if you pay a couple of bucks. This season's mega-game release, Dragon Age, is a good example of how vendors are trying to make additional money, on top of the initial game sale, through these micro-transactions.

What's the broader moral of this story? Not surprisingly, as I write this post, I'm thinking about the buzz concerning social media. Certainly, there's some market for a particular kind of social media, such as micro-blogging, or a certain way of using them, such as customer service.

That being said, you have to be very wary of leaping from that use case to unspecified new ones. They may exist...Or we may have reached the current maximum volume of reasonable use cases for that medium.

That conclusion doesn't diminish the power of social media, or its future potential, one iota. Only the truly doltish among us would argue that social media have changed nothing. In fact, the use cases that we haven't considered—in the way that people hypnotized by World of Warcraft weren't thinking of new ways to make money, such as DLC—may even have bigger, more lasting, and more profound effects that the first one we imagine.

[P.S. Thanks to the Flash of Steel blog for the pointer to Stardock's annual customer report.]

[P.P.S. In case you're puzzled by my subheads, they're all the titles of Peter Gabriel songs. If there ever was a recording artist fascinated by new media, Gabriel's the one you'd have to cite.]

Remember the KISS principle?

This morning, I had a briefing with McObject, a tech vendor that specializes in embeddable databases. From cars to set-top boxes to web sites, there's a near-universal need to put data somewhere, retrieve it, and manage it. In these use cases, the simplest database technology is the best.

Their product strategy is interesting to the readers of this blog for at least a couple of reasons. First, there's an unstated assumption in many technology companies that complexity is inescapable. If you want to keep pace with your competitors, you have to keep pace with their feature set.

Keeping the roadmap simple
Pshaw. If you look carefully at McObject's roadmap, you don't see crazy amounts of new features. Instead, their product strategy focuses on the essentials. Provide logical database devices as a layer of abstraction above the actual storage (on disk, in memory, etc.). Take advantage of the performance improvements in 64-bit architectures. Give the developer an optimistic concurrency option.

The acceptability parameters aren't too hard to figure out. Prevent database corruption. Don't screw up performance. Don't baffle your customer with new  options they can't figure out.

I'd like to think that every technology company understands these principles, but, alas, they don't. For example, I've seen product marketing materials for cloud-based data management that possess none of this clarity and simplicity. In a few extreme cases, I've been unable to decipher what the vendor was claiming they could do, even though I've been working with databases and file systems for a long, long time.

Keep it simple for your customers
Clarity in your communications starts with your own clarity about your customers. Steve Graves, the CEO of McObject, made an important observation about working with developers: they're really smart people, on average. However, they don't know everything, and they often don't understand databases.

That should be no surprise to anyone who has ever worked on a development team, which, like the Dirty Dozen, is often a collection of specialists (demolitions, build scripts, sniper, Ajax...). In no small number of cases, the team may have no one who's a seasoned hand at databases, or other important domains (performance, security, etc.). Therefore, vendors like McObject have to be ready to educate and advise, not just sling technology at them and hope for the best.

Sure, we've all had a good chuckle at that guy who rampaged across the stage like an enraged mountain gorilla, screaming "Developers! Developers! Developers!" Unfortunately, we've behaved equally ridiculously, assuming that all developers are the same, or they're always willing to tinker with technology until it works, or that the differences in job function in the same development team don't have any effect on buying and adoption behaviors. Are you marketing to rank-and-file developers, or development managers? That can be as significant a question as, are you marketing your CRM system to salespeople or sales managers?

The simpler your product, the easier it is to understand its value.  Doing a very good job in your niche, such as embeddable databases, is far preferable to throwing in every feature that might have value, or inventing strained explanations of why your technology is part of the latest trend.

[Cross-posted at The Forrester product management blog.]

Jeff Lash says, drop the shotgun!

Jeff Lash has a great post on why product managers should resist the urge to stuff as many features as possible into a single release. You might call this the blivet model of product development, but I prefer the shotgun metaphor: Load the shotgun with as many features as you can, fire it at the customer, and hope that you hit the target.

Workshop on "social product management" is done!

Had some great conversations with the workshop attendees on how PM teams are incorporating social media into their customer and market intelligence (including, but not limited to, requirements). Thanks to all who attended.

Interestingly, we spent a good deal of time talking about the type of questions people ask. In trying to make sense of both social media and PM deliverables, I made a distinction between problem-centric questions, which center on the customer, and product-centric questions, which (as the name implies) focus on the vendor's products and services.

In the technology industry, people are far more used to posing product-centric questions. Gradually, companies are learning the importance of the problem-related questions. However, it's easy to slip from one into the other. It reminds me of how I used to struggle with guitar fingering. As a novice player, I would concentrate for a while on keeping my fingers straight on the frets. Inevitably, as I started to think about other things (strumming, rhythm, etc.), I'd start to roll my fingers slightly to the side, which made it harder to hit the notes I was trying to reach.

Problem-centric questions are a lot like good fingering: it takes time, experience, and discipline to reach the point when you shake free of the bad habits. Obviously, there's a time and a place for product-centric questions, but not every time.

[Cross-posted at The Forrester product management blog.]

Exporting is not abandoning

One of the more knuckleheaded beliefs within many technology companies concerns import/export. Of course, every vendor wants to import data into their systems. But export...Not so much.

The assumption, of course, is that the only reason you export data is to abandon the system. However, it's easy to think of many use cases that depend on export. Here are a few examples:

• Migrating between a test system and a production system.
• Exporting data that will remain in System A in some form that System B can use. For example, you may continue working on content in a collaboration application, but you may need to export versions of it to a web content management system for publication.
• Exporting data as part of auditing or legal discovery, so that people outside your organization can have access to it.

And so on. We run into other kinds of export operations all the time, without blinking. Every requirements application, for example, has some mechanism for exporting content into PDF, Word, Excel, or other format familiar to particular audiences, such as stakeholders reviewing the list of features proposed for the next product release. Export-as-XML is a mechanism that serves many use cases, of which abandoning the system is just one.

Therefore, Google's announcement that it has prioritized development of export features for its application makes good sense. It may be a sign of confidence, and it may be a trust-building measure, as this InfoWorld article states. At the same time, it's also a necessity for the real-world requirements of many solutions.

Use case first, then applications

I really like following the evolving product offerings from companies like Zoho and Box.net. Since they're small, SaaS companies that are solely in the business of collaboration, customers reward them directly for making products that fit the way people work with unstructured data. Rather than just try to replicate the features of Microsoft Office, the way that OpenOffice did, the Zohos and Box.nets of this market start with basic use cases, and think about what's important to add.

Box.net's iPhone support is another case in point. Given the popularity of the iPhone, Box.net might have created a check box feature of limited usefulness, beyond marketing. Or they might have put some real effort in a feature, only to design something that doesn't reflect how people want to work with their files and folders through a smartphone. Beginning with the API is a good first step. Not only do you give your partner a way of adding value, but it gives you time to figure out exactly what the right use case is. It's there, somewhere, but you might rush into development, only to get the killer feature of your killer app wrong.

Market development: horizon or mirage?

The recession has sharpened the points of a dilemma that technology vendors were already facing: Do cleave closely to our existing customers, or try to expand outwards? Do we try to sell more into existing account in familiar markets, or do we look for new markets where people are struggling with business problems that look congruent with the ones we're solving for our existing customers?

With no obviously correct choices, vendors experiment, to the point where they see real opportunity, or decide that the exercise is going nowhere. But how do you know if you've invested enough into the experiment to get a reliable result?

Adobe runs a good business, but its stock still takes a dive
A good example of a technology company that could stick closely to its existing customers, or fan out to find new ones, is Adobe.  Having long ago identified its core market, creative departments and web site teams, Adobe might not have an obvious place to go. However, maybe it doesn't need to. As long as Photoshop remains the standard for image editing, Dreamweaver remains the web developer's tool of choice, Acrobat is the default cross-platform document format, and Flash retains a strong position against threats like Silverlight, Adobe will continue to get license renewals and accrue new customers.

Unfortunately for Adobe, Wall Street doesn't see the world through the same lenses. Even positive coverage from market observers failed to keep Adobe's stock from plunging from a high of approximately $45 per share last fall to under $20 per share in March. Since that nadir, the price has bounced back a bit, to around $30 a share today.

Here's how positive the coverage was, during this collapse of Adobe's stock price:

• Michael Goodman at TheStreet.com,  in "Adobe Has Its House In Order," praised Adobe's cost-cutting measures. Adobe was behaving like one of "the winners will be the companies that scale back operations in concert with what they're experiencing, not how they wish it to be.
• For months, The Motley Fool has pointed to Adobe as an outperforming technology stock.
• In May, SmartMoney.com featured Adobe as a top pick among technology stocks.

At this point, the management of a company in Adobe's position might conclude, "Holy moley! If we can't get our stock price up by making smart business decisions, and holding on to a reliable customer base, we have to find new customers!"

How big can the application development circle be?
Undoubtedly, new customers would be good, but where to find them? Adobe has at least one idea of how to expand its customer base: get more people who actually contribute to web applications to be users of the tools. Flash Catalyst is designed for the web designers who are not coders, but who build the application flow, user experience, and general UI conventions. After creating the basic application framework, a developer can add the necessary code to enforce business rules, handle weird edge cases, and other tasks.

That's great, but maybe it doesn't go far enough. Perhaps Adobe should be pushing to go further, involving not just the people who build prototype applications, but the business users who have to live with the results. Give that butcher, baker, or candlestick maker a cleverly-designed interface for specifying what kind of application to build, and the tool puts together the pieces. Voila! You've just expanded Adobe's licensed user base to include a whole lot of people who might have spontaneously combusted if they had come into direct contact with tools like Photoshop or Illustrator.

Or, perhaps, this user-generated application is a pipe dream. After all, vendors have tried before, but you wouldn't necessarily give Microsoft Access or even Intuit's QuickBase platform to any random business user. Maybe this kind of tool is possible, but the cost/benefit ratio of building one isn't really there for Adobe. Extending a development tool to include non-coders is already an impressive achievement, so it might be a bit unfair to Adobe to ask them to do more. On the other hand, it's just that kind of push to do more than originally planned that leads to some of the best inventions.

Whatever the ultimate answer may be, the first step into this direction, adding web designers to the mix of rich application developers, is not in and of itself a good measure of how far the idea might go. Who knows, web designers might be wholly unenthusiastic, but end users might be overjoyed to be included. Enthusiasm and adoption might not proceed along a straight line with an unvarying slope.

Herein lies the chief peril of market development. Invest too little, and you may miss important opportunities. Invest too much, and you may discover that you've been chasing a mirage.

[Cross-posted at The Forrester product management blog.]

Ebay loses track of its product

If this analysis of eBay's current revenue slide is accurate, the basic problem of the world's premiere electronic garage sale is that it's trying to be a mini-mall instead. Sort of.

Ms. Steiner, in an interview, attributes the fall-off in audience to eBay’s “identity crisis.” At the highest level, the site has switched from trying to promote itself as a place for a full range of merchandise to one that emphasizes used and off-season goods. There are other changes as well, she notes, that are not only confusing buyers but also alienating many of the site’s sellers. EBay is increasingly changing its rules to favor bigger sellers over mom-and-pop dealers and individuals clearing out their attics. For example, items from high-volume dealers appear higher in search results.

In other words, they've lost focus on what sort of product or service they provide. The various ways in which eBay has tried to shift its attention to the small retailer are manifold, such as the "Buy It Now" feature.

It seems inevitable, in hindsight, that other online storefronts would emerge, making eBay's bet on the small retailer a bit risky. (Particularly since the user experience for the shopper on a site like Amazon can be a little easier to use, and a lot less cheesy-looking, than eBay).

Ebay is an amazing web application, handling millions of transactions every hour. That's not a formula for an enormous amount of flexibility, however, in what the application can do.

Here's where the product management function is critical. Yes, says the product manager, we might make money in a lot of different markets. However, our current product is very good for a particular market, and if we can't morph it into something that's going to capture and keep a lot of new business, it may not be worth pouring money into an inherently risky venture. (Or, if it's a risk worth taking, having a plan B is still a good idea.)

It seems weird that, if we're in the middle of a recession, and people are trying to scrape two nickels together, the place where they might sell a few spare items is not doing well. However, economics depend on more than just supply and demand.

A PC is not an appliance, Bastille Day edition

Over the weekend, I tried out Netflix's Internet-delivered movie option. After installing Silverlight on my home PC, I fired up a movie.

Ten minutes into it, I had to stop. Every few seconds, the audio would skip ahead, meaning that you lost a word here, half a word there, which for me reached a fingernails-on-the-blackboard level of annoyance. I regularly watch shows on Hulu, which does not have this problem, so the Netflix experience suffered by comparison, too.

I'm telling you this anecdote not to rail against Netflix, or Microsoft Silverlight. I'm absolutely cool with the idea that there are kinks to be worked out. Maybe Silverlight has an issue with the 64-bit version of Vista, or there's some background process on my PC that's messing with the audio.

The real point I'm trying to make is this: Even as a tech-savvy person, I have no inclination whatsoever to diagnose and fix the problem. Multiply that lack of enthusiasm by at least a factor of ten for people who don't have the same level of experience and knowledge with PC issues, and could care less to learn about them.

I'm sure that either Netflix or Microsoft will fix the audio skipping problem. (A quick search revealed that I'm not the only one who's experienced it.) However, once again, a technology that should be as reliable and simple as turning on your television and flipping channels is anything but.

Of designers and developers

One of my hobbies is historical conflict simulations, better known by their shorter moniker, wargames. Playing a boardgame that re-creates the Revolutionary War, the political collapse of the Roman Republic,  or the battle of Gettysburg might not be your idea of a good time, but it's mine.

Wargames push my buttons as a history buff, and they often provide insights into historical events that other media cannot provide nearly as well. The challenges of wargame design echo the challenges people face designing other kinds of products. One of these lessons is the importance of having both designers and developers.

Developers make designers successful
It's tough to design a wargame. Anyone can throw together a game, using a board and a few bits, that might superficially resemble an historical event. Once you start playing, however, you'll immediately see that the game is about as realistic a depiction of history as Monopoly is a simulation of corporate management. On the other hand, to make the game more realistic, loading up the game with details to cover every facet of history will make a game that's superficially realistic, but unplayable.

Therefore, to simulate historical events through this medium, wargame designers must walk a fine line between credibility and simulation. Not surprisingly, they sometimes fail. A designer might devise a great new mechanism for simulating history, but draw a blank when it comes to making a playable, interesting game. Other designers might be very good at making playable games that, unfortunately, produce historically unrealistic results.

Enter the developer, the designer's partner in building a wargame. Where the designer might have a lot of good ideas, a developer knows how to make them work in practice. For example, a designer might have an interesting approach to depicting the importance of C3I (command, control, communications, and intelligence) in modern warfare. Unfortunately, the designer tried to simulate too much, creating an over-complicated set of game mechanics. At this point, the developer pares the C3I rules down to their essentials.

Development and design in the tech industry
The designer/developer partnership isn't limited to wargame design. In the technology industry, new ideas often have two inventors. Google has two founders, Sergey Brin and Larry Page, not one.  Another duo, Evan Williams and Biz Stone, founded Twitter. In big companies, you'll also find a pair of "founders" behind new technologies.

Obviously, these creative combos work because the two people have complementary skills. One person might keep spitting out new ideas with machine gun rapidity. The other partner needs to be the person who identifies the ideas with the best potential, puts them to the test, and ensures that they move from concept to concrete reality.

Other aspects of the designer/developer partnership apply to the technology industry. In both wargames and software, the temptation towards complexity is always strong. Togo back to the C3I, the wargame designer might create one set of rules to handle how a general orders his troops, and another to depict how they respond to them. The developer steps in here and says, "All you're really trying to do is figure out whether this brigade moved, and if so, how far. So why not just have one mechanic to show the effect of C3I, rather than two to show the activities that produce these results?"

Similarly, partners in software development check each other's tendencies towards needless complexity. Elegant code is easier to build and maintain. Not surprisingly, there's almost a cottage industry unto itself of books about programming elegance.

The business partnership starts from Day One
There's more to this kind of partnership than good programming hygiene, however. Some of the most successful companies in Silicon Valley had, during key periods of growth, strong business leadership to complement technology acumen. Oracle may have a reputation for bare-knuckles sales techniques, but that's just another way of saying, from its inception, the Oracle management team had a clear idea of which markets to target, and how to convince people in these markets to buy Oracle's technology.

Corporate strategy and product strategy start from the first day of coding. The team may not yet include someone with these skills, but the need for these skills exist. If the initial architecture won't support massive scalability, or a multi-tenant deployment, then good luck moving someday from an on-premise to on-demand model. You may not need to worry about these concerns, if the best opportunities don't exist in a SaaS world. The team will make this type of design decision, with enormous business consequences, even if they make the decision unintentionally, by neglecting these questions.

The Windows 7 licensing dilemma

Cue Karl Malden from the old American Express ads: You've built a new version of your operating system, after the last one was a flop. You have people excited that the technology will be better, but now you have to convince all those Windows XP users to upgrade to Windows 7. What will you do? What...will...you...do?

That's a definite head-scratcher. The moral of the Vista story was, "Microsoft can't strongarm IT departments into doing anything Microsoft may want." On the other hand, after the launch of Windows 7, Microsoft needs to get adoption of the new OS moving at a fast clip.

Clearly, this promises to be one of the most interesting tech industry stories this year.

The Heretech podcast, episode 8

You've heard of the ubiquitous Ed Yoozer, measure of all technology design, but have you actually heard him? We rectify that gap with this week's interview. (Be sure to stick around for Yoozer's views on social media.) Plus, a short review of a small book on product requirements. Copyright (c) 2009 Tom Grant

Reboot camp

[I'm going to steal a page from Christopher Cummings and use a popular culture metaphor to make a point about product strategy. To be totally Cummingsesque, it's based on superhero comics.]

Frequently, people who write serial stories--TV shows, series of novels, etc.--write themselves into a corner. The most notorious example is Dallas, which got into such a ridiculous snarl of plot twists that the producers decided, what the hell, most of what happened up to that point was all a dream. (Reboot.)

Can Superman defeat The Complicator?
Several years later, DC Comics, which owns the license to Superman, concluded that not even the Man of Steel's awesome powers could help him escape from the convolutions and complexities that piled up over decades of monthly publications. There was too much backstory for new readers to make sense  of what was happening in any particular issue.

Not only was there a man of steel, but also a dog of steel (Krypto), a teen of steel (Supergirl), a chimp of steel (Beppo), a Superman from a parallel universe...And we're just talking about the good guys. Cataloguing the bad guys was an even more Herculean labor (perhaps as difficult as bending steel in your bare hands.) There were even several different types of kryptonite, each of which screwed with Superman in a distinct way.

This "continuity" also made it increasingly difficult for the writers to do anything new or different.  Any story idea might be improbable or impossible, in a universe populated by a bazillion heroes and villains, plus an incalculable number of other complicated factors. ("Oh, right, if Superman did fight Eclipso, he'd lose, because Superman's vulnerable to magic. But why then wouldn't he just ask Dr. Fate to kick Eclipso's ass?")

Something had to give. DC's solution was to start over, wipe the slate clean, ignore everything that had occurred in the decades-long Superman storyline up to that point. The writers now had perfect freedom to do anything they want, as long as they stayed in the spirit of Superman. Lex Luthor was still a villain, but rather than being a crazed inventor, he became an amoral, power-mad industrialist.

Can Superman escape the Support Matrix?
What's the relevance to the technology industry? The common trait they share, particularly in software, is the growth of complexity to the point of unsustainability. It's not the inevitable outcome of ongoing development, but it can easily follow that path.

Every new version of a product, it gets more features. Add a knob here, a dial there, and the changes look pretty easy to digest. Add up these enhancements across several features, and you can create a product that's omnicapable, but nearly impossible to figure out on your own. Everyone likes to point to Microsoft Office as the best example of this point, but I can think of many others, too. (Some name-brand content management applications suffer from this malady, as do some multimedia editors I've used recently.)

Unfortunately, rebooting is not really an option. Not only do you risk losing customers if you cut too many features, but you're still contractually obligated to support people using the old product. (The phrase "legacy code" is as cringeworthy to development teams as "producer's actor nephew" is to movie directors.)

Still, it's important to regularly perform the mental exercise of cutting features you already have. Which didn't prove to be as important as we thought? What particular kind of customer cares about this feature, and why? It's easy to keep adding things; it's harder to remove them.

If you can't really cut back, at the very least, you can have an entry-level product. No, not some crippled application that doesn't solve anyone's problems, and is just a point of leverage for getting people to upgrade the real application. Instead, create a product that is useful, with a smaller range of features, to a particular audience that doesn't strictly need anything more. Go ahead and build more for other audiences, but always give someone the option to start with less. Let them decide for themselves if they want more.

The basic product becomes a lot like the DVD collections for some TV shows that focus on a particular plot element. Someone can watch the alien invasion episodes of The X-Files, or the Angel episodes of Buffy, and still enjoy that piece of the much bigger storyline. If a product team can't define the minimally necessary product, then they don't really understand their audience, and will face difficulties expanding it.

P.S. If you think that the fight against the cancerous growth of software features is harder than avoiding plot complexity in comic books, think again. The Superman comics have, in 20 years, again collected a lot of complex, interconnected, and unfamiliar story elements. Who the heck is Dominus? What's all the hoo-hah about this Doomsday guy? And how many times can Lex Luthor die, or at least appear to die, without the next death scene becoming unintentionally laughable? At least, in the technology industry, you don't really have to start all over again.

Nuts to negative solidarity

Phil Montgomery's recent post, "Hatred Is A Bad Business Driver," is definitely worth reading and taking to heart.  Here's the money quote from Phil's post:

I remember being at Novell in the late 90's and feeling absolute hate emanating towards Microsoft.  This was despite us all using many of their products internally - including Windows - Microsoft has some extremely good products (Excel is a case in point). Novell's hatred of Microsoft caused them to go on an irrational buying binge to assemble products (Wordperfect, DR DOS et al) and compete head-on with Microsoft. As we know, this didn't work - nobody can beat a bigger adversary by attacking them head on.  Hatred created a flawed strategy that led to failure.

Of course you have to observe your competitors carefully. Frequently, you'll need to react to what they're doing. However, that's not the same thing as shadowing their every move.

Tribes go to war
Usually, companies kick off these "Kill [Insert Competitor]" campaigns for internal reasons. They need to rally their organization around an initiative that's easy to understand, and plays to their employees' competitive instincts. The academic term for this behavior is negative solidarity, which all societies, from the most tribal to the most advanced, depend on to some degree to define and maintain their boundaries, and to motivate their members to defend the larger group.

Not surprisingly, negative solidarity is only useful to a point. While it's easy to define whom you're against, what exactly are you for? When the stakes are trivial, such as a soccer game or the Miss Universe competition, rooting for yourself against others seems pretty harmless. When you invade another country to distract the citizenry from the problems within your own borders, negative solidarity gets pretty nasty.

PMs get trampled
Since I've been interviewing product managers and product marketers for Forrester, I've seen a definite pattern. The more these groups focus on the competition to the exclusion of their customers, the weaker the PM group, and the less effective the PMs are in doing their jobs. Here's why:

• Competitors are easy to figure out. For technology companies, the competition is the point of reference in the market most like themselves. Understanding the feature list of a competitor's product is far easier than understanding the behaviors, attitudes, and quirks of users. Competitors are people like you; users live very different lives than software and hardware engineers.
• PMs have less to offer for competitive analysis. That's not to say that there's no value in having someone approach the task of competitive analysis professionally. It's also worth having people who dedicate themselves to staying on top of the market. However, competitive intelligence is relatively easy to collect, and easy for Development and other groups to interpret. Therefore, PMs primarily act as a collector of competitive data, not as an interpreter of what it means.
• Competitors can distract from the problems with your own strategy. Any reasonably clever simian can craft a product strategy based on matching the competition step by step. However, that approach makes two courageous and often dangerous assumptions: (1) The competition is following an intelligent product strategy; (2) However good or bad that strategy is, it works for your company.
• Excessive competitive focus undermines PM's ability to say no. For PMs to craft product strategy, they need to be able to veto ideas that don't contribute to that strategy. When the company gets too fixated on competitors, PMs get into a situation that resembles an argument with a Roomba over the finer points of cleaning your living room: It's programmed to respond to particular cues, impervious to whatever logic you try to apply.

This unhealthy dynamic undermines PMs role in the organization, which is a good measure of how well or poorly the company is responding to its customers.  Competitive analysis is critical, but it's not a replacement for your own company and product strategy.

Postscript
On a personal note, Phil's post caught my eye in part because I worked at a company that tried a "Kill Novell" strategy for a while. The source was the salesforce, which was complaining that they were running into Novell's file management products in their accounts. At one quarterly sales meeting, the salespeople were eager to get as much competitive data, plus our responses to the competitive threat, as we could provide.

Three months later, at the next sales meeting, Novell had disappeared from the radar. Meanwhile, we were the same company, slogging through the same sales process with the same products, and often the same customers.

[Cross-posted at The Forrester product management blog.]

Great business idea. Unfortunately, you can't do it.

As discussed in a recent post here on The Heretech, there's a big difference between invention and innovation. Nowhere is this distinction more clear than in the realm of business models and go-to-market strategies. Or, to put it another way, "Now that I've had this brainstorm, what do I do with it?"

When you get a great idea, it's intoxicating. In fact, you can get drunk on your own brilliance, often to the point where you should not be trusted to drive product direction. And the last thing you want to hear is some buzz-killing smartypants tell you that you're not really capable of turning that Big Idea into Boffo Business. (Little twerp.)

Unfortunately, that little twerp is often your best friend. It's no insult to say that the idea is really, really good, but that it's all wrong for your company. If there's no company yet, that market entry might be a lot harder than you think. Or, in either case, the cost of getting people to adopt your technology--the innovation part--might be pretty high.

Here are some common pitfalls for people who devise fantastic inventions, but have no patience for the business barriers for turning them into genuine innovations:

• You can picture what the technology will do, but you have no clear idea who will use it, and for what.
• You can picture who will use the technology, but you haven't solved a critical business problem for them,
• You've solved a critical business problem for that person, but they're not the ones making the buying decisions in the organization.
• To reach the critical buyer in the customer's organization, you need to work through channel and implementation partners that focus on that solution area.
• The idea is great, but costs and risks of replacing the existing technology are pretty high.
• You're a big technology vendors with lots of resources might bring the product to market,  but your own salespeople and partners have no incentive to sell it.
• Small technology vendors depend on turning the new technology into a "platform"--something that customers usually buy from larger vendors.

And I'm sure you've seen other examples. I have at least a couple of my own, if you're ever interested in hearing them.

Which is all a roundabout way of saying, before you kick off a new product, or God help you, a new company built around a great idea, stop what you're doing. Think hard about the invention itself long enough to consider how innovation is going to work. After you know that there's economic potential there, and it's not going to take the strength of Hercules and the wisdom of Solomon to achieve it, forge ahead.

Write the business plan. Hire the product manager earlier, instead of later. Do the necessary research. Be prepared to hear a few disappointing facts of life--but better to hear them earlier, instead of later.

Separating invention from innovation

It's not clear when it happened, but at some point in the history of the technology industry, people lost the distinction between invention and innovation. While insisting on the difference between the two words may seem like a minor semantic difference, it's as fundamental as distinguishing between speed and velocity as the same thing. In fact, mixing up invention and innovation is potentially as dangerous as confusing chemicals and medicines, if you prescribe one when you really need the other.

Tesla, Shmesla
Both Nikola Tesla and Thomas Edison were inventors. However, Edison was the better innovator. Fannish biographies of Tesla that complain about history's indifference to Tesla's genius are missing the point. Both Nikola Tesla and Thomas Edison were inventors. However, Edison was the better innovator. Fannish biographies of Tesla that complain about history's indifference to Tesla's genius are missing the point. Even if everything Tesla had invented exceeded Edison's in brilliance, Edison was much better at getting his inventions developed, sold, and distributed. (Throw in Tesla's unproven inventions, like the death ray and ion-powered aircraft, too, if you want.)

The story of Edison and Tesla should be iconic for today's technology industry, but it's not. Instead, many (perhaps most) technology companies act as though invention is all they need. When they face challenges--from competitors, the economy, or customer rejection--these vendors reflexively turn to invention as the solution. Increase features in the product, add new products, add new service offerings--these are inventions that, ipso facto, people will not necessarily adopt.

Ingres, Shmingres
Over the years, I've worked with a few veterans of Ingres who voiced a complaint that sounds a lot like the grudge Tesla fans hold against Edison. Ingres, they believed, was the better database, far superior in features and design than its chief competitor, the Oracle RDBMS. Y'know, they may be right--and that conclusion, however justified, would be irrelevant. Oracle's advantages, such as its famously aggressive salesforce, decided the issue.

You might conclude from the Oracle-Ingres battle that the technologists and salespeople just need to keep on executing for the company to be successful. For a variety of reasons, innovation is much trickier.

Inventions Are Not Projectiles
For example, Development can't just throw new technology over the wall to Marketing and Sales, and expect good things to happen. Someone always needs to mediate between Development and Sales. In the technology industry, that job function is spread across product managers, product marketers, sales engineers, and people in other roles. Activity in this middle layer needs to flow both ways, tuning the invention to better fit the market, as well as getting the invention sold and implemented.

Once you disentangle invention from innovation, many fallacies of the technology industry fall out. For example, being the first to market with an invention isn't necessarily the best strategy. To go back to the computer game industry for a moment, LucasArts often followed in the draft of other companies that invented new types of games (air combat simulators, graphical adventure games, etc.). Learning from their competitors' successes and mistakes, LucasArts was often happy to be the second to market.

So, the next time you hear someone praised as an innovator, ask yourself, Is this person really an inventor? And if so, who helped turn the invention into an innovation?

[Cross-posted at The Forrester product management blog.]

Space Marines, attack!

A segment of the technology industry reaches a point where the different species of applications are well-known and well-established. As long as no new species emerge, vendors settle into a features arms race, hoping to impress potential customers an ever-increasing number of options and capabilities. Meanwhile, many customers look at their limited time, limited budgets, and limited interest levels, and wonder why on earth these vendors think that added complexity is always a good thing.

Sound familiar? It should--and perhaps not for the reasons you think. I'm actually talking about the computer gaming industry, which in many respects leads their more serious brethren among software companies. Take a moment to consider the challenges that game vendors have faced and overcome:

• High quality levels. Oddly, people get far angrier over bugs in a $50 Wii game than they will about a much higher bug count in a $500,000 ERP system.
• Customization. The challenge of maintaining quality increases another order of magnitude the moment you add customization capabilities. On the other hand, the demand for customization (called modding in the gaming world) 
• Demanding channel. Once you set a release date, you're highly penalized for missing it. Forget staying on good terms with retail outlets and media outlets that count on you making your date. High turnover. The shelf life of the average computer game is measured in
• The Internet in the product. The gaming industry have its version of software as a service (SaaS), the massively-multiplayer online role playing games (MMORPGs) like World of Warcraft. Even best-selling on-premise games like Call of Duty need a strong online component.
• The Internet in the business model. An increasing number of gaming companies are shifting to an online distribution model (for example, Steam). Online distribution also makes smaller components--both add-ons and independent products--more economically viable.
• Social media. Game vendors invest heavily in creating and maintaining their communities, such as the XBox Live, to the mutual benefit of customer and vendor alike. These communities take real investment, however, including both the implementing technology and the people needed to monitor the community to maintain a good customer experience.

Note that the list above describes changes that affect the computer gaming market more than computer games. Standards for the actual products, such as quality levels and customization, haven't changed that much. You can still categorize games into well-understood genres, like first person shooters, with little changed in the last few years. (The notable exceptions, of course, are the MMORPGs.)

Which leads us back to the "more is better" dynamic. Despite more impressive graphics and an ever-increasing number of game options and capabilities, many types of computer games have plateaued in sales, or even started to drop.

MMORPGs are one source of distraction. Economic upheaval doesn't exactly help sales. However, there's more to the story, in which the protagonist (the computer gaming vendor) reveals his fatal flaw (addiction to complexity).

Some gaming vendors have spotted the problem, and taken steps to fix it. The developers behind Warhammer Online, for example, recognized that many gamers spend time "soloing," spending a lot of time playing on their own, instead of teaming up with other players to meet game objectives. Warhammer Online, therefore, doesn't distract the solo player with information about team options that he doesn't care about.

This interview with the designers of the just-released Dawn of War 2 is one of the most interesting discussions of this issue. You don't need to be a gamer to appreciate comments like these:

To us, it felt obvious that we were falling behind for a reason. We decided we needed to simplify the entry point but retain the depth at the back end. And we need to work on the pacing. We need to work on ways to draw the player in...

If you substitute the word user for player, and ERP system for game, you'll see why the computer game industry has many important "lessons learned" for people building other kinds of software.

[Cross-posted at the Forrester blog for product managers.]