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 McObjects 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 Heretech.]

Google Wave makes smart design decisions early

Which business problems will Google Wave address?
A few weeks ago, I watched the Google Wave launch video with a mix of interest and nervousness. A big part of my reaction was shaped (warped?) by my experience doing product management and product marketing for collaboration and content management products. While I didn't launch myself at the screen yelling "Noooooooo!" (in slow motion), I did worry that Google might walk straight into an all-too-familiar minefield of competing solution areas.

Collaboration and content management pose a classic problem in requirements and design: Which solution do you want to target? If you build a product without prioritizing among all the different business problems that it might address, you'll build a very "horizontal" product that satisfies no one. Or, worse, it makes perfect sense to you, but everyone else struggles to see how it will best work for them.

Customization in Google Wave
The very horizontal application demo application in the launch video bore an unsettling resemblance to other UIs for collaboration and content management (CM) that I've seen over the years. Unlike the UI for a word processor (like the one for Google Apps), the face of collaboration and CM tools twist and flex to the shape that organizations strongly want them to take. Remove this, add that, change how this works, make this piece run by itself in a portal, etc.

Which leaves the product team with a dilemma: Do you build something that works really well for a particular solution area (say, the loosey-goosey world of ad hoc collaboration), but not for others (for example, the highly structured processes needed for single-source, multi-channeled publishing)? Or do you build something that's highly configurable and customizable, and let the customers and partners do the morphing?

While I'd pick the second option, it has its risks. Prominent among them is forgetting to prioritize this kind of plasticity early in the product's lifecycle. With every month of coding, the product gets more resistant to your later efforts to build in customizability.

Having seen how much customization is built into Google Wave, I'm both relieved and impressed. Google already has a very big community of early adopters using the APIs and protocol to build plug-ins to accommodate a variety of use cases. From these humble beginnings, developers will build more sophisticated customizations. Will these rise to the level of capability need to address business problems like corporate risk management? We'll have to wait and see.

Google's other dilemmas
Customization isn't the only dilemma that the Google Wave team will face. For perfectly good business reasons, someone will ask, "Can I keep my content stored in my own repositories, and just use Google Wave as a collaboration and management layer above that storage?" The huge architectural questions that poses will force Google to say, "Yes, that's the business we want to be in," or, "No, that's not our core business."

Note that the choice is more about business than technology. Google is full of smart technologists, but its resources aren't infinite. Depending on the solution area, Google would have to acquire a different mix of domain expertise, marketing resources, partnerships, and sales muscle. I'd bet that the mix needed for most solution areas would not look very attractive to Google. Making a smart technology choice, up front, ensures that Google has the flexibility to choose among these options.

[Many thanks to Lars and Jen Rasmussen for yesterday's Q&A on Google Wave. If you're interested in being an early adopter, sorry, they told us that they already have the first 100,000 registrations. However, it's still worth signing up, if for no other reason than to tell Google how many people are interested in Wave, and how they'd like to use it.]

[Cross-posted at The Heretech.]

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 Heretech.]

Of designers and developers

In today's post at The Heretech, I come out of the closet. Yes, I am a bigger history geek than you can possibly imagine. Hello, my name is Tom, and I play wargames.

However, by playing a lot of games designed to simulate historical events, I've learned a couple of things that apply to designing products in the technology industry. Specifically, how do you create a design teeam that can overcome some of the common pitfalls, such as unnecessary complexity? To read more, follow this link.

[P.S. Thanks for pointing out the problem with the link. Typepad is intermittently eating the hyperlinks I enter. From now on, I'll just have to test them before I publish.]

Reboot camp

Learn how Superman's never-ending battle for truth, justice, and the American way has relevance to technology product strategy at The Heretech.

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 Heretech.]

"Why, with this invention..."

Apparently, if my goal in last week's post about invention and innovation was to spark discussion, bringing up the Edison/Tesla rivalry was the right thing to do. For example, here's a excerpt from Richard Lessman's comment:

