The Heretech

From on-demand to on-premise

Assembla has faced the same challenge as many SaaS vendors: What do you do if some of your potential customers have a problem with company-confidential data outside the firewall? The obvious answer is, give them an inside-the-firewall option.

Most discussions about cloud computing, at the application layer (SaaS) or deeper (PaaS), cover either technology that was designed for the cloud, or on-premise technology that has moved to the cloud. And then the people with security issues, or other concerns about cloud computing, bring the discussion to a standstill. (At least for them.)

Assembla's answer: OK, here's an image of the software, and we'll also give you the source code. Happy?

While this approach may open a new can of support-related worms, it may be well-justified if the on-premise customers can make it worth the vendor's while. Not every SaaS company, therefore, will be able to find the business justification to add this option. For those that do, all I can say is, be very, very careful writing your support contracts. In fact, ask for help from someone who has crafted them for an on-premise company.

[P.S. Andy Singleton, the president of Assembla, is a very active user of the company blog to communicate substantive, useful information about everything from new product features to pricing. The communication is definitely not one-way, as many of the comments, and Andy's replies, demonstrate.]

Yawn, another SharePoint-generated apocalypse

Forrester colleague Oliver Young has a great post on his blog about the SharePoint "day of reckoning." The quotes around that phrase are important, because, as Oliver discusses, some of the apocalyptic predictions about SharePoint's effect on the collaboration market are a wee bit exaggerated.

I've been hearing how SharePoint will lay waste to all independent collaboration vendors for years. Maybe it will actually happen this time, but I have my doubts.

It's unquestionably risky to fight SharePoint on its home terrain, the collection of intranet collaboration workspaces, closely tied to Microsoft Office and other Microsoft-based applications. However, as Oliver points out, that leaves a significant amount of space in the collaboration ecology for other vendors to play. Plus, as Leslie Owens and Rob Koplowitz point out (Forrester account needed to access the full report), the organization and content of existing intranet sites don't automatically map to SharePoint's way of building an "information architecture."

Certainly, other vendors will need to find a niche that keeps them out of the way of the T. Rex of collaboration. That's not the same thing as saying, however, that the T. Rex will eat everyone--or even if it did, that it had the means to survive on its own. At the very least, other vendors will do things that Microsoft won't, either as part of SharePoint deployments, or somewhere adjacent to them.

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 Heretech, episode 11: Laura Ramos on B2B marketing

Laura Ramos talks about how effective B2B marketing is a mix of old and new techniques. Plus, why even the best books on Agile are often not enough. Copyright (c) 2009 Tom Grant

"Continuous" doesn't mean "constantly"

I was agreeing with this post by Lincoln Murphy at the Sand Hill blogs...Or, at least, the first part. Yes, technology companies--and not just the ones that have SaaS offerings--would be well-served to think of their products as services. However, I don't follow the leap from that point to statements like, "Services Do Not Have To Have Versions Or Releases." In fact, that's the leap straight into a hole.

A lot of SaaS vendors believe that rapid releases of new capabilities are the key to success. Talking to end users and IT departments, however, and you get a different story.

Obviously, the rate at which people and organizations can ingest new information, then act upon it, is not infinite. Even if the information is highly valuable--how I can lose weight, be more productive, get incredible deals, radiate confidence, make the right investments, etc. etc.--there's only so much that you can process in a day.

The last thing you want to do with customers is confuse them. Or build them things that they don't notice. Or make them feel lost, the next time they log into an application that they use every day.

And it's not just the customers that get confused. Inside every technology company, there are nice, well-intentioned, highly professional people who need to market, sell, and support the product. Salespeople have other things to do than learn about this week's list of new features, or stay current on the roadmap of weekly releases.

In most situations, people need landmarks to encapsulate change. Not everyone wants to be on a constant voyage of discovery, particularly when they're not in control of the direction or speed.

Why do tech companies often overlook these human limitations? Because, in the minds of some immature people in an immature industry, value is a direct function of features. The more, the better. The faster they're delivered, the better.

The principle, Faster is not necessarily better, applies in different degrees across companies. If Flickr or eBay add new features every week, their audience will be a lot less annoyed than, say, a government auditor using a document management tool like SpringCM, or the lawyers who manage their practices with Clio.

Even so, everyone has their limits.

Why use cases should drive technology design

During a briefing from Microsoft's xRM team, the question of how to integrate structured and unstructured data arose. If xRM (the Dynamics platform) is good at the structured stuff, and SharePoint is good at unstructured content, what's the right way to bridge the two?

Back in my Oracle days, we faced exactly the same question. At a technology level, there's no obvious answer. Bring together two development teams (the structured and unstructured specialists), and you'll first get a lot of technical-level discussions. How should security work? What API changes might be needed? How will metadata span the two kinds of information?

Unfortunately, there's no immediately obvious answer to these questions. In fact, the options are so broad, and the risk of technological quagmires so great, that the endeavor might easily grind to a halt. People ponder the options, argue over which one is best, go back and ponder some more...

At Microsoft, a clear use case accelerated this discussion. The Public Sector group developed a constituent services application for local governments that combines both SharePoint and xRM. Notice how specific the application, the Citizen Service Platform, is. Not all government, but local government. Not several government functions, but constituent services. 

Undoubtedly, the Citizen Service Platform team made it clear which kinds of integrations were important, and which weren't. It's not too hard to generalize the use case to other situations. After all, we're talking about the same CRM platform that property managers and church pastors use, for different but similar purposes.

For people who are already sold on use cases as the right foundation for designing products, this might seem like a "Well, duh!" sort of observation. However, many product teams go full speed ahead with only the haziest use case, or to be honest, none at all. If their product decision-making process is too slow, or too error-prone, they might reconsider the value of a very specific use case.

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

The cringeworthy list

Stewart Rogers has started a list of words and phrases that make PMs cringe. I'm sure that you, Dear Reader, have at least one to add.

Podcast follow-up: A movie recommendation

Here's the movie, Witnesses, that I recommended in this week's podcast. For those of you who haven't listened to this week's episode of The Heretech podcast, I cite Witnesses as a great way of showing how hard it can be to understand people with whom you have the briefest of contacts. On top of that, the lack of information matters a great deal.

The movie is about the conflict between Croats and Serbs, but the moral applies to a  lot of situations.  For example, an enhancement request is a small piece of information that, because of its incompleteness, can be wholly misleading.

Podcast follow-up: The CPM's "bona fides"

Yet again, Rick Chapman of aaSS University glances left at his concept of product management, glances right at reality, and concludes that reality must be wrong. In this case, he tries to cast doubt on whether the Cranky Product Manager is currently employed as a product manager, and therefore if the CPM can speak with any authority or accuracy about product management.

The basis of the charge? The CPM can get sales projections. Therefore, according to Chapman, the CPM is fabricating an incident that could not have happened, because PMs never get sales projections.

I can confirm that the Cranky Product Manager, whom I just interviewed, is a real product manager. And yes, in many companies, PMs do get sales projections. In fact, they can't do their jobs effectively without this information.

Chapman reminds me of the Houyhnhnms, a race of intelligent but narrow-minded horses, in Gulliver's Travels. The Hounyhhnms are baffled by Gulliver, an apparently intelligent creature who looks a lot like a Yahoo, a "degenerate and brutal" species of animal. The savage Yahoos couldn't possibly be endowed with reason, and if they were, it would be a very dangerous situation indeed. Gulliver flees the land of the Hounyhhnms, since there's no way to convince them that he is both intelligent and not a threat. With their comfortable worldview restored, the Hounyhhnms are happy to see him go.

The Heretech, episode 10: The Cranky Product Manager speaks!

The Cranky Product Manager talks about the sources of crankiness, and not just for product managers. We've masked the CPM's voice to protect the satirized. Plus, a movie recommendation for anyone who thinks it's easy to understand what customers really want. Copyright (c) 2009 Tom Grant

"Good enough" isn't good enough

I'm a big fan of the latest version of Microsoft Office. Rather than just keep plodding forward with yet another set of new features, the product team tried to re-design Office to make it more useful. A good chunk of that effort went into making the capabilities of Office more visible, since most of the features that accreted over several releases were hidden away in various menus and dialogs.

That's only a small part, however, of the very interesting story behind the Office re-design. I strongly recommend taking the time to watch "The Story Of The Ribbon," a presentation by Jensen Harris, the group program manager for the Microsoft Office user experience team. It's also a good history of Microsoft Office interface design, which led Harris' team to conclude that the most common reaction to the UI, "Good enough," actually wasn't good enough.

Harris' team spent a lot of time with users before forging ahead with the re-design. However, the Microsoft Office team wanted to learn how people used Office, and also what they wanted from it. In other words, it was a much different requirements-gathering effort than the typical "Tell us what features you want" meeting, or other mechanisms (e-mail, the bug database, voting on features, etc.) that convey only bits and pieces of the overall picture.

Ultimately, the overall picture is what makes the new Office way, way better to use. As the results show, building a good product isn't a question of having a creative or inventive team. Nor is a stream of customer requests going to tell you everything you need to know about making them happy with your product.  You need both, and the right mental framework into which all these pieces fit.

[Many thanks to Peter Merholz for the link to this presentation. Thanks also to Daniela Busse, one of the members of the Office design team, for a separate explanation of the thinking behind these changes.]

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.

Deciphering Google Wave

After watching the launch video for Wave, Google's new collaboration technology, I followed a link to another video about "live collaborative editing." Since I had expected to see more details on the applications that Lars Rasmussen, Jens Rasmussen, and Stephanie Hannon had demoed, it was a bit surprising to hear a Google developer talk for several minutes about session management. And therein lies a bit of the initial confusion about what Google Wave will be, or what it's most likely to turn out to be.

Before coming to Forrester, collaboration and content management were my main focus for several years. It's a fascinating topic, full of interesting challenges for product designers. For example, how do you get the average person to comply with corporate or regulatory directives, when they impose extra work on top of the work they're already doing? How different is the collaboration between people within the same organization, as opposed to collaboration across organizational boundaries?

Watching the Google Wave demo, therefore, was almost a nostalgic moment for me. Oh my stars, I remember the days when the collaboration technology was new, and the use cases were vague to the point of being practically nonexistent. We got by with nothing but gumption and a compiler.

As impressive as the technology is, the use case is where projects like these get lost in a jungle of possibilities. Or, at least, one part of them, the application, faces this risk.

There are just too damn many use cases in the collaboration and content management space for it to be practical to cover all of them in a single application. Focus is essential, particularly at the beginning of the design process. Sure, being able to re-purpose your photo gallery in your blog looks neat, but does this represent any business problem that needs to be solved? You could ask the same question of the "everyone sees the edits in real time" functionality: Do people really want to work that way? Maybe some people do--say, legislative aides drafting a bill--but is that the audience you really want?

The funny thing is, Google already has a very popular collaborative document editing solution. A lot of people enjoy editing a document in Google Apps, and then sending the link via Gmail. This combo is good for a particular market, which may be the same one for which Wave is designed.

Still, Google doesn't necessarily have to design the killer app for Wave to be successful. The APIs and moving parts beneath it may be attractive to other ISVs, who then build better applications than Google's. What Rasmussen, Hannon, and Rasmussen demoed might never need to go beyond being the proof of concept for the underlying platform.

However, it's important to remember how much the application drives the API. If you want to build an application that will excel at handling compliance use cases, you'd better make damn sure that the objects and methods give developers credible ways to build auditing and security features. On the other hand, if you want to support self-organizing project teams, you'll stress things like workgroup administration and content state (draft, review, completed, etc.).

Therefore, Google can't be completely indifferent to the applications it wants to support on the Wave platform. Strategic technology decisions during the early stages dictate how far collaboration technology can go, and in which directions.

Iran's regime believes in anti-social media

Iranian protesters are using many different Web 2.0 technologies to inform the rest of the world apprised of what's happening in Iran, as well as communicating with each other. However, Twitter seems to have grabbed the lion's share of press attention. Let's not forget what Facebook, YouTube, blogging sites, and other services are doing to keep the channels of communication open.

By the way, in one company where I worked recently, Iranian opposition groups used our service to organize and communicate. Their use of Web 2.0 technology goes back years.

Coolest technology of the day

Researchers are working on "programmable matter," material that can shape itself into whatever tool you need at the moment.

Agile Executive post on "regime change"

Many thanks to Israel Gat at The Agile Executive for posting my thoughts on how Agile is following the same path that many revolutions take. After you've had some initial successes, and take your new programme seriously, what now?

SaaS backwards

The arguments over SaaS University's "SaaS companies don't need product management" post continues. The original author,  has taken the comments seriously enough to answer them, often at length. Unfortunately, he's not helping himself in the process.

Brevity is the soul of wit
To his credit, Chapman has disentangled the issue of product management training from the value of product management:

I'll break this into two parts. First, I think for a SaaS company, all the current product management courses are mainly irrelevant and you should save your money. In next week's post, I'll describe where I think PM is going. I do think that SaaS will greatly change the role and scope of what PMs do, and I wonder if the title will exist in the near future.

I've certainly been guilty of trying to cram too many points into one big blog post. (Watch me give into that temptation again in this post.)

Having addressed the confusion, Chapman should have stopped there, and told people to wait a short interval for his next post. Instead, he started to make his argument in bits and pieces through the comments section. Neither the bits nor the whole picture are very convincing.

Is that really Agile?
It was inevitable that Agile would enter the picture at some point in this discussion, particularly given the close linkages between Agile and SaaS. Unfortunately, in trying to use Agile to prove his point, Chapman instead highlights the gaps in his understanding of Agile. Here's a prime example:

But Agile was never intended for PMs. It was intended for DEVELOPMENT groups to better communicate with users/customers! If you can learn and communiciate directly with the community, what value does the PM bring to the process?

The rebuttal to this vulgarized version of Agile was sitting within arms reach, and took me only a couple of minutes to look up. Jim Highsmith, one of the authors of the Agile Manifesto, has a lot to say about product management's role. In the section of Agile Project Management in which he paints a favorable picture of feature-based development, Highsmith says:

Using this style of planning, product managers control which features are included in the product. Development engineers control how features are designed and implemented. Product managers wouldn't have the authority to say, for example, "We're running behind, let's cut testing time." Instead, they could only say, "We're running behind; let's cut featurs 34 and 68." Similarly, the development team couldn't arbitrarily add a feature because "it would be way cool." Obviously this delegation of responsibilities undergoes discussion and debate, as product managers may have suggestions about (but not final authority over) how products get built, and development engineers may make suggestions (but not decisions) about potential features

Clearly, Highsmith sees PM as the prime authority on the business value of the features themselves. (See below for a few words on that business value.) Product managers appear thoughout Highsmith's book.

The Framers of Agile didn't set down a formula for defining the relationship between the product owner and the product manager. In practice, approaches vary widely; in many cases, the product manager is the product owner. However, even if you overlooked how Agile teams actually work, it's pretty clear that Agile theorists vested some PM-ish responsibilities in the product owner role.

For example, Ken Schwaber, in Agile Project Management With Scrum, says that the product owner, among other responsibilities, creates "the project's initial overall requirements, return on investment (ROI) objectives, and release plans." If weighing business goals against the feature list, both of which the product owner owns, isn't a PM function, what is?

I'll be anything you want me to be
Chapman's argument seems to be based on the assumption that, if your customers want you to build a feature, that feature will have business value for you. (Therefore, you can automate the process of selecting them, eliminating the PM as "middleman.") That reductionist formula is flatly wrong.

I covered a lot of the reasons why in my earlier post. I'll add one more critical point here: Customer demand is not the only criterion for building a feature. It seems a bit ridiculous to have to say that, but it's apparently necessary, in this case.

Giving customers the features they want is not an end in itself. By meeting demand, you hope for something to happen. More people may buy your product, and you may retain more customers. These are business goals that enhancement requests are supposed to help achieve.

And these definitely are not the only goals. A new feature may sharpen the contrast with a competitor. Your current customers might not be asking for the feature, but it might be critical for entry into a new market.  You might build the feature just to look like a cool company brimming with good ideas. None of these goals would be attainable if all you did was put product decision-making on autopilot, the way that Chapman advocates.

These aren't the developers you're looking for
The really weird thing about Chapman's proposed strategy is, I can't imagine any development group agreeing to it. The difficulty of building a feature has no relationship to demand for it. Release planning, therefore, is a negotiation. How can we meet the objectives of the release without pushing out the schedule too far? Or introducing too much complexity or instability in the product? Or creating long-term maintenance headaches?

On the other side of the scale from development costs, of course, are the business benefits. To find the right balance, product teams examine different scenarios, argues their pros and cons, and makes a strategic bet on whichever set of features make the most sense.

These discussions feed on information. Some of it comes from the outside world, and go beyond just how many users have voted on a feature. (See the previous post for examples.) Some of the relevant information comes from within the company, such as the development risks, or how various corporate goals affect product decision-making.

It's difficult to imagine developers embracing Chapman's "robo-PM" strategy, which effectively eliminates a lot of the data needed to mitigate risks. Companies reward developers for executing, executing, executing, not mumbling excuses for why they designed a feature the wrong way, or misinterpreted what customers really wanted.

Playing "Telephone" with your customers
Chapman has an almost child-like faith in the literal truth of what customers say:

Again, consider an environment where you have developed a strong SaaS customer community. You don't need a PM to "sense" the market; you can sense it directly. Your community will be quite happy to tell you about its problems. And I believe THEY'LL be driving prioritization! Why do you need a keeper of a tick list when your community can tell you what it wants and what it's doing in near real time.

If, through some electronic medium, you listen to customers propose features, comment on them, and vote for them, you are not engaging in a Vulcan mind-meld with them. You're getting very valuable information, but it's the same species of raw data that leads superpowers to invade countries they don't really understand.

Customers can be unclear. They may have ulterior motives that shape their enhancement requests. They might be talking about an imagined implementation of a feature, instead of explaining the actual need for the feature. Interpreting the information is critical, and it takes effort, maturity, experience, judgment, and imagination.

By the way, you're hearing why the "social media as a resource for product requirements" study I wrote turned into three separate documents. Alas, if only product decision-making were so simple that you could subscribe to some RSS feeds, set up some polls, and wait for further instructions.

Yer bein' too uppity fer yer own good
What's very clear from Chapman's responses is that he doesn't have a very high opinion of the value that PMs can provide:

Hakan, PMs are not upper management; let's keep that in mind. All responsibility; no authority; that's the traditional PM laments, and it's a middle manager's mantra.

+++ Latent markets not using your product, new segments, new verticals, business unit strategy, collaboration and communication with different stakeholders within a company, and many other areas needs someone to take the reigns and own. +++

But PMs don't do that. PM's are middle managers. PMs are almost never hired when a company is young; PMs are brought in after a company has reached a certain level of maturity. Vision is usually owned by the company founder. Collaboration? Can't the community collaborate? BU strategy? Owned by the BU head? (Not a PM.) Strategy? The job of the CEO, no? New verticals.

Chapman is talking about a stereotype that may be prevalent in many companies, but is no more accurate than Charlie Chan was a fair depiction of Chinese-Americans.  In fact, in many companies, PMs are not middle managers. They have both responsibility and authority. One Vice President of PM I recently interviewed told his peers in Sales and Marketing, "If I do my job right, I'll help you cut down the sales cycle and increase the revenue per purchase." And that's exactly what happened.

In fact, PM is becoming more strategic, not less. An increasing number of PMs report directly to the CEO, instead of being subordinate to Development or Marketing. They may not set grand strategy, at a corporate level, but they do set product strategy, and in many cases, market strategy (i.e., which markets or solution areas to pursue).

It's hard to argue with a stereotype, because it's usually deeply ingrained in how people see the world. All I can do is offer the data from our research into product management and product marketing, and cross my fingers that the stereotype collapses.

What is a browser?

Watching this short video in which average people answer questions like, "What is a browser?" and "What's the difference between a browser and a search engine?"

 

 

There's nothing condescending about the video. Instead, it seems like a needed reminder, to people in the technology industry, that what matters to most people about technology is how it helps them, not how it works.

[Thanks to Greg Ritter for the pointer.]

HTML 5 vs. Flash and Silverlight...Fight!

In case you haven't been following it, the new HTML 5 standard aims to replace some of the "rich" Web application functionality of Flash and Silverlight. Hmmm, this promises to be an interesting match-up. Flash is, of course, extremely well-established, and Microsoft is putting a lot of its considerable weight behind Silverlight. And IE is critical to the success of Microsoft's Azure platform.

Even if the HTML 5 standard propogates among Safari, Firefox, and other alternatives to Internet Explorer, the critical battleground will be IE. Microsoft might successfully ignore or downplay the new standard, if whizbang special effects were the only things in the W3C spec. However, HTML 5 also adds improvements for the performance of web applications, a benefit that's much harder for any browser developer to ignore.

Making a SaaS of yourself

A recent post at SaaS University ("Where CEOs Go For SaaS Higher Learning") argues that SaaS companies don't need product managers. Here's a quick summary of the argument.

• Product managers maintain the prioritized list of features.
• SaaS applications can ask the users to vote, within the application, on what features they want.
• Therefore, product managers aren't needed.

This argument is based on such a rich smorgasbord of fallacies that it's hard to decide where to start. I'll just elbow my way into the buffet line of bad assumptions at the point where the features are spread out on the table, waiting for people to select the juiciest among them. Here's how Rick Chapman, the author of this post, depicts the process of defining and prioritizing features:

The tick list is traditionally gathered from the product manager's imagination, development's imagination, the CEO's imagination, competitive analysis, press reviews, and, most importantly (and often only theoretically) from user requests.  It is the job of the PM to collate these new features, prioritize them, and fight (persuade) development that the PM is accurately reflecting the wishes of the customer in terms of the added functionality needed by the next version of the product.

Which begs the question, How do you figure out if you're "accurately reflecting the wishes of the customer" if everything runs on autopilot? Letting customers vote on features is important, but it's no substitute for understanding what customers really need, or who among them you should heed.

Making yourself clear
Say you propose Feature A. The one-line summary reads, "Streamline the process of imanetizing the eschaton." Now, assuming that your customers understand what the eschaton is, even if they're using it every day in your SaaS application, you're still hardly giving them enough information to know what streamlining really means. Are you proposing to cut down the number of clicks needed to get through the imanetizing process? Make it easier to learn how to use the imanetization management features in your SaaS application? Make the application run faster?

Crafting a good design
If you think that I'm being unfair by making the original feature proposal too vague, let's assume for the moment that the customers completely understand the importance of this feature. How then do you decide what the design constraints are? What might seem, to the developer writing the code, like the best eschaton-imanetizing feature ever conceived, might turn out to be baffling to the end user, or perhaps not all that helpful. Without any clear sense of the use case, the business problem, and the user, you're as likely to make bad design decisions as good ones.

Listening to the right people
But let's even put that risk aside for the moment, and focus instead on the voting process. The people doing the actual eschaton imanetization might have very strong feelings about the need for streamlining it. Unfortunately, these users may also have no impact on the business success of your SaaS application. For every 10 end users, there may be 1 manager that wants a new report instead of the streamlined imanetization. The manager may be the one who makes the buying decisions, and may be royally POed if you don't give them what they want, even if they're in the minority of voters.

Going after a bigger market
And what about market development? Our hypothetical SaaS vendor has already attracted a particular kind of company--say, medium-sized eschaton brokerage firms in the continental United States. But is that the ultimate market that you, the SaaS vendor, want to reach? By following the direct feedback of current customers, you may be missing the features that are important for the next market you want to enter, where neither streamlined imanetization or improved reporting may be the cost of entry.

Letting PM focus on the customers
As startlingly naive as this view of enhancement requests might be, the bigger error of this post is its conflation of bad product management with all product management. Here's how Chapman describes the role of PMs as voices of the customer:

PMs are traditionally supposed to spend a great deal of time with customers learning what they like and don't like about the product they're responsible for. The reality is that in most companies, most PMs learn a great deal about how to manage a tick list, communicate the tick list, prioritize the tick list, fight for the tick list, write the MRD, revise the MRD, examine the PRD, fight about the PRD, etc., etc. This doesn't leave much time to spend with customers.

The companies in which Chapman worked may not have granted PMs the time to research customer use cases, market characteristics, buying behaviors, and other critical topics. However, that's hardly true of all technology companies.

For example, in the soon-to-be-published Forrester Leadership Board on product management best practices, a VP of product management describes how he writes time spent with customers into every PMs quarterly goals. Other PMs I've interviewed since taking this job as an analyst have similar stories to tell. Either they have taken the initiative to protect the time needed for their research, or their management has made it a bigger priority, fearing the bad consequences of misguided product decisions. Chapman's argument smacks of, "Well, we've never given the PMs the chance to do the most important part of their jobs, so we'll just get rid of them altogether."

Understanding PM's to-do list
Maintaining the prioritized feature list is hardly the only thing PMs do. The list of tasks that PMs perform may vary across companies, but it's always a big list. Sales and marketing support, training, release management, customer reference recruitment, social media outreach, press and analyst briefings, release management--someone has to do these sorts of tasks.

I might have my disagreements with particular approaches to teaching product management. However, Pragmatic Marketing, AIPMM, et al. don't limit their description of product management to "the tick list."

Since Chapman begins his post with the statement, "If you're a SaaS company with product managers and are considering sending your PMs to one of these courses, I wouldn't bother," it makes me wonder how much he really knows about these organizations, or the curricula they present. Nevertheless, even if these outlets for PM training were to prove completely worthless, that's not the same as saying that product management is worthless, too.

[Postscript: The role of PM does change in SaaS organizations, but it hardly disappears. If you're a Forrester client, you can read the complete report on what PMs actually do in SaaS companies here.]

The Heretech podcast, episode 9: Adam Bullied

In this week's interview, Adam Bullied and I talk about product management, product strategy, and why PMs aren't mini-CEOs. Copyright (c) 2009 Tom Grant

Innovation and social media

Last week, I did a presentation that linked the recent research on inbound social media to the innovation process. Many thanks to Accept Software for inviting me. Here's the recording, and here's the written Q&A that followed.

What's the Dev team's interest in social media?

Most aficianados of social media emphasize the customer-facing applications of these technologies. By now, we've all heard interesting stories about how Marketing used blogs to get the message out, Sales used forum postings to help qualify leads, and Support used Twitter to respond to users wrestling with technical problems.

Exciting, new-frontierish stuff, to be sure, but you hear far less about Development's social media strategy. What about the "inbound" applications of social media?

That question was my inspiration for what turned into a three-part series on "inbound social media." The first research document appeared today (Forrester subscription required to read the whole enchilada). The second and third parts are coming shortly.

A lot of development teams are skeptical about their company's investment in social media. Frankly, they don't see what's in it for them. Worse, it threatens to be a distraction from their mission to execute, execute, execute.

But, as I found, social media fills an important informational gap, as long as you're willing to make the commitment to taking it seriously. You may have already heard my rants about traditional sources of product requirements, and why they stink on ice. (And believe you me, I speak from firsthand experience on that topic, as well as the vicarious experience of many PMs I've interviewed in this job.) If not, here's a sample.

The first document in this series is really a summary of why Dev teams should take social media seriously, and how they'll have to adapt to use it effectively. For example, inbound social media are a mechanism for answering questions, some of which will be ongoing, and some of which will be ad hoc. Most development teams (broadly defined to include QA, Doc, and PM) don't necessarily have the right organization and habits to juggle both of these types of inquiry. Driven by release schedules, teams focus on the questions relevant to the next release--not necessarily the bigger questions that span releases. Social media can address both kinds of questions, but teams will have to make some adjustments to find these answers.

Many technology companies will have to change the way they make product decisions. I used to annoy the heck out of stakeholders by saying, "If we've reached a question that we can settle empirically, then let's shut up and find the answer." Not everyone wants to sacrifice their dearly-held opinions, or their freedom of action within the organization, on the altar of the scientific method. But that wrenching change may be necessary for these teams to survive and prosper, given the challenges of convincing customers to buy and adopt new technologies.

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

The not-so-deep blue sea

Here's a phrase I hope never to hear again: "We don't really have any competitors."

Oh, really. I've yet to meet anyone for whom that's really true. In fact, it's almost impossible for it to be true.

You're a piece of a solution
First, let's start with the customer. (I know, I know, a few "technologists" might have a stroke if they try too hard to think about the customer instead of themselves, but it's worth taking the risk.) People have problems. Technology can help solve them.

