Posted by Tim Walters on March 18, 2011
Hype accompanies technology innovation like a shadow. When the inventor of fire was touting its benefits (“Makes mastodon meat more tender!” “Creates a romantic ambiance!”), there was no doubt someone at the back of the cave shouting, “Ach, it’s all just hype!”
Unfortunately for the critics of hype, people tend to remember only when they are hilariously wrong. A 1995 Newsweek article titled “The Internet? Bah!” mocked the proponents of the web: “Nicholas Negroponte, director of the MIT Media Lab, predicts that we’ll soon buy books and newspapers straight over the Intenet. Uh, sure.” Borders certainly wishes that prediction had been accurate.
The accelerating pace of change creates ever new opportunities for the hype police to look foolish, faster. Facebook will suffocate in its superficiality. The iPad will be an embarrassing flop. Twitter is just plain stupid.
In the software realm, hype is often associated, or even equated, with marketing. In one sense, it’s true that marketing is hype (and I say this as a former software marketer). Vendor claims about the benefits of their products are almost always unrealistic -- because they are usually based on abstract, imaginary, and ideal use cases. The challenge for any vendor selection process is (in principle) to separate the abstract scenario from the real benefits achievable given your specific business environment and goals. POST is a tool to help you determine and measure that delta.
POST is the aspirin for your hype headaches. Forrester's Josh Bernoff developed the POST methodology in 2007 in response to questions from our clients about how to get involved in consumer social media. What we noticed is that by focusing on the technology or platform, they’re often asking the wrong question first.
Technology is the “T” in POST. That means that while the selection of the appropriate technology is certainly important, there are other questions – about People, Objectives, and Strategy – that need to be addressed first. Thus we’ve applied POST to help organizations back up and reset their discussions around social media, smartphones, and iPads. In 2010, my Collaboration and Content colleague Ted Schadler realized that POST applies extremely well to internal-facing collaboration and Information Workplace discussions, which he described in “POST: A Systematic Way To Define Your Collaboration Strategy.”
As Ted explains, in the context of collaboration the four step POST methodology consists of:
1. People. Start by understanding what employees actually use and need today. Don’t guess and don’t rely on anecdotal interviews. Instead, start with a quantitative assessment.
2. Objectives. With that baseline of understanding in place, next decide what your business goals are. You will need to build a decision council that includes IT and business to help you do this.
3. Strategy. The strategy part of this planning process means mapping the business goals to specific collaboration scenarios that you can actually improve — no tools yet.
4. Technology. The last step is to figure out which technologies improve your most important collaboration scenarios. Choose cloud services if they make sense; on-premises if not.
As vendors increasingly target business users (and as many new tools originate in the consumer web and appeal directly to users), IT struggles with a new form of hype. As one Content and Collaboration professional recently told us, “I used to hate constantly meeting with vendors trying to sell me stuff. But now the vendors go directly to the users, convince them they need the tools, and I end up with my own colleagues demanding I buy this “great” stuff that is “exactly what they need.” It’s even worse!”
POST deflects this kind of demand. “You think it’s just what you need? Ok, let’s run the POST methodology and see if this technology is appropriate for our people, objectives, and strategies.” If the answer is yes, you’ve cut through the hype and verified real business benefits. If the answer is no, you’ve demonstrated precisely why, rather than just refusing to give users what they want.
What do you think? Can POST (or a similar methodology) really help inform, vet, and improve your technology decisions?