The Heretech

The iPad business model

Now that we've all had a few days to ponder Apple's iPad announcement, what are we to make of it? A revolutionary change in the computing industry? More of the same Apple technology, repackaged? A shot in the arm for the publishing industry? A new way for corporations to restrict the free flow of ideas?

Apple's announcement inspired all these reactions, and more. It's clear that the iPad strikes a nerve—several, actually. And that's what makes commentary on the iPad difficult: we're having several conversations simultaneously, sometimes confusing what we wish the iPad to be with what it is (or will be).

It's the business plan, stupid
Obviously, the iPad continues what Apple started with the iPod and iTunes, a combination that defines Apple's real market differentiation. As my colleague Tim Harmon rightly observes, tech companies now compete over their business models more than their technology (or the coolness of their physical design). Other companies developed MP3 players before Apple. What set the iPod apart from the competition was iTunes. Not only did you transfer your music library from your CD collection, but you could buy new music through the iTunes store. 

That's what makes discussions about the competing features of the iPad versus other e-Readers moot. Sure, it's annoying that the iPad won't have a USB port, but in many respects, the iPod wasn't necessarily the best MP3 player on the market. (And, as a player and organizer, iTunes is far from the best of all possible worlds.) The important question is, will consumers want the whole enchilada, buying the content through Apple's store, and then reading it on Apple's device?

At the initial price, the number of early adopters will be limited. As the price drops, however, we'll see whether Apple faces other barriers to adoption.

The difference between movies and books
All media are not alike. For example, there's the question of privacy. Apple keeps information about what music you like, so that it can make friendly suggestions about what else you might buy. But how do you feel about Apple keeping tabs on what you read? (To be fair, this concern already exists with other e-readers.)

Reactions vary when different types of content are unavailable. If you can't buy a particular album through the iTunes store, the consequences are minor. If books you need for your work, or your education, or other important tasks are not available through Apple, and it's difficult to get them into the iPad through other means, how attractive will the iPad appear then?

The difference between tablets and PCs
Jobs took a swipe at netbooks at the beginning of his launch presentation. Unfortunately, the comparison isn't perfect. While the iPad might be a better e-reader, netbooks do a much better job at other tasks. Would you rather take notes during a meeting using a netbook's physical keyboard, or the iPad's virtual equivalent?

Near the end of Jobs' demo, I started to wonder about some of the pre-packaged apps he was touting, such as the address book and calendar. Sure, I don't mind seeing my appointments on this device, but the iPad won't be where I do my work. I may not even bother to sync my appointments with yet another device, if I'm already going to look at my laptop anyway. Chalk up these sorts of details to the compulsion for feature completeness that's an unspoken assumption of many keynote demos.

The difference between appliances and tools
I share the frustration many people have with how much fussing around any laptop or desktop computer requires. Constant updates, complex interactions among components from different vendors, problems that are difficult to diagnose--computers are definitely not appliances. If there's a device that handles many of the same tasks, without these headaches, many consumers might buy an iPad for that benefit alone.

However, there's a reason why we live with the twitchy unpredictability of laptops and desktops: some capabilities are impossible without this kind of technology. If you want choices among productivity applications, video editing tools, games, and other kinds of applications, Apple's business model may not provide this range of choices. Certainly, many of these applications have technical requirements that won't squeeze into the constraints of the iPad.

As long as we applaud fast innovation and broad capabilities in the electronic place where we work and play, we're effectively asking for computers to be toolkits, not appliances. We want to be able to swap hardware in and out, at the same time that we're adding and updating software. The more the moving parts change, the greater risk that the overall machine will break down. Unfortunately, that introduces unexpected incompatibilities, security issues, performance bottlenecks, and other problems.

It doesn't have to be revolutionary to be good
As someone who bemoans the lack of good e-reader options, I'm certainly interested in the iPad. The device definitely has value, and it doesn't have to rock my world to provide it. The business model doesn't have to be "disruptive" to succeed. And we might not want some of the disruptions.

