Google's decision to pull the plug on Wave was hardly surprising. Not only did Wave stumble out of the gate and then never quite get its footing, it violated a core principle of software as a service (SaaS): It's the application, stupid.
If you're going to be in the SaaS business, you need to deliver an application that's attractive, comprehensible, and usable immediately. Not after a horde of developers built a library of interesting widgets. Not after a quasi-beta program in which the product is really in production, but you just choose to call it beta. Not after potential users scratch their heads for days, wondering what the heck this Wave thing is supposed to do, and then sell their equally perplexed colleagues on its purported value. Deliver value now is the cardinal rule of SaaS.
On-Premise Strategy For An On-Demand Application
Wave's product strategy resembled a traditional on-premise strategy, in which you built the platform first, and then added an application to it. In the cloud, the product strategy moves in exactly the opposite direction: application first, then platform. A classic example is the Salesforce portfolio, which started with a highly capable CRM application that was easy to implement. Later came the platform, Force.com, on which customers and partners could build customizations and adjacent applications.
Today was our first official update to the research plan (a.k.a. the development document) for our project investigating thought leadership in the technology industry. A quick refresher: this particular piece of research is our first venture into Agile research development, which (1) applies Agile principles to our research, and (2) opens the project to the community to participate in the research process from start to finish. In other words, we're using the newly-launched Forrester Community as the forum where the voice of the customer will speak directly to us about our research as we're doing it.
You can see the current development document, including the updated text and the comments that inspired those changes, here. As promised, we're also maintaining a change log for tracking these changes over time. (The development document is also versioned, so we can look back on the history of edits through that mechanism, too.)
As I explained earlier this week, this is our first venture into Agile Research Development, a very different way of doing research. Since it's officially Agile, I'll use even the thinnest of excuses to explain how we're applying Agile principles. Pictured here is our Scrum Master, Eric Hsieh, taking a picture of our initial list of items that we're putting into the backlog. That chart sits right next to my desk in the Foster City office of Forrester, so I threw in another shot that gives a peek at the scenic view from my desk. (If you've never been to Foster City, it's the mini-Venice of the Bay Area. I could kayak to work.) Also taken from the Agile canon are the user stories that define how we expect the collaboration between us and the Forrester community to operate.
Today's a very exciting day for me. As you know, I'm a member of a team of Forrester analysts who write research specifically for product marketers and product managers in the tech industry. A few weeks ago, we launched a community for product marketers and product managers. Now, we're bringing those two activities together by including our PM community in every stage of a research project. Plus, we're using an Agile approach. And you're all invited.
(Role-based research. The voice of the customer, expressed loudly and regularly through social media. Agile as the vehicle for applying what customers say to the product we're developing, in the most rapid and substantive way possible. I guess we do read our own research.)
What's The Topic?
We've yet to meet a product marketer or product manager who isn't interested in thought leadership, given its attractiveness and elusiveness. Gaining recognition as a thought leader is only the first step. Having achieved that exalted status, how do vendors convert thought leadership into tangible business benefits?
For our first venture into this new research approach, thought leadership was an easy choice of topic: important, popular, practical, and manageable.
Where Does The Community Fit In?
The community has a bigger role to play in this project than just suggesting a topic. We need your suggestions and feedback throughout the entire research process, from inception to publication. For example, before doing the primary research, we'll draft a list of interview questions. Since thought leadership has no end of interesting aspects, we want to make sure that the questions we ask go straight to the issues that matter most to product marketers and product managers. Here are but a few examples:
[Another interesting finding about the requirements tool market, from research by Yours Truly and Mary Gerush. For other observations about this very interesting market, click here and here.]
As organizations improve their requirements practices, and as the requirements tool vendors adapt in response, the front end of the requirements process is getting a disproportionate amount of attention. Many requirements defects start early, with the information that you feed into the requirements-generating machine. For example, if you don't have a clue how criminal investigators work, you're going to make basic mistakes in feature prioritization and design when you build a case management system for them.
And it's not just the information that has fallen under suspicion. A lot of people are equally worried about the other raw material, ideas, that you feed into this machinery. Here are a few commonly cited concerns:
By now, the arguments for improving product requirements are very familiar – all too familiar. Bad requirements lead to misconceived projects, many of which fail outright. The survivors can waste frightening quantities of time, effort, and money. (And if you've been unlucky enough to be part of one, you don't want to repeat the experience.) In technology companies, even the best requirements are no barrier against failure: insights into what kinds of problems customers face, how the company's products and services can help address them, and why they'd consider getting the vendor's help remained siloed in the requirements, never reaching other people in the company – sales, marketing, support, etc. – who deal directly with customers and partners.
Nonetheless, it wasn't until relatively recently that the market for requirements tools expanded and diversified, as described in my previous post. Many organizations had the same attitude toward requirements that most of us share about regular visits to the dentist: We understand the clear, direct benefits of changing our behavior, but we'd rather not make the effort. Clearly, something changed in the last few years to increase the general interest in adopting better requirements hygiene.
In fact, many things changed, all pointing in the same general direction. Not every potential requirements tool adopter experienced the same new pressures, so you won't be able to identify a single, iconic tale. Instead, the history of the requirements tool market is more of an anthology of stories that have the same moral: the business consequences of bad requirements are no longer tolerable.
The just-published overview of the requirements tool market is, at bottom, a story of unrecognized success. The requirements tool market has grown rapidly along several measures, including the number of vendors, the scale of adoption, and (the primary focus of the overview) the number of business problems that these tools are designed to address. From a small niche in the software market, requirements tools have grown and evolved, sometimes merging with other applications, to the point where it's hard to talk about them as "requirements tools" in the strictest sense of the term.
When colleague Mary Gerush and I dove into the primary research, we were immediately struck by the number of vendors that have crowded into a space that, to be honest, was not too long ago treated as a bit obscure and unexciting. The longer we looked at the market, the more little vendors appeared in the landscape. We'd heard of long-standing specialty vendors like Ryma, Blueprint, and iRise, but names like TraceCloud and AcuNote were new to us. The big vendors, too, have seen opportunities in this space, sometimes buying (for example, IBM's acquisition of Telelogic), sometimes building (such as Microsoft's Sketchflow tool).
Something was happening in this market, and at least a piece of the explanation was clear from the moment we started talking to vendors and users. Very few of these applications were exactly like the first generation of requirements tools, such as MKS Integrity and Borland (now Micro Focus) Caliber, and most of the newer tools bore little resemblance to each other. Although they share the title "requirements tool," they don't deal with the same aspects of requirements.
In the immortal words of Keanu Reeves in Speed, "Pop quiz, hotshot!" Answer the following questions:
On average, how long does it take for customers to implement your technology? (Include people using the technology in the definition of "implement.")
In all phases of a project (building the justification, drafting the requirements, selecting vendors, implementing the technology, reviewing its success), is there anyone in the customer organization who champions the project from start to finish? If not, when and how does the hand-off happen?
Is there anyone responsible for successful execution in each phase? Again, if not, what does the hand-off look like?
How does the project team convince people in their organization to use your technology?
Don't worry if you couldn't answer some, or even all, of the previous questions. You're not alone. Most technology vendors don't have anything but the most superficial understanding of how customers adopt their technology. Naming a few stakeholders isn't the same as understanding the adoption process, unless you think there's no reason to read Gone With The Wind if you can identify Scarlett O'Hara and Rhett Butler as the main characters.
Tech vendors have all kinds of reasons to understand adoption better than they do. When projects fail, and adoption doesn't happen, those customers are far less likely to stay customers. That's also a potential success story that you must cross off the list. And that's just the beginning of the problems.