Except that despite being poor and having many of his inventions unrealized, a hundred years later we're still using Tesla's work rather heavily. This says something about his pure success as an inventor, with or without massive market capitalization.

...And I agree. Yes, our electrical distribution mechanisms use Tesla's AC, not Edison's DC. Yes, Tesla's coils became a component of other inventions, such as radio transmitters and medical devices. And yes, arguably, Tesla is a vastly underappreciated inventor.

However, none of that necessarily helps technology companies, which frequently confuse invention and innovation, understand how to be more successful businesses. Six years passed between Tesla's invention of his eponymous coil and the first demonstration that it could be part of an economically viable technology for "wireless telegraphy." More years passed before radio transmitters and receivers enjoyed widespread adoption.

Needless to say, that's not the time-to-market that modern technology companies hope to achieve. Rather than focus on innovation--spreading the practical application and adoption of an invention--some technology vendors conclude that they need to keep tinkering with the invention.

The unstated assumptions sound a lot like Victorian notions of science and technology, at least in the popular culture of the age:

• New technology grants immediate power. Think Captain Nemo and the Nautilus, which destroyed warships with impunity. Verne gave almost no details on how Nemo got the material and labor to create the Nautilus in the first place.
• New technology finds widespread application, somehow. Never mind the details like, say, how the telegraph went from "What hath God wrought?" to an international communications system. Even modern histories bleep over the "go-to-market" for the telegraph, as if technology merely flowed of its own accord into the spaces where it's needed.

Of course, Victorians were in love with science and technology. Fervent admirers don't care about the unlovely process of what happens before the premiere. What captures their imagination is the moment their object of desire steps onto the stage, with all the glory of success, and none of the homelier efforts that preceded it.

While this conceit might work in a technothriller, the missing details matter a great deal in the technology industry, where good ideas don't always succeed. Invention and innovation aren't mutually exclusive, so tech vendors need to invest in both to succeed.

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. 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 Heretech.]

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 Heretech].

From the cradle to the grave

During the last couple of month's worth of conversations with product managers and product marketers, the following questions popped up with conspicuous regularity:

• What's the difference between an offering and a product?
• How much do service offerings need to be treated as products, meaning that they need real product management?
• How do you know when something is ready to be called a product?
• How do other companies handle "productization"?
• What best practices do other vendors use when defining the product roadmap?
• Should we put our product into maintenance mode?
• Realistically, when can we cut off support?

The order in which I've placed these questions is no accident. They're the cycle of birth, maturation, old age, and death that all products face.

Without getting into all of these questions, which would take much more verbiage than one blog post permits, it's worth making an observation about the questions themselves: The challenges of the product lifecycle illustrate that the technology industry is still in its adolescence.

Product managers face two levels of difficulty, therefore, in handling these issues.  First, even in the best of circumstances, the work required take a serious amount of project management, negotiations with customers, potentially nasty legal pitfalls, and a whole lot of other tasks.

Unfortunately, that's where the lack of industry-wide best practices make this work twice as arduous as it should be. In other parts of the economy, vendors have long ago worked out these de-support issues. Automobile companies, for example, know from the day a new car appears on the show floor how many years into the future it's going to keep having to devote attention to this product. When the three-year warranty on my television ends, I have some idea, as a customer, how much help to expect from the manufacturer and the place where I bought the device.

No such clarity in the technology industry, except perhaps on the hardware side. Our current economic woes, however, may be muddying that picture. Customers are less willing to upgrade hardware, if they can avoid it. Vendors would prefer that they didn't avoid it. Who will win that tug of war?

I'm not surprised, therefore, to hear these questions from technology vendors--and in particular, the people whose job description alludes to managing products. Perhaps technology vendors can save themselves a lot of grief, since they'll have enough challenges in the next year, if they were to apply a bit more discipline to the product lifecycle.

[Cross-posted at The Heretech, where I write things that don't appear here!]