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.
In the technology industry, there has been a rising chorus of questions about the role of the executive in Agile adoption. The recent acceleration of Agile adoption has a lot to do with the frequency of the question. Here's the other reason: Agile has been around long enough for a collective contemplation of lessons learned. In the after action reports about Agile implementations, executives regularly appear as major characters.
Given the ripple effects of Agile adoption throughout a technology company, it would have been surprising indeed if executives had played only a minor role. When the development team changes when and how it delivers new technology, everyone (Sales, Marketing, Support, Consulting, etc.) is affected in some way. With Agile adoption, executives who are already trying to bring departments into greater alignment face another potential source of misalignment. At the same time, as Forrester's research into Agile adoption in the tech industry shows, executives are less able to influence the priorities and activities in Development. If the executives don't really understand Agile, or haven't invested much in making this profound transformation work, an avalanche of backlash from the upper regions of the org chart is the usual result.
If you're still baffled, flummoxed, or concerned about Facebook's now-infamous privacy policies, here's a handy chart from The New York Times. (Thanks, Madiha, for the pointer.) While the diagram retains a neutral tone, it's hard to read the phrase 50 settings with over 170 options without having a "What the hell?!?" moment.
In defense of Facebook, they're no worse than many technology companies that devise confusing UIs, full of knobs and dials that users don't understand or use. These companies are still to blame for creating the circumstances in which a confusing UI is hard to avoid, so they're not completely blameless.
An apology to future generations
Here's where we venture into the idiosyncratic sub-culture of the tech industry, which is hard to understand if you've never been part of it. In spite of having big development budgets, a staff of seasoned professionals, and months to build a useful product, tech companies repeatedly build software that begs the question, "Daddy, why is your product so hard to use?" (Even weirder: usability is often inversely proportional to the price.)
The always incisive and effervescent April Dunford has a great post at her blog Rocket Watcher about the reasons why your start-up needs a website, before you have a product to talk about. I couldn't agree more, for the following reasons:
Customers are buying your business model, not just your product. Your product is one source of value to potential customers, but not the only one. A good case in point: the many SaaS start-ups that attracted a lot of initial attention, then quickly lost their users to competitive products. If there's more to keeping your customers than just the product, you'd better start communicating those other sources of value.
You need the opportunity to test your marketing. You won't get the communication right the first time, so market testing before the moment when you release the product is critical. Who wants to slave over a great new invention, only to discover that your marketing sucks?
You need early product feedback. All new products are based on a set of assumptions, some of which will be wrong. You can use your website to understand your potential customers better through the website. If there's something wrong with your personas, use cases, or any other guiding principles of prioritization and design, identify the problems now, unless you really enjoy re-engineering.
[More in a series of posts inspired by the "PM in an on-demand world" research that I've been doing. Here's the link to yesterday's thought du jour.]
During the research interviews about PM and SaaS, I was struck by how philosophical the conversations got. To the interviewees, SaaS was not merely a delivery vehicle, but a fundamental decision about their business. Bringing technology producers and consumers closer together forced many vendors to admit that they had a vague, incomplete idea of who adopts their products and services, why they do it, and how they do it. The subscription model led to many hard questions about how the company makes money. Marketers had to deal with a significantly modified value proposition, while simultaneously knocking down some new potential objections (most notably, security).
But those are just the most obvious consequences. The deeper we got into the research, the more I felt that we were talking about other ripple effects of SaaS, PaaS, and the other aaSes. At least a couple of Big Industry Trends – the kind that Very Serious People spend a great deal of time talking about – owe a great deal to SaaS. Without the success of SaaS, many organizations would not have been as open to embracing other changes. I'll mention just two of them, Agile and social media, among several that we'll discuss in the final report.
As promised, still more SaaS! Following an excellent day of discussion about PM in an on-demand world, I started over here at the fresh-out-of-the-shrinkwrap Forrester community site. Topic: On demand is a business model choice, not just a delivery mechanism. Discuss.
I'm working on a report about the role of PM in an on demand setting (SaaS, PaaS, and all the other aaSes). As often happens in discussions about PM, the role is a window into many bigger issues. Since their responsibilities span both business and technology, product managers and product marketers find themselves in the middle of many fundamental questions for technology vendors, such as, How often should we deliver something new to our customers?
That question has two sides: (1) how often do customers want to receive something new, and (2) how often can the vendor deliver it. Both questions can be difficult to answer. Customers often want tech vendors to deliver value faster, but they also complain if the changes happen too fast. Vendors know that they could deliver new technology every time they do a build, but they also know that the entire company (sales, marketing, support, etc.) won't be able to keep up at that pace. There must be some golden mean between the pace of technology production and consumption, but what is it?
By shortening the distance between producers and consumers, on demand, and SaaS in particular, has made it easier to reach a meaningful answer. The on-premise model creates a very long value stream between the development team at the beginning of the technology adoption process, and the users at the very end. In fact, adoption is, at best, a blurry image on the distant horizon of the development team's field of vision. Since the success of a development team's work products depend on its adoption, lack of information about adoption is not an information gap, but a yawning chasm.
This just in: a very interesting case study about Sterling Commerce. The company used portfolio management to align its product strategy, and gave a revamped PM organization greater authority over that portfolio. It's another good example of how technology companies are recognizing that product managers and product marketers are a strategic resource in their organizations, and a natural ally of executives who are trying to increase alignment.
A lot of my recent research – about SaaS/PaaS, Agile tools, requirements tools, and innovating with your channel – share a common conclusion: successful technology vendors see integration as more than just a necessary evil. Here's why.
Business problems drive technology adoption You can see this principle in action in the requirements tools market, which in the last decade has grown larger and more complex. Teams use these tools to address more than one type of requirements-related challenge, so it's easy to see why the tools themselves are now as diverse as as Micro Focus (née Borland) Calibre, Atlassian JIRA, Ravenflow RAVEN, and VersionOne's Ideas Management module. If your problem is, "People don't like using our product," you might look at a visualization tool like iRise to shorten the feedback loop, leading to better design decisions. If, instead, your problem is, "We don't have a good business justification for what we build," you might look at IBM Rational DOORS to evaluate the pros and cons of alternative scenarios for what goes into the next release.
Tomorrow, May 6, I'll be talking about the way in which product managers and product marketers in the tech industry are helping executives fix misalignments in their company. The technology goes here, the business goes there, and PM is in the thick of it.
This alliance between PM and executive management pushes PM into an increasingly strategic role. As a result, PM teams are changing their job descriptions, departmental structures, to-do lists, and objectives. Some investment is required, but the payoff is big.
Ryma Technologies is the organizer and sponsor of this webinar as part of their CxO series, scheduled from 12 to 1 EDT / 9 to 10 PDT. You'll find more information at this link. See you there.
In the tech industry, the "tell me a story" approach to product requirements – personas, user stories, use cases, visualizations, etc. – has made a bigger impact than many people may realize. Not only has this new type of content resolved many problems that existed with requirements, but it has led to a brand new way of looking at requirements. By thinking of requirements as stories, it's easier to figure out what kinds of requirements we need, and why we need them.
A tale of two mini-series
The fundamental question when writing any kind of story is, "What are you trying to convey?" I was thinking of exactly that question while I was watching the HBO mini-series The Pacific. I probably wasn't the only person to expect The Pacific to be the same kind of story as Band Of Brothers, just transplanted from the European to the Pacific theater of operations. I was wrong.
As it turns out, the new series has a very different kind of story to tell. Band Of Brothers depicted the experience of combat, in (literally) gory detail. While The Pacific does have more than enough battle scenes, it also tries to show military life beyond the battlefield. For example, one episode focused on the painful romantic choices that young people stationed in faraway lands have to make. Another episode depicted something rarely seen in war movies, the psychiatric casualties of war. Far more than Band Of Brothers, The Pacific shows more of the atrocious things that young men under brutal, terrifying conditions are capable of doing.