PMs know that requirements are flawed

The workshop next week, "Using Social Media To Make Smarter Product Decisions," was a good occasion for me to jump into the data we've been collecting about requirements in the technology industry. It's one thing to claim that there are problems that need fixing, and that social media can help fix them. It's another to put that claim to the test.

The requirements survey has produced a lot of interesting results that will see the light of day in a research document to be published later this quarter. The questions we asked build a composite picture of both the content of requirements and the process of creating them. For example, we asked, ""How much time do you dedicate to requirements work at each stage of the development cycle?" Doing a weighted average of the responses, here's the answer:

This picture should be familiar to any PM: lots of requirements work at the beginning of the project; less and less as the project proceeds. Which begs the question, how effectively can the organization make mid-course corrections? When does the "after action report" kind of analysis happen, when PMs look back on the work they just did to figure out what they could do better the next time?

While this spike of requirements attention at the beginning of a project makes sense in bureaucratic terms, it doesn't make sense in research terms. You might pretend that the requirements you build at the beginning of a project are everything that the development team needs to proceed, but at best, that's a comforting fiction. You always need to fill in gaps, provide more detailed explanations, and validate the results.

If requirements are the information that technology teams need to avoid making costly mistakes, then requirements gathering and analysis should be an ongoing activity. While that's certainly true in some PM teams that I've met during my time as a Forrester analyst, in the aggregate, these peaks and valleys of activity still define the requirements landscape for many PMs.

There are plenty of other signposts to deficiencies in product requirements. For example, there's a big mismatch between the skills needed to do requirements, and the opportunities to put these skills to work. While the rest of the story will come later, I thought this one result was interesting enough to now, instead of waiting for the final report.

[Cross-posted at The Heretech.]

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

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

That was the week that was, part 2

The other big project this week was a detailed analysis of a company's corporate and product marketing. We have a specific methodology, called a Vendor Positioning Review (VPR), that measures the ability of a company's publicly-available marketing materials to speak to both technical and business audiences. We also assess the connections (or lack thereof) between the corporate and product marketing content. We put these details into a tool, and out pops an assessment that suggests some important changes that may be necessary.

The VPR is based on what Forrester calls the IT to BT shift. In this shorthand, IT (information technology) delivers value only if the right combination of business and technical experts, working in tandem, can figure out whether there's any business value in it. BT (business technology) delivers value more quickly, because its creators design and market it to address particular business problems that plague people in particular jobs.

We see the effects of this IT to BT shift all the time. In a way, it's a congratulatory message to the technology industry: "Good for you! You've become an integral part of the lives and work of billions of people!" Unfortunately, that also means that the self-same billions who now rely on this technology have strong opinions about whether or not it works for them, and significant power to determine its purchase and adoption.

Many companies in the technology industry struggle to speak the business user's language. Some of them act like the "freaks and geeks" crowd hanging around the fringes of a high school dance, uncomfortable with talking to anyone outside their circle. Trying to make the astronomy club sound cool might not be worth the effort, particularly if you feel that you're doing fine with the crowd of people who already understand you. (By the way, I was in astronomy club, and it was pretty cool.)

Others might be more aggressive about discussing their favorite arcane pursuits, which may hold no appeal for most other people. Going out to the desert with your buddies, getting blind drunk, and chasing jackrabbits with your three-wheel ATVs might seem awesome to you, but not to the young woman you're trying to impress.

Unfortunately, you do need to explain the value of technology to people who might otherwise not care to hear it, even if it's the most "techie" of all technology. If there are no business benefits, then why should someone spend money on it?

I'll use the JSR-168 portal standard as an example. If you go to the web site of a vendor who supports this standard, chances are you'll find some relevant product marketing materials.  This finely-crafted material might be as gripping as the last season of The Wire...For a purely technical audience. Rarely will you find a statement of business value as straightforward as, If you buy technology that supports this standard, you'll spend less time training people on integration APIs, or maintaining your portal, etc.

And if you still think that the ability to speak in both business and technical terms is unnecessary for your product...Well, I guess you're a happier person than me, since you've probably missed the great economic implosion of the last year or so. Cling to your child-like innocence for as long as you can.

[Cross-posted at The Heretech.]

Market development: horizon or mirage?

The recession has sharpened the points of a dilemma that technology vendors were already facing: Do cleave closely to our existing customers, or try to expand outwards? Do we try to sell more into existing account in familiar markets, or do we look for new markets where people are struggling with business problems that look congruent with the ones we're solving for our existing customers?

