« August 2009 | Main | October 2009 »
Posted at 04:40 PM in Podcast, This blog | Permalink | Comments (2) | TrackBack (0)
Posted at 12:37 PM in Podcast | Permalink | Comments (2) | TrackBack (0)
Posted at 10:23 AM in Product management, SaaS | Permalink | Comments (0) | TrackBack (0)
Whether you prefer to call them private security firms or just plain old mercenaries, these companiesdo a terrible job at naming themselves. The connotation of Custer Battles is obviously awful. But how about Triple Canopy, a phrase that gained currency in the 1960s to describe the jungle landscape of South Vietnam? (Now that sets off a train of associations you don't want to follow: Vietnam, quagmire...) Or the new name for Blackwater, Xe, which sounds like our new alien overlord?
While I don't have a lot of sympathy for these particular companies when they choose stupid names, I do feel for tech vendors that seize on unintentionally silly or embarrassing names for their companies or products. Here are a few examples:
While these names are funny, they're also sad. People stake their careers on catchy branding, or they sink their life's savings into a business venture. And then, someone points out that your life's work is named Phartronics.
The moral of the story is, the technology business is like any business. The problem isn't that some people are so stupid that they should not be given naming authority, but that, unchecked we all have the capacity for stupidity. We all have our blind spots, and we all commit the occasional brain fart.
Pack a bunch of very smart people into a room, and they'll come up with something—a company name, a new product, the next market to pursue—that makes complete sense to them. However great that Big Idea seems, someone needs to do a reality check before committing a very costly mistake.
Posted at 05:47 PM in Product management, Product marketing | Permalink | Comments (0) | TrackBack (0)
A hilarious take on designing technology to meet your customer's expected use case. Or not.
Posted at 11:46 AM in Product design, Use cases | Permalink | Comments (0) | TrackBack (0)
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 here, 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.
Posted at 01:11 PM in Innovation, Product management, Social media | Permalink | Comments (8) | TrackBack (0)
Posted at 07:57 PM in Podcast | Permalink | Comments (1) | TrackBack (0)
Forrester colleague Oliver Young left last week to join Jive as a product manager. Oliver is a big music fan with eclectic tastes, so I thought I'd put together, in his honor, the product management/marketing playlist. If you were to make a musical version of what it's like to be a tech PM, here's what you'd put into the soundtrack. (Suggestions for additions welcome.)
Why these songs?
[Cross-posted at The Forrester product management blog.]
Posted at 11:46 AM in Product management, Product marketing | Permalink | Comments (0) | TrackBack (0)
Apparently, you can rely too much on social media to communicate:
Two girls aged ten and 12 who were trapped in a storm drain used Facebook to get help instead of calling the emergency services.
Posted at 02:04 PM in Social media | Permalink | Comments (1) | TrackBack (0)
That's essentially the argument that Jeff Walsh makes:
For the marketplace's sake, Windows 7 needs to be a success. However, even a sluggishly performing Windows 7 spells trouble for the PC market and, potentially, could mark the end of the conventional PC buy/spend cycle.
On the other hand, maybe it's a bad idea for the market to depend on Microsoft's latest OS to have the same effect on PC sales that the December holiday season has on retail sales. It'd be nice if the sale of new hardware didn't depend on the release status of one operating system.
Additionally, we have to take other factors into account, when defining expectations for new PC sales. During the our recent economic troubles, hardware sales took a bigger hit than software sales. It'd be a wee bit unfair to place all the burden of desktop and laptop market health on the release of Windows 7.
The good news is, there's still a market for new hardware, and fortunately, it has nothing to do with Windows 7. I'm speaking, of course, about netbooks, which have succeeded because they didn't get sucked into the maelstrom of Microsoft's Vista woes. I'm sure that lesson isn't lost at Dell, HP, and other PC manufacturers.
Posted at 02:18 PM in Microsoft | Permalink | Comments (0) | TrackBack (0)
While other Forrester analysts will pronounce judgment on Adobe's acquisition of Omniture, I'll give a quick bit of perspective from the Technology Industry (TI) Client Group's side of Forrester. From this angle, the acquisition is a very interesting case study in how a company that has mastered working with a very technical audience feels the need to address the needs of business users, too, in their product portfolio.
Adobe has done a great job of addressing the needs of their two core audiences, graphic designers and web developers/web designers. These two groups are technical in different ways. Photoshop and Illustrator are highly specialized tools for people with highly specialized tools. "The suits" might approve their work, but they're not deeply involved in it.
Web developers—the target audience for Dreamweaver, ColdFusion, Flex, and the like—are technical professionals of a different sort. However, their work isn't nearly as divorced from business users as the graphic arts people. The web site is where marketers launch campaigns, track visitors, and re-purpose the same content for different contexts (languages, regions, media, etc.). This crowd might not even be able to spell PHP, but they're keenly interested in what happens within the edifice that the web developers build.
That's why it seems, at first glance, that Adobe's acquisition of Omniture makes sense. Their existing tools addressed only part of the business processes that centered on the web site, and only some of the people whose job depends on the success of the site. To the degree that, at a business level, a combined Adobe/Omniture offering addresses both groups is a good thing, even if the products aren't integrated any time soon (or ever).
The real challenge for Adobe may not be the product strategy. Instead, Adobe's marketing and sales will need to begin working more closely with a different audience than the people you find on the Slashdot forums. Arguably, the business types were already in the background. Even the most propeller-headed Flash developers didn't live in a vacuum, completely isolated from the business concerns that defined their projects, and decided how the company should invest in the web developer team.
At this moment, some companies realize the extremely high value of the domain expertise that comes with the acquisition. Other companies watch helplessly, or indifferently, as the people who really understand their customers and partners wander off to find jobs elsewhere.
Omniture's business depended on both the technical types who knew how to implement tools like web analytics, and the business people who consumed them. The biggest rewards from this acquisition depend on plugging into the bigger community of people who work on the web site than just the technical professionals.
[Cross-posted at The Forrester product management blog.]
Posted at 04:54 PM in Adobe, Technology industry | Permalink | Comments (0) | TrackBack (0)
Two of my research documents just went live on the Forrester web site:
Wargaming for business leaders. Not the same as the kind of serious gaming that colleague TJ Keitt and I have discussed before, wargames are a more structured exercise that try to simulate possible business outcomes. The output is different than serious games, role-playing exercises, and other game-like tools. For example, in many cases, the goal is to help make smarter company-level decisions, not just product-level ones.
Posted at 04:19 PM in Games, Product management, Product marketing | Permalink | Comments (1) | TrackBack (0)
One of the more knuckleheaded beliefs within many technology companies concerns import/export. Of course, every vendor wants to import data into their systems. But export...Not so much.
The assumption, of course, is that the only reason you export data is to abandon the system. However, it's easy to think of many use cases that depend on export. Here are a few examples:
And so on. We run into other kinds of export operations all the time, without blinking. Every requirements application, for example, has some mechanism for exporting content into PDF, Word, Excel, or other format familiar to particular audiences, such as stakeholders reviewing the list of features proposed for the next product release. Export-as-XML is a mechanism that serves many use cases, of which abandoning the system is just one.
Therefore, Google's announcement that it has prioritized development of export features for its application makes good sense. It may be a sign of confidence, and it may be a trust-building measure, as this InfoWorld article states. At the same time, it's also a necessity for the real-world requirements of many solutions.
Posted at 12:46 PM in Google, Product strategy, Use cases | Permalink | Comments (4) | TrackBack (0)
This week, Steven Haines, author of The Product Manager's Desk Reference, discusses the growth of PM as a profession, and the harmonic convergence that led him to found Sequent Learning. Plus, if you don't know who Karl Popper is, maybe you're in the wrong job. (c) 2009 Tom Grant
Posted at 11:10 PM in Podcast | Permalink | Comments (1) | TrackBack (0)
I really like following the evolving product offerings from companies like Zoho and Box.net. Since they're small, SaaS companies that are solely in the business of collaboration, customers reward them directly for making products that fit the way people work with unstructured data. Rather than just try to replicate the features of Microsoft Office, the way that OpenOffice did, the Zohos and Box.nets of this market start with basic use cases, and think about what's important to add.
Box.net's iPhone support is another case in point. Given the popularity of the iPhone, Box.net might have created a check box feature of limited usefulness, beyond marketing. Or they might have put some real effort in a feature, only to design something that doesn't reflect how people want to work with their files and folders through a smartphone. Beginning with the API is a good first step. Not only do you give your partner a way of adding value, but it gives you time to figure out exactly what the right use case is. It's there, somewhere, but you might rush into development, only to get the killer feature of your killer app wrong.
Posted at 03:10 PM in Collaboration, Product strategy, Requirements | Permalink | Comments (2) | TrackBack (0)
It's bad enough that some upgrades from Windows XP to Windows 7 can take almost a full day. What's worse is how Microsoft tries to fudge the problem, claiming that only "super-users" will face this new education in the virtue of patience.
A "super-user," in their definition, has 650 GB of data and 40 applications. Now, take a look at your system and ask yourself, Are you a super-user? If you like music, you probably have 60-80 GB of music already stored on your hard drive. Install Microsoft Office 2007? You've probably consumed another 60 GB minimum of Microsoft's own applications. Take many pictures? If so, you're eating up a lot of additional hard disk space every month.
In other words, it's easy for the average consumer to approach 650 GB rather quickly. Computer games are notorious space hogs: World of Warcraft, for example, requires several gigs of space, just by itself.
And 40 applications? If you add up productivity tools, browsers, photo editors, the printer applications that companies like HP want you to install when you buy their equipment, video editors, desktop security applications, archiving tools, and other utilities, you're going to approach the super-user threshold for installed applications, too.
In the drive to get Windows 7 out, and restore its reputation in the process, Microsoft may not have prioritized installation and upgrade. Unfortunately, as user experience pros will tell you, those two processes define the first experience users have with a new operating system.
Last week, in the podcast, I gave a favorable review to Luke Hohmann's book, Beyond Software Architecture, since it explained why considerations like installation and upgrade are not simply the unfortunate necessity you fit into the end of the development cycle. I wonder if Luke might add the Windows 7 upgrade to a revised edition of the book.
Posted at 02:45 PM in Microsoft, User experience | Permalink | Comments (1) | TrackBack (0)
This weekend, I saw two commercials for Google Chrome, one on regular live TV (during the bizarre Packers/Bears season opener), and the other during some Internet-based TV watching (yes, I'm one of those mutants who actually watches a fair amount of broadcast content through my browser). Clearly, Google is spending a sizable amount of money to promote the Chrome browser.
There's a temptation to leap to a conclusion that, because a company spends major coin promoting a product, it's therefore taking it seriously. (Why else would it spend money on promoting it?) However, Google takes many other products seriously, such as Google Apps and Gmail, which are pitched at a consumer audience, too.
Unlike these siblings in Google's product portfolio, Chrome is a platform, not just an application. The whole reason Google built Chrome was to run Web applications better, including, obviously, Google's own applications.
But how convincing will this advertising be? Clearly, the Thurber-esque cartoon characters in the ad won't change what IT departments put into officially approved desktop images. Corporate or government decision-making about which browser people should be using has nothing to do with cute advertising, or even Google's image as an innovator.
However, what gets included by default on the desktop is a major part of the story of how Microsoft beat Netscape. People didn't flock to Internet Explorer because it was more cool, or even more fun to use. Nor did IE win because it cleaved to standards better, or even had greater usability than Navigator. At a particular point in time, IE may have been a better browser, according to some measures (say, speed), but that's not necessarily the reason why users choose Hamburger B over Hamburger A.
Microsoft won because it got more people to use its browser. While that might sound tautological--they got more people to adopt IE by getting more people to use it--it's not. Microsoft might have found clever ways to get people to try a browser, but they don't necessarily convince someone to keep using it. Instead, Microsoft made IE appear as if it were a natural part of the desktop application experience, by being bundled with the operating system, and being the default browser for its ubiquitous Office applications.
That implies a different path to make Google Chrome a success than advertising. Still, it can't hurt to increase awareness of the Chrome option, since most people haven't heard that Google has a browser. The next step, going to the Chrome part of Google's web presence, isn't necessarily a deal-clincher. Most people aren't going to read the "Why we built it" page all the way through, let alone make it the decisive argument for switching browsers (something the average person doesn't do very often). The entries on the feature page, such as "dynamic tabs" and "simpler downloads," are a mixed bag of capabilities that the average user might find attractive, and others that the average consumer might not even understand.
Which is all a long, roundabout way of saying, if Google wants to break out of the niche of "interesting new browser option," advertising might be a sign of seriousness, but not necessarily success. There's a long way to go from 1-2% of the browser market share to IE's 78%.
Posted at 01:21 PM in Google, Product marketing | Permalink | Comments (1) | TrackBack (0)
I've been out of town for a couple of days, during which blogging and micro-blogging have been on hold. I hope to return to my blabby self tomorrow.
Posted at 04:04 PM in Off-topic | Permalink | Comments (3) | TrackBack (0)
This week, Luke Hohmann of Enthiosys tells us why people in the tech industry should take games seriously as a way of generating ideas and understanding customers. Or would you rather roll the dice and hope you're building the product that people want to use and buy? Copyright (c) 2009 Tom Grant.
Posted at 09:38 PM in Podcast | Permalink | Comments (1) | TrackBack (0)
Thoughts on Agile 2009 by Tom Grant and Dave West
Agile is dead, Long live agile.
That’s how the Agile 2009 conference in Chicago opened. In the keynote, Alistair Cockburn cleverly paraphrased Marc Antony’s funeral oration from Shakespeare’s Julius Caesar: “I come to bury Agile, not to praise him.”
A very narrow definition of Agile has passed away, to be replaced by a mature, expansive version that has now joined the mainstream of development methodologies. Agile with a capital “A,” with its vision limited to the development team, died of natural causes. Its successor still worries about build scripts, daily Scrum meetings, and IDE plug-ins, but it recognizes the sovereignty of business objectives, and governs jointly with other methodologies. While we might talk more about agile with a small “a,” the significance of this change is big.
You could see these signs of regime change throughout the conference. The program book was a heavy tome, reflecting both the size of the audience for Agile and the scope of questions that audience brought to Chicago. Instead of presentations that argued the merits of one Agile approach over another, they focused on topics such as scale, release management and executive sponsorship. Serious project management issues such as managing resources and portfolios were as popular as development processes, such as writing good stories or building a continuous integration strategy.
Clearly, the breadth and depth of topics at Agile 2009 achieved a critical
mass of energy and enthusiasm, and then some. The number of sessions was
boggling, which made the conference program was a heavy tome. The sessions we
attended were full of people asking questions, sharing experiences, and
exchanging e-mail addresses so that they could continue these conversations.
Outside the official sessions, impromptu discussion groups and project
simulations filled ever alcove, seating and table area.
As apt as the
Julius Caesar reference was, a different Shakespearean allusion might
work even better. As you might tell from our description, Agile 2009 felt like a
significant point in the history of software development, the kind of moment
that reminded us of the famous speech from Henry V (paraphrased, with
apologies to the Bard):
We few, we happy few, we band of builders:
For he today that finishes his
sprint with me,
Shall be my brother: be he ne're so Waterfall,
This day
shall improve his productivity.
And product teams elsewhere, now
a-bed,
Shall think themselves accursed they were not here;
And hold their
projects cheap, while any speaks,
That attended with us Agile 2009.
Looking at the data from numerous surveys (results to be published soon), approximately 40-45% of teams are now using Agile in some capacity. But before we crown some new Agile king, it really needs to show how it can re-shape the entire software supply chain, determining how organizations define portfolios, releases and IT strategies. This new model of governance, therefore, must apply the principles of Agile to broader problems.
For this reason, before its coronation, Agile may need to assume a different name, Lean. Where Agile has re-defined how people work within the boundaries of the development team, Lean’s dominion is the larger organization. Lean builds upon Agile, as well as other disciplines that apply to parts of the organization that share their boundaries with the development team. You might say that Agile governs one province, but Lean governs the entire kingdom.
Certainly the vendors at the conference have started to take notice of what this regime change means. The vendor village contained the old nobility of Agile tools—Rally, VersionOne, Danube, and others. As the boundaries of Agile/Lean expand, other vendors, such as Microsoft, IBM, Serena, and Microfocus (including their recent Borland acquisition) have joined the court. These vendors are less provincial, but they have had to assimilate the local dialect and customs of Agile. At the same time, the Agile tools vendors have been learning how to be more cosmopolitan, without losing touch with their essential roots.
In the next year, rather than continuing to jostle and elbow each other, some of these vendors may join forces as part of mergers and acquisitions. Others may decide to focus just on the provinces they know best. For vendors and their customers alike, the near future may be, to use (or abuse) Shakespeare again, “the brightest heaven of invention.”
[Cross-posted at the Forrester blog for application developers and the Forrester blog for product managers and marketers.]
Posted at 08:23 AM in Agile, Development, Technology industry | Permalink | Comments (1) | TrackBack (0)
I'm not a fan of the recent fad for PowerPoint decks full of pictures, and few or no words. While the text-packed presentations were guilty of a different sin, the answer is not to remove so many words that someone looking at the slides post oratio can't figure out what the presenter was saying.
In other words, your slides are a UI. The user experience must fit the use cases, including people reading your slides, instead of listening to you talk. You could jettison that use case altogether--if someone didn't hear the presentation, too bad for them. However, I'd bet that most speakers don't want that much economy of communication.
If you're teaching a creative writing class, and you're coaching a chronic blabbermouth, you might want that person to learn how to write haikus. That approach might help them write shorter novels, but they're still going to write novels, not haikus.
Posted at 10:18 AM in PowerPoint, User experience | Permalink | Comments (2) | TrackBack (0)
A few weeks ago, in the Heretech podcast interview with Saeed Khan, we discussed the importance of the product management function from the very beginnings of a product. For start-ups, the PM spadework is especially critical, since bad product decisions jeopardize not only the product, but the whole company.
Here's a cautionary tale about a small start-up (thanks to Steve Johnson for the link). The author's verdict: his business fell into a gaping product management hole.
So the number one reason my startup failed was: I was distracted by a cool and shiny feature that didn’t solve anyone’s problem. The shinier and more tempting features of any software program should be regarded with a high level of suspicion. There may be a reason some things are so shiny and alluring. Traps often have this quality. My advice to anyone creating a solution is to march straight towards your initial goal, as long as the goal really does address a true need then that’s what you should focus on.
Posted at 10:20 AM | Permalink | Comments (9) | TrackBack (0)
I agree with about half of this op-ed about Microsoft and innovation. A sample disagreement: being second to market with a technology is not a bad thing, innovation-wise. Not only can you work out the kinks in the core invention, but you can learn from your competitors' efforts to get sales and adoption.
I do agree, though, that Microsoft often takes good ideas and makes them very Microsoft-centric. Of course, they're hardly the only company to be guilty of that particular sin. IBM, Oracle, SAP, and other technology companies have taken very good ideas and tied them too exclusively to the platform, or slowed the natural trajectory of new technologies so that, at every step, they stay firmly attached to the company's underlying platform.
Of course, from the vendor's point of view, selling the platform is the goal. While there may be some business benefits to the customer (simpler vendor management, fewer risks dealing with smaller vendors, etc.), there are big and obvious down sides, too.
For example, not everyone is thrilled about moving to the next generation platform, and the next generation after that, at the pace the vendor fervently wishes you would. Frictions between customers and vendors result, along with the occasionally perverse business outcome. (Apple's market share of operating systems declined slightly in 2008, for reasons that had nothing to do with Apple. Most netbooks run Windows XP, the OS that customers have preferred over Vista.)
Anything that becomes an end in itself for the vendor becomes an obstacle for innovation, almost by definition. The pace of invention may continue, but the aggressive arm-twisting about the platform on which these inventions run can slow down adoption. As I mentioned earlier, platform-centric product strategies sacrifice development in any particular technology area (BI, CRM, content management, identity management, cloud computing, you name it) in the name of staying in pace with developments in the platform. Limited time, limited resources--development teams can't do everything that both customers and their corporate masters demand.
The XBox, Microsoft's successful venture into home entertainment hardware, provides further proof. The XBox is not your home entertainment platform, around which your TV, DVR, DVD player, MP3 player, receiver, and other components revolve. It's a very good console game system, and that's why, in part, it's still a raging success, because all the hardware in your family room doesn't depend on it.
That product strategy may not have been what Microsoft intended when it launched the XBox. However, how many times have products failed because over-enthusiastic executives thought, "Why, with this platform technology, I can rule the world!"
Posted at 05:26 PM in Innovation, Microsoft, Platforms | Permalink | Comments (2) | TrackBack (0)
In October, I'm doing a workshop in the Foster City office about social media for product teams. How can social media fill in the gaps left by traditional requirements? Which social media outlets should you use to answer particular questions? What skills and investments are required? What's the tangible business benefit?
A big part of the workshop is hands-on experience with the questions your team faces. Bring an example of a burning question that the product team needs to answer (e.g., What's the impact of dropping this feature? Is our product a good fit for similar business problems in other markets?), and we'll explore how to use social media to find substantive, useful answers quickly.
For more details, click here. Also, in a couple of weeks, colleague Laura Ramos is doing a workshop, "Making B2B Marketing Work," that chock full of useful content.
[Cross-posted at The Forrester product management blog.]
Posted at 04:47 PM in Forrester, Requirements, Social media | Permalink | Comments (2) | TrackBack (0)
During yesterday's interview with Steve Johnson for the podcast, Steve gave an account of the panel at Agile 2009 that tried heroically to draw the line between product manager and product owner, but didn't reach a consensus answer. Today, I spotted this blog post about what it means to be a product owner. Even if this were the definitive job description for product owner, you still wouldn't be able to guess exactly where this job differs from product management.
By the way, if you have access to Forrester's research, here's the study I did last year on this topic. As I said during the interview with Steve, I thought it would be a bit of a lark. Instead, it turned into a real puzzler, trying to find the organizational algorithms that technology companies used to develop a variety of different PO/PM formulas. They're the same! They're different! They're different levels of seniority! They're the same! And so on.
Posted at 04:33 PM in Agile, Product management, Technology industry | Permalink | Comments (1) | TrackBack (0)
C. V. Wedgwood: The Thirty Years War (New York Review Books Classics)
Edward Gibbon: The Decline and Fall of the Roman Empire: Volumes 1-3 (Everyman's Library)
Richard S. Dunn: The Age of Religious Wars, 1559-1715 (Norton History of Modern Europe)
Stephen O'Shea: The Perfect Heresy: The Life and Death of the Cathars