The Forrester Blog For Technology Marketing Professionals
This blog is a roll-up of all the posts from analysts who serve Technology Marketing Professionals. Individual analyst blogs are listed below. Visit Forrester.com to learn how we make Technology Marketing Professionals successful every day.
All three parts of the series on social media as a new source of requirements data are now published. The first shows how product teams can use social media to create reach more accurate conclusions than traditional sources of requirements (customer visits, enhancement requests, customer advisory boards, etc.) alone can provide.
The second document distills the lessons learned from attempts to use social media in this "inbound role" into a methodology, PLOT (persona, location, options, test). Since the choice of which social media can best answer particular kinds of questions isn't immediately obvious, I devoted the third document to that topic alone.
During the research for this series, it became glaringly obvious that there is a major dividing line in the type of information that product teams collect and analyze:
Some recent statistics on Twitter show how the reality can be more convincing that the hype. Do we never learn that the eye-rolling, "Oh my God it's going to change the world" enthusiasm for a new technology buries that technology's real success in an avalanche of hyperbole?
Memex, a company that makes software for police departments, is a great case study in use case-based product design. If the requirements didn't start with detailed insights into police departments work, the application might be just another set of UI components with a database behind them.
Google's announcement about the Chrome OS raises a whole lotta questions about the future of the operating systems market, or what an operating system really is, or how the Chrome OS fits into Google's larger strategy. As interesting as these questions may be, we also have very little foundation on which to answer them.
I have a much longer post here about the reasons why we can't reach any conclusions yet. Here's the short version:
Netbooks, which play a significant role in the prospects for Chrome OS, can be both a blessing and a curse.
You could say the same thing about the degree to which the Chrome OS depends on the Chrome browser.
Users may not see the compelling reasons to use this new platform, or even understand it fully.
Governments may not be thrilled about the implications for competition and privacy.
There's still a lot of murkiness about cloud computing in general that this does nothing to dispel.
For people in product management and product marketing, organizational questions—for example, Where should we report? What specializations of the PM role seem to work?—are always high on the list of hot topics. That statement is true of this week's Heretech podcast, to be posted later today, in which Saeed Khan and I spend a good deal of the interview discussing these issues. It's also true of the research that I do, including a recent study that revealed some interesting results about the relationship between product management and product marketing.
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.]
During a briefing from Microsoft's xRM team, the question of how to integrate structured and unstructured data arose. If xRM (the Dynamics platform) is good at the structured stuff, and SharePoint is good at unstructured content, what's the right way to bridge the two?
Back in my Oracle days, we faced exactly the same question. At a technology level, there's no obvious answer. Bring together two development teams (the structured and unstructured specialists), and you'll first get a lot of technical-level discussions. How should security work? What API changes might be needed? How will metadata span the two kinds of information?
Unfortunately, there's no immediately obvious answer to these questions. In fact, the options are so broad, and the risk of technological quagmires so great, that the endeavor might easily grind to a halt. People ponder the options, argue over which one is best, go back and ponder some more...
Stepping out of the shadows, the Cranky Product Manager and I talked about the sources of crankiness in the technology industry in this week's Heretech podcast. The conversation also ranges from the reasons why product management is a "wretchedly awesome" job, to how overzealous Agile advocates hurt their cause.
To maintain anonymity, I masked the CPM's voice. A couple of listeners have already compared the effect to the Cylon voice effect in the old Battlestar Galactica series. I'm not sure if the CPM would be flattered or mortified by that comparison.
In the same podcast, I also review a movie that you've never heard of, but which has a lot of relevance for a recent hot topic in the PM blogs.