With no obviously correct choices, vendors experiment, to the point where they see real opportunity, or decide that the exercise is going nowhere. But how do you know if you've invested enough into the experiment to get a reliable result?

Adobe runs a good business, but its stock still takes a dive
A good example of a technology company that could stick closely to its existing customers, or fan out to find new ones, is Adobe.  Having long ago identified its core market, creative departments and web site teams, Adobe might not have an obvious place to go. However, maybe it doesn't need to. As long as Photoshop remains the standard for image editing, Dreamweaver remains the web developer's tool of choice, Acrobat is the default cross-platform document format, and Flash retains a strong position against threats like Silverlight, Adobe will continue to get license renewals and accrue new customers.

Unfortunately for Adobe, Wall Street doesn't see the world through the same lenses. Even positive coverage from market observers failed to keep Adobe's stock from plunging from a high of approximately $45 per share last fall to under $20 per share in March. Since that nadir, the price has bounced back a bit, to around $30 a share today.

Here's how positive the coverage was, during this collapse of Adobe's stock price:

• Michael Goodman at TheStreet.com,  in "Adobe Has Its House In Order," praised Adobe's cost-cutting measures. Adobe was behaving like one of "the winners will be the companies that scale back operations in concert with what they're experiencing, not how they wish it to be.
• For months, The Motley Fool has pointed to Adobe as an outperforming technology stock.
• In May, SmartMoney.com featured Adobe as a top pick among technology stocks.

At this point, the management of a company in Adobe's position might conclude, "Holy moley! If we can't get our stock price up by making smart business decisions, and holding on to a reliable customer base, we have to find new customers!"

How big can the application development circle be?
Undoubtedly, new customers would be good, but where to find them? Adobe has at least one idea of how to expand its customer base: get more people who actually contribute to web applications to be users of the tools. Flash Catalyst is designed for the web designers who are not coders, but who build the application flow, user experience, and general UI conventions. After creating the basic application framework, a developer can add the necessary code to enforce business rules, handle weird edge cases, and other tasks.

That's great, but maybe it doesn't go far enough. Perhaps Adobe should be pushing to go further, involving not just the people who build prototype applications, but the business users who have to live with the results. Give that butcher, baker, or candlestick maker a cleverly-designed interface for specifying what kind of application to build, and the tool puts together the pieces. Voila! You've just expanded Adobe's licensed user base to include a whole lot of people who might have spontaneously combusted if they had come into direct contact with tools like Photoshop or Illustrator.

Or, perhaps, this user-generated application is a pipe dream. After all, vendors have tried before, but you wouldn't necessarily give Microsoft Access or even Intuit's QuickBase platform to any random business user. Maybe this kind of tool is possible, but the cost/benefit ratio of building one isn't really there for Adobe. Extending a development tool to include non-coders is already an impressive achievement, so it might be a bit unfair to Adobe to ask them to do more. On the other hand, it's just that kind of push to do more than originally planned that leads to some of the best inventions.

Whatever the ultimate answer may be, the first step into this direction, adding web designers to the mix of rich application developers, is not in and of itself a good measure of how far the idea might go. Who knows, web designers might be wholly unenthusiastic, but end users might be overjoyed to be included. Enthusiasm and adoption might not proceed along a straight line with an unvarying slope.

Herein lies the chief peril of market development. Invest too little, and you may miss important opportunities. Invest too much, and you may discover that you've been chasing a mirage.

[Cross-posted at The Heretech.]

Of designers and developers

In today's post at The Heretech, I come out of the closet. Yes, I am a bigger history geek than you can possibly imagine. Hello, my name is Tom, and I play wargames.

However, by playing a lot of games designed to simulate historical events, I've learned a couple of things that apply to designing products in the technology industry. Specifically, how do you create a design teeam that can overcome some of the common pitfalls, such as unnecessary complexity? To read more, follow this link.

