How an ISV uses "inbound" social media

 In this week's Heretech podcast, I spoke with Alex Bender of Archer Technologies about the role the Archer community plays in the development process, all the way through the release. If you click the thumbnail shown below, you'll see their process in graphic detail. While Alex and I didn't get into all the specifics of how they do it, we did cover most of their "social product management" approach in the podcast. 

Among other interesting aspects of how they use their community as a resource for innovation and adoption, the role of partners really stands out. Of course, in the governance, risk, and compliance (GRC) space, you have an ecology of partners who are experts in things like Sarbanes-Oxley and risk management best practices. They'll tell you in plenty of detail why your product isn't really doing the job it should as a GRC tool.

GRC implementers and advisers have a very explicit kind of domain knowledge. However, if you stop to think about it, almost any partner has domain knowledge that's valuable to ISVs. To cite an obvious example, how does the average organization implementing your technology define the project? What obstacles do you impose at the critical landmarks in the implementation?

We usually talk about communities as consisting of customers. However, I think it's worth including partners whenever you talk about your community strategy.

Innovation's moment of truth

You just got out of the meeting with potential customers, and they're not big fans of your Big Idea. You were sure it was brilliant, but they just don't get it. Or they applaud the effort, but they think you're going approaching it from the wrong angle. 

Here's the moment of truth when many projects go bad, and sometimes drag companies down with them. The crisis isn't unique to the technology industry--there's the cautionary tale of New Coke, after all, from a well-established industry that should have known better--but given the immaturity of the technology industry, and the plasticity of the work product, it happens quite often.

At this moment of truth, development teams choose from among the following responses:

• "These people are idiots. Let's go."
• "They're not idiots, but they're not our market. Let's keep setting meetings until we find people who can appreciate what we're trying to do."
• "Maybe if we talk more, they'll finally get it."
• "Maybe we didn't put enough into the first version. Let's go back and see what enhancements will make the product more appealing."
• "We've committed too much into this project to stop now. Forward! We'll work out the sales and marketing later."
• "Maybe we had a good idea, but we went about it the wrong way."
• "Maybe there isn't the market for this idea."

Adam Smith, meet Sigmund Freud and Niccolo Machiavelli
At moments like this, we can see why the simplistic economic model of the firm as a unified, rational actor makes zero sense. All of these responses might be the correct one. A rational,  unified actor should select among them impartially, based on their inherent risks and rewards. For example, if there really isn't a market for the idea, the consequences are dire. (If you were a game theorist, you'd work as hard as possible to prevent this kind of "nuclear option," even if the risks were low.)

Unfortunately, companies are not rational, nor are they unified. People have strong emotional attachments to their ideas, the people with whom they work, and the work itself. They also worry about the politics within their organization. For example, what happens to your reputation as a Wunderkind if your latest great idea turns out to be a flop? And what will the investors, or Management, think?

Market test early and often
This is exactly when the organization needs professional product management and product marketing, as long as you're serious about getting someone's honest assessment. Is the problem with the invention itself? If so, you need someone who can do an objective, credible appraisal of the problem, if it exists, with the product. Is the problem with your explanation of its value? If so, it's critical now to address that problem quickly and professionally, if you're going to build any market momentum, pre- and post-launch.

Inventors need product management and product marketing as early as possible. Unfortunately, in the history of the technology industry, that scenario doesn't happen as often as it should. Companies commit people and resources to an idea before it gets real market testing, or even a clear picture of who's going to use it, who's going to buy it, and why.

Innovation is more than just inspiration
Innovation--the art and science of converting inspiration into adoption--doesn't really start until someone performs these tasks. Therefore, the moment of truth depends on admitting the possibility that you don't know your target market as well as you should.

When the market feedback is disappointing, you need to establish some emotional distance from your idea. The invention still may have a bright future, but the consequences of being wrong might be disastrous. If you find yourself looking for reasons why you were right all along, without taking any time to question your ideas, or even the people with whom you're working, then you know you're setting yourself up for failure.