The problems, therefore, always exist prior to the technology. Except, of course, if we're talking about a problem that technology creates. Like, say, the burden of e-mail that needs my attention before I leave the office.

Obviously, the phrase, "We don't really have any competitors," doesn't mean that you created a new problem, and then solved it. You might be trying to say that you're the only technology that addresses that problem, but that's very, very hard to believe. You might address it differently than potential competitors, or you might address a piece of the problem that other companies overlook. For example, online bill pay helps me get through the annoying but necessary task, but it doesn't necessarily remind me that I have to pay my bills.

Still, it's a very rare technology indeed that finds this naked, raw, chafing part of a problem that absolutely no one else has ever addressed. Aside from competing technologies, there are other measures I might take that have nothing to do with technology at all. Putting a sticky note on my bathroom mirror that says, "Pay your bills, dummy!" is one such measure, as is the proverbial string tied around my finger. Not everyone necessarily wants a technological alternative to these measures--but that's a much bigger topic that deserves a separate post.

Therefore, in the vast majority of cases,  the phrase, "We don't really have any competitors," is really just another way of saying, "We think that we're addressing part of a problem in a new way." While that may be a glorious accomplishment, you still have competitors. They just happen to be addressing a problem in a new way.

Not every problem will be solved
Even when the new approach is clearly better than the old one, the market isn't necessarily going to embrace it right away. It may not ever embrace it completely.