[P.S. Thanks for pointing out the problem with the link. Typepad is intermittently eating the hyperlinks I enter. From now on, I'll just have to test them before I publish.]

Nuts to negative solidarity

Phil Montgomery's recent post, "Hatred Is A Bad Business Driver," is definitely worth reading and taking to heart.  Here's the money quote from Phil's post:

I remember being at Novell in the late 90's and feeling absolute hate emanating towards Microsoft.  This was despite us all using many of their products internally - including Windows - Microsoft has some extremely good products (Excel is a case in point). Novell's hatred of Microsoft caused them to go on an irrational buying binge to assemble products (Wordperfect, DR DOS et al) and compete head-on with Microsoft. As we know, this didn't work - nobody can beat a bigger adversary by attacking them head on.  Hatred created a flawed strategy that led to failure.

Of course you have to observe your competitors carefully. Frequently, you'll need to react to what they're doing. However, that's not the same thing as shadowing their every move.

Tribes go to war
Usually, companies kick off these "Kill [Insert Competitor]" campaigns for internal reasons. They need to rally their organization around an initiative that's easy to understand, and plays to their employees' competitive instincts. The academic term for this behavior is negative solidarity, which all societies, from the most tribal to the most advanced, depend on to some degree to define and maintain their boundaries, and to motivate their members to defend the larger group.

Not surprisingly, negative solidarity is only useful to a point. While it's easy to define whom you're against, what exactly are you for? When the stakes are trivial, such as a soccer game or the Miss Universe competition, rooting for yourself against others seems pretty harmless. When you invade another country to distract the citizenry from the problems within your own borders, negative solidarity gets pretty nasty.

PMs get trampled
Since I've been interviewing product managers and product marketers for Forrester, I've seen a definite pattern. The more these groups focus on the competition to the exclusion of their customers, the weaker the PM group, and the less effective the PMs are in doing their jobs. Here's why:

• Competitors are easy to figure out. For technology companies, the competition is the point of reference in the market most like themselves. Understanding the feature list of a competitor's product is far easier than understanding the behaviors, attitudes, and quirks of users. Competitors are people like you; users live very different lives than software and hardware engineers.
• PMs have less to offer for competitive analysis. That's not to say that there's no value in having someone approach the task of competitive analysis professionally. It's also worth having people who dedicate themselves to staying on top of the market. However, competitive intelligence is relatively easy to collect, and easy for Development and other groups to interpret. Therefore, PMs primarily act as a collector of competitive data, not as an interpreter of what it means.
• Competitors can distract from the problems with your own strategy. Any reasonably clever simian can craft a product strategy based on matching the competition step by step. However, that approach makes two courageous and often dangerous assumptions: (1) The competition is following an intelligent product strategy; (2) However good or bad that strategy is, it works for your company.
• Excessive competitive focus undermines PM's ability to say no. For PMs to craft product strategy, they need to be able to veto ideas that don't contribute to that strategy. When the company gets too fixated on competitors, PMs get into a situation that resembles an argument with a Roomba over the finer points of cleaning your living room: It's programmed to respond to particular cues, impervious to whatever logic you try to apply.

This unhealthy dynamic undermines PMs role in the organization, which is a good measure of how well or poorly the company is responding to its customers.  Competitive analysis is critical, but it's not a replacement for your own company and product strategy.

Postscript
On a personal note, Phil's post caught my eye in part because I worked at a company that tried a "Kill Novell" strategy for a while. The source was the salesforce, which was complaining that they were running into Novell's file management products in their accounts. At one quarterly sales meeting, the salespeople were eager to get as much competitive data, plus our responses to the competitive threat, as we could provide.

Three months later, at the next sales meeting, Novell had disappeared from the radar. Meanwhile, we were the same company, slogging through the same sales process with the same products, and often the same customers.

[Cross-posted at The Heretech.]

How the Oracle/Sun deal makes sense

Ever since the IBM offer to acquire Sun fell through, we've been waiting for the other shoe to drop. Apparently, we didn't have to wait very long.

Honestly, I'm surprised at the strongly negative tone to many of the responses I've read or heard today. You expect to hear a lot of snarky sniping on Slashdot, but come on, Infoworld, do we really know that Oracle is going to lay off 10,000 Sun employees? (Which is a highly misleading headline, since in the last sentence of that article, you'll discover that Sun was already planning to lay off 6,000 people.)

Every deal has its pros and cons. Since other observerss have been focused on the potential downsides for Oracle, Sun, or their customers, let's leave those aside for the moment. Instead, let's talk about the waysin which this deal make sense.

Sun was on the path to be acquired by someone. Sun was struggling, and finding a buyer was a good way out of their business dilemmas. Once the IBM deal fell through, the big question was, how many other companies were in a position to acquire them? If not Oracle, then who?

Oracle needs to extend its platform. Oracle's strongest card has been its ability to get its platform technology--in particular, its database--into IT centers. Just as many companies have discovered how slippery a concept "platform" can be, Oracle long ago realized that its business depended on expanding that definition beyond just the RDBMS.

Oracle realizes that it can't build everything. On the other hand, as big a company as Oracle is, and as many developers as it employs, it came to a realization--not immediately, and not easily--that it couldn't build everything. You might quibble whether Oracle should develop certain point capabilities, such as workflow, or let someone else build it. When a company of Oracle's caliber finds it difficult achieve the success it thinks it deserves at a line-of-business, major platform component level, then people need to stop quibbling and get serious. To its credit, Oracle realized that it needed to stop trying to build its own version of every technology out there. (Anyone  remember Oracle PowerBrowser?)

Oracle has been successfully acquiring platform and application technologies. To get serious about the application server market, Oracle acquired BEA. To overcome the hurdles entering the enterprise content management market, it gobbled up Stellent. And most famously, to get applications technology, solutions expertise, and customer lists, it bought Peoplesoft and Siebel. All smart moves, compared to rolling a big Sisyphus-sized rock up hills where Oracle couldn't bring its strengths to bear.

At key points of contact, Oracle and Sun's businesses mesh. The best way to describe Oracle's business culture is, "Techie on the inside, techie on the outside." If you're a component technology company, you'll find it easy to fit into the Oracle organization. If your customers are DBAs, developers, or sysadmins, the transition will be that much easier. The congruence between Sun and Oracle works at other levels than products and customers too. Oracle's salesforce now has more enterprise-scale technology to sell. Oracle's very genuine investment in building a community of technologists just got a huge boost, too.

Oracle has not raped, pillaged, and burned its acquisitions. Remember when Oracle announced its intention to buy Peoplesoft, and everyone acted as though Viking longships would soon be coming through San Francisco Bay? Oracle has not cleaved savagely at the organizations it acquired, nor at the customers who came with them. Was everyone happy with the results? No, of course not--but how different was that from other acquisitions in this industry? Particularly since the priorities of the larger company (for example, having everything work within the current versions of Oracle's platform technologies or management tools) naturally take preference?

Oracle needs a stronger cloud story. Oracle is still the odd platform company out in the cloud market. Larry Ellison might go to extremes in decrying the hype about cloud computing,  he's right to be careful. Oracle might fit into the cloud already, since there are multiple layers of the cloud computing platform, without making major changes. However, if the shift to cloud-based services, something that does play strongly to Oracle as a platform company, does require investments in technology (yes, perhaps even hardware) or expertise, then the Sun acquisition may help.

Oracle's freedom of action expands with Sun. Depending on how the technology market expands, with or without respect to cloud computing, "the Oracle platform" might need to include an operating system, greater optimizations to work on particular hardware, or more direct influence over the future of Java and related technologies. In that case,  the Sun acquisition might be strategic, even if the short-term benefits aren't altogether clear. (And it's worth noting Oracle's existing investments in some of these platform-defining technologies, such as Linux.)

Yes, of course, there are potential downsides. Perhaps MySQL won't die immediately, but it might suffer malign neglect.  On the other hand, as long as its fortunes were tied to a struggling company, its future was in doubt for other reasons. Maybe other people's favorite technologies will get the axe. And maybe some of them, such as the-serious-challenge-to-Microsoft-Office-that-never-was, should get the bum's rush. Whether that means selling these technologies, putting them into RDB-like semi-retirement, or completely retiring them, remains to be seen.

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

Giving in lean times

Whenever the economy gets into trouble, charitable contributions take an even greater beating. This recession has struck particularly hard at many of the organizations that are major sources of institutional donations. No amount of tax incentives seem to change this picture significantly.

Therefore, every little bit counts. Companies still have some self-interest in charity, but that doesn't change the importance of the outcome.

Case in point is Atlassian, who is donating a portion of their core business, Confluence and JIRA, to raise money for Room To Read. The one-year, 5 users at $5 per user deal (click here for details) is hardly a cost-free donation for Atlassian. Confluence has a lot of traction in the Wiki market on its own. The Confluence/Jira duo appear frequently in technical teams who want a mix of tools that fit their work, but are flexible enough to be twisted into whatever collaborative shape they want. Heavily discounting these licenses, therefore, is nothing to sniff at.

Other tech vendors who have built charity into their business plans, like Salesforce, continue their investments, even during these tough economic times. These efforts don't get much attention from analysts like us, so I'm glad for a chance to give a quick nod in this direction.

[Cross-posted at The Heretech.]

Latest podcast: emerging markets

In the third podcast, I interview Jennifer Belissent, a senior analyst here in Forrester's Foster City office, about emerging markets, going international, and what all that means to product managers and product marketers. Here's the link to the official location for the podcast, which is also available through iTunes.