[P.S. If you're looking for other examples of this principle in practice, let's just say that the point is as valid in US foreign policy as it is in the technology industry.]

[Cross-posted at The Heretech.]

Invention, innovation, and product management

In response to the last couple of posts about invention and innovation, Jennifer says:

While this is an interesting thread to read, and can definitely cause many long hours of debate sitting in front of the fire with our pipes et al, it seems that it might be missing the mark with product management.

Yep, I agree. Which leads me to the next point I wanted to make in this series:

Inventors in development need innovators in product management.

While the two groups often don't get along very well (product managers are naysayers, development is just doing its own thing, etc.), the partnership between them is essential.  Someone with a cool idea and enormous technical skill is usually the first person in a new product group, or a new startup company. However, that inventor can benefit immediately from someone who's a professional reality checker and opportunity finder--a product manager.

I'll have more to say later about the sources of ideas for both invention and innovation. For this morning, since I have to run in a minute, it's enough to point out that the frequent frictions between development and product management are not only unnecessary, but pernicious. Tech companies need to bring new products and services to market as quickly as possible, which is really another way of saying, "We need really good inventors and innovators."

That may seem like a small semantic difference, but it's really a critical conceptual clarification. Too often in this industry, excellent inventors style themselves to be innovators, which they're not. Happily, they work with product managers (and product marketers, and consultants, and arguably a lot of other people involved in the diffusion of inventions), who are more than glad to help. If the two groups aren't working well together, the core problem is often the organization's ignorance of the invention/innovation distinction.

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

The end of reposiphilia?

One sure sign that Web 2.0 is a genuinely new epoch in the tech industry: the haymaker punch it threw at a repository-centric view of application architectures, effectively knocking it out of the ring. For those who aren't familiar with what I'm talking about, I'll give a little bit of history for the young 'uns out there.

Forward into the past
Let's hop in a time machine, go back 10 years, and eavesdrop on conversations in development teams building multi-tier applications. Chances are you'll hear no small number of words about the repository. For example, suppose the project was integrating two middleware applications, such as content management systems and ERP applications. In many development teams, you'd get funny looks if you didn't advocate some merger of the two repositories as the solution to the challenge. Integration at the middle tier sounded, to many ears, like trying to pull a fast one, substituting a hack for "real" integration.

Of course, the reposiphiliacs had an argument worth taking seriously. If you didn't have a single repository, you'd impose more work on the DBA or sysadmin. Any repository-level rules--stored procedures, data retention policies, etc.--would have to be repeated across every repository. If standards didn't compel people to build similar metadata schemes, you'd spend a lot of your time translating between applications, often with very different notions of the same attribute. (Over here, it's an array; over there, it's not.)

Everything you know is wrong
Now, let's jump back to the present day. One of the striking things about the Web 2.0 world is not only the ease of integration, but also the relative unimportance of the repository in the discussion. You can add your Flickr album to your Facebook profile. Mashups keep on growing, both in options (what you can combine) and methods (how you build them, and the level of technical skill needed). You can upload documents to Box.net, and use Zoho to edit them in place. RSS has grown from simple newsfeeds to an inter-application communication medium. When I publish this post, a link will appear automatically in my Twitter feed. And so on.

Nowhere in this discussion do you hear the word "repository," nor do you need to. Certainly, data structures matter, as do the media for communicating metadata from one application to another. But the underlying repository--by which I mean, if it's not clear, the place where the content is stored--doesn't really matter all that much. In fact, as Web 2.0 charges forward, the repository continues to be commoditized. Amazon, Salesforce, Intuit, or someone else will handle the structured or unstructured data storage and management for you.

What many once considered to be a kludge--integration above the level of the repository--is now the main platform for innovation. Now, if that's not a sign that we live in a different world, I don't know what is.

A SPITR in the eye

A while ago, I published a piece titled "Beyond Innovation: Adding Adoption To Your Business Objectives," which started with the observation that we're damn lucky in the technology business. Innovation, particularly on the software side, moves faster than in other industries because of fewer physical constraints. Oh, sure, a few hard realities apply, such as the speed of light, or the amount of heat your overclocked gaming PC generates. Those constraints are trivial, compared to the limits of physics and chemistry that innovaters in other industries face.