Here's an example. Given its superiority as a way to get from point A to point B on a daily basis, the automobile enjoyed quick, explosive adoption. In the United States, cars-to-people ration increased from roughly 0.1 in 1920 to 0.3 in 1930. Gas-powered vehicles became an increasing part of everyday life, from farming to waging war. In fact, the whole face of modern warfare changed, not just with the tank, but with the advent of "mechanized" or "motorized" infantry--soldiers moved around the battlefield on trucks and half-tracks.

You might be surprised to hear, therefore, that the armies that fought WWII were not fully "motorized." When Germany invaded the Soviet Union, most German soldiers traveled on foot, or by horse-drawn wagon. Great Britain had the only fully motorized or mechanized army. Not even the car-happy Americans had reached "100% market saturation" in the adoption of motor vehicles for the military.

Therefore, even if there are no other companies that address the same part of a problem that you do, or even helps with the problem at all, you're still effectively competing with "No decision" and "No project" in the win/loss picture. If there's a void, you will not automatically fill it. Any business projections based on the "nature abhors a vacuum" logic is going to be a source of crushing disappointment.

So, please, don't ever tell me that you have no competition.

[My inspiration for this post was this excellent review of Blue Ocean Strategy. Many thanks to Christopher Cummings for the link.]

These aren't the sales droids you're looking for