We've heard some very thoughtful responses to Apple's announcement, and some silly ones. (Topping the list: the claim that the iPad's resistance to hacking is a critical problem for its popularity.) The most useful observations have focused on the experience of using the iPad—finding, acquiring, and consuming content through this new device. That experience is the end product of Apple's business model as much as it depends on the device itself.

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

I miss newspapers

While I was staying at a hotel over the holidays, I had the unusual experience of reading a newspaper. I normally read all my news on my laptop, along with feeds from blogs, forums, and other sources of content. And boy, it felt nice to read a newspaper again.

It's not that I have some weird nostalgia for getting newsprint on my fingers again, or some quixotic desire to help save major newspapers from impending doom (brought on themselves, to a great degree). Here's what I liked about the newspaper:

• Encapsulation. Printed publications create boundaries of content. In this issue, you will read the following stories, and then you're done. In contrast, my normal way of reading the news is boundless. There's always one more news item that I could read, which might actually lead me, in some topic areas, to read fewer news items, instead of more of them. If there's always a huge number of things I might read, the sense of completeness in reading a day's news items could end at any time.
• Prioritization. You might argue with the primacy that newspapers grant some stories by putting them on the front page, but at least there's some prioritization. The "dump all the news stories on a floor and find what you like" approach, as exemplified by sites like Salon.com, create a sense that nothing is more important than anything else. My own sense of what's important won't change, but the publisher's certainly does. If it's worth putting on the front page, it's worth doing a little more fact checking, and adding a little more content than you might not afford in a lesser story.
• Presentation. I get tired of looking at the same laptop screen all day. I want something that isn't backlight, requires a power supply, and can present something that looks like the average size of a book page. Again, it's not a question of nostalgia for printed things, but simple efficiency. I don't like having to click Page Down too often.

Having said all that, you might think that I've already bought an e-reader like the Kindle. Nope, haven't taken the plunge yet. I share some of the same anxieties that Farhad Manjoo discussed in Slate, such as high price and freaky DRM rules. If it's not as functional a netbook, I don't want to pay more than the cost of a netbook. I just want something that I can load up with a permanent collection of PDFs and downloaded feed items and read on the couch, or in a hammock, or on a plane.

All of which presents an interesting challenge to product managers and product marketers working on e-reader technology. The people designing and marketing MP3 players had a relatively easier time, since the use case they created was nothing like past alternatives. Not only would your shelves of CDs disappear, but you could listen to your entire library anywhere you went, using a device that you could slip into your pocket.

The e-reader use case is a little more familiar. You can't bring your high-end stereo system on the subway, but you can still bring a book or newspaper. The file format for music files is a non-issue for users, but e-readers are forcing consumers to make bets on which e-book format will persist and which will die.

For the moment, e-readers face serious adoption challenges. Overcoming them will be one of the most challenging tests of ingenuity for PMs in the tech industry.

Upgrading customizations, by the numbers

Here's a common conversation in the tech industry:

Customer: We'd really like a fix for this issue.

Vendor: We've fixed the problem in version 11.0.8.7. If you upgrade, your issue will disappear.

Customer: Um, maybe you're not aware of how big a deal an upgrade can be.  We have customizations, and it takes time to upgrade them, not to mention the infrastructure components that need to be upgraded and tested...

Vendor: Not to worry! In a few weeks, we'll be releasing version 11.0.8.8 SDK, which will include productized versions of some of the functionality that your customizations provide. You won't need to maintain these extra bits of code!

Customer: Really? I can quote you on that?

Vendor: Sure. As long as you read the small print absolving us of any responsibility for functionality we don't deliver.

Customer: What did you say?

A recent CIO Magazine article on the difficulties of ERP implementations got me thinking about this issue. One of the chief villains in this story, according to the CIO Magazine writer, is customizations. Upgrade the system, and you also need to upgrade the customizations. In a system as complex as an ERP system, upgrading the customizations never goes smoothly.

So who's really to blame here? Do we point the finger at the vendors, who make products that require customizations in the first place, and who don't prioritize the feature Make upgrades easier highly enough? Or are the customers paying for their laissez faire attitudes towards customizations, some of which may not have been strictly necessary?

To do a decent job of answering these questions, real research is necessary. Meanwhile, we can do some informed speculation. Even if the overall calculation can't be accurate, even a back-of-the-envelope estimation might reveal which aspects of the upgrade process matter the most. And by matter, I mean, will cost the customer time and effort during the upgrade. Identify the critical factors, and you also can tell who bears the greatest responsibility for whatever problems exist.

As with any such exercise, there are plenty of variables that you might consider, but only a few you can consider. We're only making a rough guess at something, so complexity, beyond a certain point, doesn't add anything. We want to arrive in the neighborhood of the truth, not build something so complicated that it never gets out of the garage.

Here's the list of variables I used for my own seat-of-the-pants calculation. Again, we're only considering the customizations, not all the other aspects of the upgrade:

• Number of existing customizations. This variable represents the customizations that the customer had the opportunity to discuss with the vendor.
• Number of new customizations. To be fair to the vendor, we have to acknowledge that customers are always thinking up new customizations. To be fair to the customer, the world changes (new business processes, new technology components that must be integrated, etc.), which compel them to write new customizations. Even if, during their last meeting, the vendor acquired perfect knowledge of the customer's set of customizations, that set is likely to have grown since their last conversation.
• Average time, per customization, to upgrade. I haven't decided to count customizations by feature points, function points, story points, or something else. I just know that points are involved.
• New functionality in the next release that replaces some fraction of the customer's existing customizations.
• Risk that the vendor will not deliver this new functionality (customization relief?) in the next release.
• Additional functionality in the next release that does not make customizations obsolete, but which do add overhead to the customization. The "You didn't ask us for it, but here it is" problem is commonplace in the tech industry.
• Average ease of upgrade, per customization.
• Average time, per customization, to handle additional overhead (change management stuff, such as training). This variable applies to all new visible functionality, whether the customer asked for it, or not.

Plugging some sample numbers, representing a fictional ERP implementation, into the calculation gave me a baseline. From there, I started cutting each value (number of customizations, difficulty of upgrading, etc.) in half, just to see what would be the effect of simplifying each element.

At this point, if I haven't said it enough, I'm just thinking aloud, so for God's sake, don't quote me. However, it seems as though the variables that matter most include:

• Average time per customization to upgrade. While customers might get better at doing customizations, vendors can invest in ways to simplify them. (If you've ever had the agonizing experience of seeing customers struggle to preserve customizations to a badly-designed web UI, you've seen at least one possible area of improvement.)
• Risk that the vendor won't deliver promised functionality that will replace customizations. Yes, customer complaints about the vendor's roadmap are justified. Vendors think in terms of releases, which are either fantastic, or slightly less fantastic than promised. Customers think in terms of projects, which will take either X weeks, if you believe everything the vendor tells you, or X plus some unknown number, if you want to look at vendor claims with a justifiably skeptical attitude.
• The number of customizations. On the other hand, it's definitely fair for vendors to push back on the number of customizations. How many of them represent something that the customer felt was important earlier, but nobody uses now? How many of them filled a genuine gap, but did so in a clunky way that's hard to maintain?

Again, real research is required to go beyond just an educated guess. Still, a little bit of math does sometimes help narrow the list of factors that probably do matter the most.

Drop the pilot?

Via Rocket Watch, do you need to pilot the roll-out of enterprise-esque, Web 2.0-ish collaboration tools? Michael Idinopulos of SocialText says no:

But social software is different from traditional IT. Traditional IT enables individuals to carry out well-defined, highly standardized transactions. Users go into the system to process transactions--to transfer funds, purchase supplies, track inventory, etc. The nature of these transactions, and the system's ability to enable them, do not vary much according to the number of people using the system. Whether 100 people are entering orders or 10,000 people are entering orders, the transactions themselves doesn't really change. What that means is that a representative small-scale sample is an accurate predictor of adoption and value at full scale.

Idinopulos starts the post by saying, "Get out your pitchforks, I'm about to commit Enterprise 2.0 heresy." If he detects the smell of torches, or the clatter of pitchforks, it's not because his argument is heretical. (As you might guess, I have a lot of sympathy for heresy.) Instead, his argument overlooks the adoption process for collaboration tools.

Idinopulos' argument breaks down at the following points:

• While "traditional IT" (ERP, etc.) focuses on transactions, social applications focus on interactions. If you have ever had to deal with a rejected expense report, or negotiated a deal with a client, or handled an internal audit, you'll quickly appreciate the lack of clear boundary between "transactions" and "interactions." In reality, work is a combination of well-defined tasks, such as closing the books on the quarterly financial statement, and the large amount of collaboration needed to get those structured activities finished.
• Collaboration is separate from "traditional IT." As the previous bullet implies, there's not a clear boundary between the two. In a business setting, people aren't collaborating for the sake of collaborating. Instead, they're trying to get work done. In a Microsoft shop, a SharePoint or Exchange administrator might not see these other activities, or the applications involved (CRM for sales, document capture for contracts, etc.). However, those files, e-mails, and other unstructured content are part of a larger business process, not the whole business process itself.
• Collaboration has no specific shape or form. "This is the way we communicate new releases to customers in this company" is one of countless examples of how institutional factors constrain activities. So, too, do individuals themselves, who have habits, preferences, past experiences, lessons learned, and a limited amount of time and patience for experimentation.
• Adoption depends on the tool. Idinopulos argues that some social applications, such as Wikis, require more up-front work to make them useful than, say, micro-blogging. However, that's hardly the only variable, and it's not necessarily the most important one. Sure, as a customer service rep, it's easy to post a thought about how to deal with difficult customers via the company's Yammer account. However, you can't put much into that thought, and certainly, for someone looking for advice, it's harder to sort through a bunch of micro-blogging posts than a well-organized Wiki. The business argument for using a collaboration tool, as either a contributor or consumer, is just as important a determinant of adoption as the difficulty of using the tool itself, or the amount of content needed to get it started.
• For a new collaboration technology to be successful, you need to start big. Idinopulos cites Metcalf's Law, which "famously states, the more people there are in that network...the more value that individual derives from participation in that network." And, Idinopulos argues, it's hard to predict from a small pilot how other individuals or groups will use the technology. Unfortunately, people are not Christmas tree lights: you don't just string all the nodes together, stand back, and say, "Ooooh, impressive." Some people may figure out the value of the tool on their own, but for those who don't, a few good business arguments and use cases discovered during the pilot can be very convincing.

The very fact that you can't always predict all the use cases for a collaboration tool is the very reason why, in many cases, you need some use case as an illustration, even if it's not your own. Collaboration tools don't manufacture use cases; they create the means to address these scenarios in new ways. For example, I'd love to stay in touch with everyone that I've ever known. LinkedIn and Facebook just make it way easier to do so.

Social networking, Wikis, blogs, forums, micro-blogging—these are great technologies to address human wants and needs in novel ways. In the workplace, the communications and activities they make possible are connected to business processes.

Of course, IT people can get in the way of projects, deciding on behalf of employees the "proper" use of collaboration tools. Of course, you can smother some projects by making them too small. You can also ensure the failure of the very same projects by making them too big, if you throw new technologies in people's faces and expect them to figure out the use cases, and work out all the kinks of your technology, on their own.

Announcing the Agile adoption survey

Hot on the heels of the requirements survey (which is still available, if you haven't participated), we've launched the Agile adoption survey. Colleague Dave West and I are looking into the state of Agile adoption, looking for answers to commonly-asked questions like...

• What aspects of Agile are getting stronger or weaker adoption?
• How important are tools, coaching, and other aids?
• How important is the flavor of Agile you select?
• What types of organizations or projects seem to have the best chances of success with Agile?

If your organization is at any point in the Agile adoption curve, from an initial evaluation to a fully mature implementation, we'd love to hear how's it going. Here's the link that will take you straight to the survey.

All responses stay strictly confidential. If you're wondering what's in it for you, we'll provide you with a copy of the research, once Dave and I have finished writing it up. And please feel free to forward the link to other people who might take the survey.

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

My brain is full. Please stop talking.

In many blogs, some of the most interesting content is in the "About Me" section. Such is the case with Cindy Alvarez's blog on PM issues.

Here's a striking quote from Cindy's account of how her background shapes her approach to product management:

I chose to major in psychology at Harvard because I was interested in the theory of multiple intelligences, which posits that intelligence consists clusters of skills that allow people to excel at certain types of tasks.

This notion, simple as it is, suggests a simple yet revolutionary rule: not every audience is alike, and the product feature set and interface need to work for the audience you have.

Cindy is making a very important observation here: you need to think about what's in the customers' brains as much as what's in their wallets.

Cognitive load is one of those aspects of human psychology and intelligence that product managers and product marketers both frequently overlook. When considering how users learn about a product, through demos, web site content, documentation, or just poking around, you need to consider the learning process as much as the product capabilities. Humans, as is true of any animal, have a finite capacity to process new information. If you try to shove too much into the brain all at once, some of the information will leak onto the floor.

Unfortunately, many people in the technology industry forget this basic limitation. Your product can do a lot, so why not tell your audience everything it can do? Presumably, you'll impress people with its vast capabilities, while at the same time making the competition look puny and weak.

Meanwhile, the people watching the demo, or clicking through the UI, don't care about everything you're telling them. Even if they did, not all of it will stick.

The cognitive load gets even heavier when you make this presentation of new information a translation exercise to boot. It's hard to learn anything in a foreign language, because your brain is processing the new information and handling the translation. Your product's impressive array of features and capabilities is a foreign language that the user, buyer, or implementer needs to learn to see how the technology can solve their problems, and how it will fit (or not) into their existing work habits.

The trick, therefore, is finding the right economy of product information. If you don't know your customers well enough so that you can prune the information you present down to their essentials, best of luck to you in your business. You'll probably need it if your competition does a better job of communicating within the constraints of cognitive load better than you do.

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