The Heretech

The Heretech is taking the week off

I've had a massive amount of end-of-Q3 work to do, so the podcast is on hold until next week, when it will return to its regularly scheduled broadcasting schedule. I'll also pick up where I left off, blogging-wise, later this week.

Links to things I've reviewed

I've done a long-overdue housekeeping task, adding links to everything I've reviewed on the weekly Heretech podcast. Look for them to the right at the bottom of the column immediately to the right.

More for the PM playlist

Based on some recommendations from friends of the blog, I've made some additions to the PM playlist.

Why everything needs a sanity check

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:

• Tsunami regularly appears, for reasons that escape me. Why would you choose a natural disaster as a moniker? Undeterred, companies continue to do it, including one enterprise software company that shall remain nameless, who chose it as a code name for a project not long before the 2004 tsunami killed approximately 230,000 people.
• Another recurring name is Rolling Thunder. It might make you think of an Apache warrior, but it's actually the code name for a human disaster, the failed US bombing campaign against North Vietnam. (Again with the Vietnam War!)
• Small companies seem to be especially prone to bad name choices, such as Gianus, Ebone, Wayne Kerr Electronics, Bookgoo, ISOARS Web Design, and ExchangeP.
• For every bad company name, there are 10 bad product names, such as iSmell, TheGIMP, Vergatorio (look it up), LappyMats, Popuload, and the Tonium Pacemaker (not what you think it is).
• And if you're not careful, your innocent-sounding name may make a disastrous URL. 

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.

Not quite the use case he expected

A hilarious take on designing technology to meet your customer's expected use case. Or not.

How an ISV uses "inbound" social media

In this week's Heretech podcast, I spoke with Alex Bender of Archer Technologies about the role the Archer community plays in the development process, all the way through the release. If you click the thumbnail shown 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.

The Heretech, episode 22: Alex Bender on inbound social media

This week, our guest is a prime example of "inbound" social media, used to make smarter product decisions. Alex Bender of Archer Technologies describes how their community helps with the entire release cycle, from starting with the generation of good ideas. And whaddaya know, there's another research document, by Yours Truly, about this topic in the Forrester publication queue. Finally, if you're looking for a primer on Lean approaches to development and delivery, look no further than this week's review. Copyright (c) Tom Grant.

The PM playlist

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?

• "Build Me Up, Buttercup," The Foundations. The job is, at the end of the day, making sure that your company is building something of value.
• "If You Could Read My Mind," Gordon Lightfoot. Unfortunately, what defines value is pretty elusive. Figuring out what people really want is one of the trickiest parts of the job.
• "Quality Shoe," Mark Knopfler. Often, what they want is a lot simpler than what people in the development team assume. It's always safest to start with the basics.
• "Human," The Pretenders. In PM, you'll spend a lot of time talking about technology, in technological terms (features, supported platforms, bugs, integrations, builds, etc.). You need to be on top of these details, but you also need to keep enough perspective on the human elements of technology adoption. (And if you're not keeping an eye on both the technology and business factors, who is?)
• "I Need Some Money," John Lee Hooker. At the end of the day, though, you're building something of value for both you and the customer. Can your company make money, based on this idea? (By idea, I mean something as big as a product, or as small as a minor feature.)
• "On The Road Again," Canned Heat. Then you have to translate this value, for the customer and your company, into a roadmap that benefits both parties.
• "No Phone," Cake. As you march down this roadmap, you're going to face a lot of conflicting priorities, unexpected twists of fate, and other distractions. Still, you need to keep your wits about you, which often means you can't be as available to everyone who wants your time as they'd like.
• "Who Are You," The Who. You're also going to face a lot of confusion about your job description. What does PM do, anyway? If you don't take the initiative and define it clearly for them, other people will define your job for you.
• "Video Killed The Radio Star," The Buggles. Technology shifts are tricky to predict, and everyone wants to be at the center of these changes. You're going to have to decide how your company can best strike the balance between visionary possibilities and prosaic realities.
• "I Won't Back Down," Tom Petty. Your job as PM is, in large part, to remove a lot of this chaos and uncertainty. Your best tool in your arsenal are the facts. You're paid to have an expert opinion about markets, customers, competitors, technology trends, and other forces that shape your company's destiny. You are not paid to have just another opinion.
• "All You Ever Wanted," The Black Keys. Roadmaps will change. Projects will get new priorities. Some messaging will fail. Customers will disappoint you. Obviously, you need to be flexible, but you also need to keep the same destination in sight: Building something people want, and will make your company money to provide it.
• "Complicated Situation," Black Rebel Motorcycle Club. You're going to have to deliver bad news. Some stakeholder's pet idea won't pan out. A customer's bug is going to take longer than expected to fix. The big new market will prove to be a mirage. Deal with it.
• "Under Pressure," Queen with David Bowie. If you don't like these kinds of challenges, then PM isn't the job for you.
• "Working In The Coal Mine," Lee Dorsey. And yes, it's a lot of work. Frequently, you won't always be able to predict what the work will look like for the rest of the day, week, or month.
• "Three Little Birds," Bob Marley. But, as Bob Marley says, "Every little thing is going to be all right." Not every prospect is going to buy your technology. Dates slip, but not into infinity. You'll get bad, unfair press. You'll lose internal arguments. Good PMs know how to dust themselves off and move to the next task.

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

OMG! U R trapped!

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.

Windows 7: Too big to fail?

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.

Adobe's Omniture acquisition: a TI perspective

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

Hot off the presses: wargames, PM in the recession

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.

• Product management/marketing during the recession. A very short document that points to other research that we've done about the recesssion, and then puts it into context for PMs. What changes do PMs need to make in product strategy and positioning? Which markets are likely to bounce back first, and what do you need to know about them?

Exporting is not abandoning

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:

• Migrating between a test system and a production system.
• Exporting data that will remain in System A in some form that System B can use. For example, you may continue working on content in a collaboration application, but you may need to export versions of it to a web content management system for publication.
• Exporting data as part of auditing or legal discovery, so that people outside your organization can have access to it.

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.

The Heretech, episode 21: Steven Haines on PM as a profession

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

Use case first, then applications

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.

Everyone's a super-user!

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.

Polishing the Chrome

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

I'm a ramblin' man...

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.

The Heretech, episode 20: Luke Hohmann on serious gaming

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.

The Agile regime change

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

Slides are not self-explanatory

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.

Killer feature kills startup

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.

Are platforms a drag on innovation?

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!"

Workshop on social media for development teams

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

Product owner or product manager?

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.