I especially enjoyed this post at The Cranky Product Manager, having experienced a similar bait-and-switch with Sales in a previous job. Plus, the description of the CEO is hilarious:

So, the CEO calls the Cranky Product Manager into his office.  After complimenting her hair and the way her jeans fit, asking her if she is still happily married, and trying to give her a George-W-style shoulder rub,  The Big Boss tells her to drop the price to the one the Droids are begging for.

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

So you want to start a revolution

There's a faction in the technology industry that has a very high opinion of what CRM can do, or what it will do, once it goes through The Next Major Transformation That's Just About To Happen!!! My own belief in a CRM revolution makes me more of an optimistic pragmatist like Thomas Jefferson or James Madison, and less of a impatient radical like Danton and Robespierre.

We're certainly seeing how many organizations are making big changes to their business practices. The CRM system helps  organize and communicate information about customers, as well as routinize the activity of customer-facing groups. The CRM system is also a resource for making product decisions, though companies have been slow to use their CRM data in that fashion. If I were to bet on any repository of data within an organization that's going to become more central to a company's strategy and operations, I'd vote for the CRM system.

But how far will this revolution in customer relationship management go? And will other market forces, such as the proliferation of social media, accelerate this trend further?

For part of the answer, look no further than your local Safeway.

Well, you know, we all want to change the world
There's a Safeway close to the Forrester office in Northern California, so I'm a frequent customer there, particularly around the lunch hour. Although I haven't posted my actual picture anywhere in this blog, you can take my word for the fact that I am not physically or mentally incapacitated. I can pick up a heavy box of books and carry them into the garage with little effort. Few jars have ever been able to resist my impressive upper body strength. If you're curious about my ability to get around on my own power, here's a fact: during vacations, I usually spend my days on my feet, hoping to squeeze in as many different sights as I can in a limited amount of time.