As good as rapid, unconstrained innovation can be, it's not without its problems. Technology companies want to give the human source of these innovations, whom we'll call The Smartest Person In The Room, enough latitude to put their talent and creativity to work. And heck, since they're smart, why not put them in charge of things needed to bring their innovative ideas to market, such as the development team? Unfortunately, there is such a thing as giving highly intelligent people too much latitude.

Around the Valley, the Smartest Person In The Room (SPITR) often holds a title like CTO, Chief Architect, or Development Manager. The stereotypical SPITR is thirty-something, graduated from a school like Cal Tech or RPI, wears slacks with tennis shoes, and talks at a pace that's sometimes hard to follow. The SPITR has profound technical skills, and a creative mind that operates much like a pinball machine, lights flash and sirens sound when the SPITR hits a new idea, and it won't be long until the SPITR bounces to to the next possible innovation.

Obviously, every company needs to hire people like the SPITR and find the right role for that person. You'd be stupid to waste someone that valuable. However, even the smartest people aren't smart about everything. For example, Napoleon may have conquered continental Europe, but he didn't have the political acumen to know how to hold on to what he won. Symptomatically, he had a bad habit of putting his less-than-capable relatives and cronies on the thrones of defeated countries, with predictable results.

The same rule applies: SPITRs are good at many aspects of product or service development, but not everything. For example, just because a SPITR is smart doesn't mean that person will make a good development manager. Every team lucky enough to have a SPITR needs to be realistic about filling out the other roles with people that have complementary skills. The SPITR also needs a counterbalance, since not every idea from any human being is going to be a good one.

Unfortunately, some technology companies give too much unchecked power to the SPITR. You know you're working in one of those companies if...

• The feature list for the next release is completely under control of the SPITR.
• The SPITR has a secret feature list.
• The development team looks to the SPITR for guidance more than 80% of the time, and to the customers and partners 20% or less. (We might want to set the bar lower, but you get the idea.)
• The SPITR takes risks, such as last-minute check-ins of unreviewed code, granted to no one else on the team.
• The SPITR has a product vision that no one else on the team fully understands.
• The SPITR's projects are surrounded with so much mystery that no one in upper management feels competent to judge how well these projects are going.
• The SPITR does not have time to mentor other team members.
• If in a managerial position, the SPITR is not devoting sufficient time to management tasks.

Dealing with an unchecked SPITR is not easy. Companies fear that, by doing so, they'll squelch the SPITR's innovations, or drive the SPITR to look for a job in another company. But those are just excuses for bad management. If Eisenhower could make good use of Patton, a CEO or EVP in a software company can figure out how to harness the talent of a good SPITR who's responsible for too many things.

The research Inbox and Outbox

Recently published: "Beyond Innovation: Adding Adoption To Your Business Objectives."
This document started as a survey of technology industry professionals, asking them what they thought set this part of the economy apart from other verticals. The title of the piece reflects the conclusion, from taking a close look at the survey results. The punchline is, focusing on adoption can provide a powerful competitive advantage.

Coming soon: "Inquiry Insights: CRM Customers Focus On Business Processes, Not Technologies."
This document will be my inaugural piece about CRM. What does it have to do with product management? Quite a lot, both in how CRM does and does not factor into the sources of information for PMs. In this case, we looked at the questions we receive from customers implementing CRM systems. Obviously, these questions say a lot about the real needs of CRM customers.

I'll add one more observation about the connection between CRM and product management. When our PM group at one technology company developed a custom requirements application, one of the executives asked, "Why are you developing a CRM system, if we already have one?" Well, er, sir, it goes something like this...

The grown-up world of computer games

The most mature part of the technology industry may be the console and PC game vendors, who pitch their wares at the least mature audience. These companies matured the hard way, by surviving not just technology challenges, but having to master business techniques that many other technology companies have yet to learn. Here are a few examples:

• Channels. Game companies like Electronic Arts and Blizzard would never have survived and prospered if they hadn't mastered the retail channel. With a shelf-life of several weeks, every computer game had to hit the retail channel at the right time, with the right amount of copies, to succeed. Game vendors also had to maintain these channel relationships, even when there wasn't a lot of new product in the pipeline.
• Partners. Game vendors learned long ago how to make partnerships work. Small development firms, such as Dice or Relic, need to find big partners like Sega and EA to package and distribute their products. When it didn't make sense to invent new technologies, such as 3-D gaming engines, from scratch, they had to work out licensing agreements.
• Quality. The average console and PC game has fewer bugs than enterprise software costing hundreds or thousands of times more, per copy. If you buy a buggy XBox 360 game for $50, you can always take it back a few days later to Best Buy or GameStop. If you buy a $500,000 ERP system, you won't know all the showstopper bugs until you're well into the implementation.
• Innovation. The most successful game vendors were not always the ones to come out with a new technology or a new idea first. In fact, LucasArts did a great job of being the second through the door, having learned from the first competitor to build a
• Time to market. Having mastered these other techniques, successful game vendors can control their production schedules, instead of having the schedule control them. Blizzard has shown how a smart company can avoid making firm commitments about release dates until it's clear that the game is ready to go to market. Other vendors have waited too long, such as the Battlecruiser 3000 debacle, or rushed unready products to market, such as the bug-riddled Knights of the Old Republic II.

Sure, game vendors make mistakes. Many of them look worse than they really are, however. For example, the vast majority of "tie-in" games, based on popular movies and TV shows, stink on ice. However, in an industry where shelf-life is short, a small company can still make amoney on a licensed game, since the game will be off the shelves almost as soon as the negative reviews are published. Cynical, yes, but hey, it's business.

Other technology companies might learn a lot from the game industry. They may also ponder how much good it did for the game vendors to work under constraints like the retail channel. While everyone wants to be masters of their own destiny, sometimes you can learn a lot more valuable lessons with less freedom of action. To use a musical analogy, you learn to play scales before you improvise, not the other way around.

Customers: threat or menace?

Maybe it's just me, but I seem to have bumped into a lot of people in the technology industry who think that innovation and customer sensitivity go together as well as Batman and the Joker. (Spoiler alert: Innovation is the good guy.) In this worldview, customers can't understand innovative ideas, because there's no reference to them in reality as it exists today. Innovation is just too...Er...Um...Well, it's too damn innovative for the average person to understand.

According to a different point of view, as expressed in this post on Derek Morrison's blog, if you spend time with customers, you'll find inspiration for new ways of helping them that you never would have conceived on your own. Customers are not objects to be overcome; instead, they are wellsprings that you can help channel.

Which is right? It depends. On the one hand, I've seen people fail to understand Big Ideas until they saw it in action, at which point, they loved it. The iPod was one of those Big Ideas. XML was another, something that a surprising number of developers didn't get when they first heard about it.

However, this approach has its risks. Failing to make the step from the Big Idea to the Mundane Details is one of the most  problems. For example, there are different subcomponents of the XML specification, such as XPATH and XSLT, that could have been designed better. I've used them, and as an XML enthusiast, they left me with the strong impression that they were not designed with too many real-life use cases in mind.

On the other hand, innovation through observation isn't free of risk. Target users may know what problems they face, but they may have trouble describing them (or what a solution might look like). Consequently, the technologist may have just as hard a time getting out of the swamp of  problems, since they may not understand the landscape any better than the users do.

Still, problems with one approach are no excuse for failing to use it. These two techniques for stimulating innovation--what pops into my own skull, what I see happening in the reality I don't fully understand yet--buttress each other.

To disagree with Derek for a moment, incremental changes can be "game-changing." In the search for the Big Idea, you might miss these profound opportunities. A couple of year ago, I heard a presentation from Patrick Whitney, a faculty member at the IIT Institute of Design, in which he described how the inspiration to add a better grip to a potato peeler revived innovation in one of the least likely areas of technology. It took one person watching another person peel potatoes to have this multi-million dollar idea.