« June 2009 | Main | August 2009 »
I forgot to cross-post "Beware of the naked man" last night. Since people kindly left comments to the post, I have to rectify that oversight.
The post is about the role of social media in product requirements. Is it a supplement or replacement for other requirements sources? How hard is it to get good information out of social media?
We're trying to make our requirements survey as successful as possible, which depends in large part on getting as many people to take the survey as possible. Here's where we humbly beg for your help.
Please distribute this link to the survey to anyone you think has experience with, and opinions about, requirements documents and the requirements process:
http://deploy.ztelligence.com/start/survey/survey_taking.jsp?PIN=15TQ9CMTFTDDZ
Again, all responses remain confidential, and participants get both our thanks and a copy of the final research.
[Cross-posted at The Heretech.]
Which business problems will Google Wave address?
A few weeks ago, I watched the Google Wave launch video with a mix of interest and nervousness. A big part of my reaction was shaped (warped?) by my experience doing product management and product marketing for collaboration and content management products. While I didn't launch myself at the screen yelling "Noooooooo!" (in slow motion), I did worry that Google might walk straight into an all-too-familiar minefield of competing solution areas.
Collaboration and content management pose a classic problem in requirements and design: Which solution do you want to target? If you build a product without prioritizing among all the different business problems that it might address, you'll build a very "horizontal" product that satisfies no one. Or, worse, it makes perfect sense to you, but everyone else struggles to see how it will best work for them.
Customization in Google Wave
The very horizontal application demo application in the launch video bore an unsettling resemblance to other UIs for collaboration and content management (CM) that I've seen over the years. Unlike the UI for a word processor (like the one for Google Apps), the face of collaboration and CM tools twist and flex to the shape that organizations strongly want them to take. Remove this, add that, change how this works, make this piece run by itself in a portal, etc.
Which leaves the product team with a dilemma: Do you build something that works really well for a particular solution area (say, the loosey-goosey world of ad hoc collaboration), but not for others (for example, the highly structured processes needed for single-source, multi-channeled publishing)? Or do you build something that's highly configurable and customizable, and let the customers and partners do the morphing?
While I'd pick the second option, it has its risks. Prominent among them is forgetting to prioritize this kind of plasticity early in the product's lifecycle. With every month of coding, the product gets more resistant to your later efforts to build in customizability.
Having seen how much customization is built into Google Wave, I'm both relieved and impressed. Google already has a very big community of early adopters using the APIs and protocol to build plug-ins to accommodate a variety of use cases. From these humble beginnings, developers will build more sophisticated customizations. Will these rise to the level of capability need to address business problems like corporate risk management? We'll have to wait and see.
Google's other dilemmas
Customization isn't the only dilemma that the Google Wave team will face. For perfectly good business reasons, someone will ask, "Can I keep my content stored in my own repositories, and just use Google Wave as a collaboration and management layer above that storage?" The huge architectural questions that poses will force Google to say, "Yes, that's the business we want to be in," or, "No, that's not our core business."
Note that the choice is more about business than technology. Google is full of smart technologists, but its resources aren't infinite. Depending on the solution area, Google would have to acquire a different mix of domain expertise, marketing resources, partnerships, and sales muscle. I'd bet that the mix needed for most solution areas would not look very attractive to Google. Making a smart technology choice, up front, ensures that Google has the flexibility to choose among these options.
[Many thanks to Lars and Jen Rasmussen for yesterday's Q&A on Google Wave. If you're interested in being an early adopter, sorry, they told us that they already have the first 100,000 registrations. However, it's still worth signing up, if for no other reason than to tell Google how many people are interested in Wave, and how they'd like to use it.]
[Cross-posted at The Heretech.]
We're doing a major research project on the state of product requirements in the technology industry. To make this project as successful as possible, we need your participation in either or both aspects of it, the survey and the examples. (Whichever works for you.)
What's in it for you? When the final research document is done, we'll give you a copy. We also promise to keep any information you provide confidential.
The survey
We just launched the survey at the following link:
http://deploy.ztelligence.com/start/survey/survey_taking.jsp?PIN=15TQ9CMTFTDDZ
If you have approximately 20 minutes to spare, we're interested in hearing how you collect, write, review, and circulate requirements in your organization. Also, please feel free to forward this link to anyone you think would be interested in participating in this survey.
The examples
We've been building a library of examples of requirements documents. (And thanks to everyone who has sent us their samples already.) We don't need to see the actual words, just the structure of the document. In other words, we want to see your template, not the actual contents of a completed requirements document. Fake or redacted data is good, too, if you use a requirements application.
We're being deliberately vague about what a "requirements document" is, since we don't want to lead the witness. Your examples will tell us what you think the fundamental requirements documents are. What do the key stakeholders and consumers in your organization need?
If you're willing, please send your examples directly to me, tgrant@forrester.com.
[Cross-posted at The Heretech.]
As a Forrester analyst, I talk directly to product managers, product marketers, product VPs, development managers, CEOs, you name it. Sometimes, I discover that people in these roles don't know the full range of research, data, and other services that Forrester provides to them as our clients. Therefore, I thought it would be worth a quick post about one of these services, inquiries.
Have a question? Set up a 30 minute inquiry and we'll do our best to answer it for you. Since my research covers a bundle of related topics--product management, product marketing, requirements, Agile, social media, product strategy, etc.--the questions sent my way usually fit into these categories. I also get no small number of questions that fall naturally into the penumbra of these topics, such as market development, innovation, standards, and tools. Here are some recent examples:
You pick the format for the response, e-mail or phone call.
If I get a question that's not in my bailiwick, I'll help our Inquiries team steer the question to the right people. For example, Tim Harmon is usually best for SMB-related topics, while Jennifer Belissent covers international markets.
To arrange an inquiry, you can use your Forrester account to log into our web site and pose your question. (Every research document has a similar link to the inquiry request form.) Alternately, you can use the inquiry@forrester.com e-mail address to contact the Inquiry team.
So, fire away.
[Cross-posted at The Heretech.]
I have boardgames on the mind lately, since game development has some interesting parallels to product development in the technology industry. Today's twist: Boardgame designers put a lot of effort into creating a particular experience. There are lots of ways to make bad design decisions, but the really good ones don't reveal themselves unless you "playtest" them. Unfortunately, the "user experience" testing for a $100,000 piece of technology often isn't nearly as rigorous as the playtesting for a $30 boardgame.
For the full discussion, follow this link to The Heretech blog.
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:
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.]
The "inbound social media" research grew to massive proportions, then underwent mitosis to become three separate documents, because it's difficult to encapsulate the discipline of using social media. Like any new field, social media are fraught with both opportunity and risk.
In the particular application that I was investigating, social media as a new source of requirements data, people can commit the same mistakes with this new source of information as they have with the old ones. For example, important players in the product development process often make decisions based on the customer with whom they last spoke. An equally common temptation is to listen to customers who echo what you want to hear, and disregard the rest.
In the best possible circumstance, you get a single person who appears representative of a larger user population, gives you credible insights, and even articulates their needs clearly. The obvious problem is that you're only listening to one person, who will never be 100% representative of the larger population. That's especially bad if the population contains distinct segments of people with different needs, habits, and skills, and you have to build something that fits the bill for more than one of these cohorts.
If you're not taking advantage of the opportunity to use social media to collect more data than you could through traditional, labor-intensive methods (for example, customer meetings), you're missing a big part of the reason for paying attention to social media in the first place.
And if you don't believe me, take a look at this item from The Guardian about how British businesspeople went gaga over a single 15 year-old intern's analysis of how teenagers use social media. To be fair, both traditional and social media contributed to the buzz around the document. But that's the point: you can repeat all the mistakes of old media when using new media.
[Cross-posted at The Heretech.]