Nevertheless, every time I make a purchase at Safeway, the clerk asks me the same question: "Would you like help carrying that out?" I could have purchased only a single tube of toothpaste and a bunch of bananas, and I get the same question.

Clearly, the management of Safeway has made this question mandatory for their clerks, no matter how ridiculously inappropriate it may be. I suspect there's a great deal of pressure on the clerks to ask this inane question, given how seriously they treat it. I've tried making a joke of it with them--usually something like, "God, I hope not!"--but their faces remain as immutable as the Easter Island moa.

If the revolution in customer relationship management is all about sensitivity to particular consumers, then we see evidence every day that the revolution may not be as widespread or complete as some might believe. About the only thing that's personalized about my shopping experience at Safeway is, after swiping my Club Card, the clerk says, "Thank you very much, Mr. Grant." Which, of course, is right before they ask, "Do you need help out with that?"

You know we all want to change your head
Revolutions rarely achieve the goals of their most zealous adherents. The tools of revolution, from the Declaration of Independence to the guillotine, can inspire people to behave differently, and which can lead to organizational changes. (Or, it might work the other way around, changing the organization first, and then the behavior.)

The tools of revolution can't change everything overnight, and may not be able to overcome some ways in which human beings think and act. For example, no investment in a CRM system will change how the decision-maker behind Safeway's "Do you need help out with that?" policy uses the data, or even looks at it at all.

If you read some of the most quotable quotes from Maximilian Robespierre, you'd be surprised that they came out of the mouth of someone directly responsible for one of history's greatest bloodbaths. Who can argue with a statement like, "Any law which violates the inalienable rights of man is essentially unjust and tyrannical"?

Well, you know, we'd all like to see the plan
The frustration with the slow pace of achieving these ideals is one of the major reasons why revolutions often turn nasty. The French revolutionaries experimented with a lot of policies, such as changing the calendar to make the current date the "Year Zero," to reach a more just society as quickly as possible. When none of these measures worked, many supported the Terror as a way to get rid of the people who stood in the way of revolutionary change. (If you can't make people better, you can get rid of them.)

The CRM "revolution," if it's indeed happening, is definitely aiming for the right goals. Improvements in CRM technology, as well as adjacent technologies like social media, are going to contribute to that change. However, the revolution won't really happen until people change their attitudes, behavior, SOPs, and other human factors that determine how organizations relate to their customers.

Meanwhile, the revolution is likely to start with more prosaic changes, like getting rid of the duplicates and out-of-date information in the CRM system, or getting more people to stop what they're doing long enough to enter information into the CRM system. These improvements may inspire people to think more ambitiously about CRM, and more ambitious expectations of CRM might make these projects more of a priority.

In both cases, you can't avoid dealing with the mundane issues that stand in the way of revolutionary changes. (Do you invite friends over to inspire you to clean up the house, or do you clean up the house and then feel inspired to invite friends over? Either way, you need to clean up the house.) If you try to ignore them, you're only setting yourself up for disappointment and cynicism.

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.