This is a roll-up of all Forrester blogs written for . Role-specific blogs are listed below. Visit Forrester.com to learn how we make successful every day.
A while back, I had a spirited exchange with someone who took a rather extreme position about the role of product management in software as a service companies. The less polite version: He staked out a silly position – just poll your customers about what to build, and eliminate the PM role altogether – so I felt obliged to refute it. With two additional years of research into SaaS and PM, it's worth returning to that contretemps for a moment.
Then, I argued that PM was necessary in SaaS ventures.
Now, it's clear that PM is not merely necessary but essential.
Product Managers Are Really Innovation Managers
If the sole responsibility of PM were requirements, as my foil assumed, a poll might replace a person, but only if you had no interest in the long-term success of your company. Polls are extremely useful tools, and it's far better to use them than not to. However, polls have their limitations: most obviously, as a tool for taking the temperature of the customers you have, they tell you absolutely nothing about the customers you don't have yet.
This week, I've already written a little about the need to go beyond polls to use other tools, such as serious games. In an upcoming post, I'll have more to say on the topic. For now, I'll just say that, in both business and politics, voting alone is not the ticket to ultimate success.
Hi, and thanks for stopping by. I joined Forrester just over a month ago and I plan to post here regularly with some thoughts on the ERP apps arena. I’m hoping this blog will serve as a place for us to exchange views, and I very much welcome your input.
As you know, Forrester is structured around roles, and I’m part of the analyst team serving the needs of business process professionals. My primary area of focus is enterprise resource planning software. I’m currently pulling together my research agenda for 2011, and I was wondering what top-of-mind issues you think I should be tackling.
At a high level, some of the areas I’m considering include:
Midmarket ERP.
SaaS ERP and PaaS.
ERP-flavored project management.
I’m also interested in hearing about midsize organizations and enterprises that have benefited from the successful deployment of one of the following:
SaaS ERP.
A two-tier combination of one vendor’s SaaS ERP integrating with another vendor's on-premise ERP.
There are blog posts that you can write without doing any prior work (he says, looking meaningfully at himself in the mirror), and then there are blog posts that require real work. This very interesting post about how the Facebook development organization operates is in the latter category. Instead of pointlessly summarizing the author's findings, compiled from sources who know Facebook from the inside, I'll add a few reactions:
If, as reported, the development team comprises about a quarter of the company's employees (and operations another quarter), that's an unusually high ratio for any tech vendor, whether or not it's in the software-as-a-service (SaaS) business. At salesforce.com, R&D comprises 15% of the company, which is high for the tech industry. Facebook's 25% R&D is staggeringly high.
Even though Facebook regularly confuses the heck out of the people with changes to security features, the company does pilot features before shipping them.
Facebook developers bear a lot of responsibility for their own code, across many dimensions of quality (design, testing, justification, etc.).
The ops team has a more gradual approach to deploying new code than it might appear.
As 2010 draws to a close, what are the key trends that customer management process professionals need to pay attention to as you finalize plans for next year?
Here are the top trends that I am tracking. My full report that spotlights our latest research will be published in January.
Trend 1: The Revenue Impact Of Poor Customer Experience Is Recognized
Our models estimate that the revenue impact from a 10 percentage point improvement in a company's performance, as measured by Forrester’s Customer Experience Index Score (CxPi), could be in excess of a billion dollars. Poor performers are particularly weak in being able to orchestrate multichannel interactions.
Trend 2: Business Process Management Extends To The Front Office
By extending business process management (BPM) to the front office functions, customer service organizations will improve the consistency of service delivered, elevate agent efficiency, personalize service, and meet compliance goals — at a cost that makes sense to the business.
Trend 3: The Business Value Of Social Customer Engagement Becomes More Evident
Winners of Forrester’s annual Groundswell Award spotlight how organizations are using Social Computing to innovate, such as: community-based marketing research techniques; engaging with customers through social media; energizing brand advocates; empowering communities to support customer self-service; and collaborating with customers during the product ideation and development process.
Two months ago, we announced our upcoming Forrester Forrsights Software Survey, Q4 2010. Now the data is back from more than 2,400 respondents in North America and Europe and provides us with deep and sometimes surprising insights into the software market dynamics of today and the next 24 months.
We’d like to give you a sneak preview of interesting results around some of the most important trends in the software market: cloud computing integrated information technology, business intelligence, mobile strategy, and overall software budgets and buying preferences.
Companies Start To Invest More Into Innovation In 2011
After the recent recession, companies are starting to invest more in 2011, with 12% and 22% of companies planning to increase their software budgets by more than 10% or between 5% and 10%, respectively. At the same time, companies will invest a significant part of the additional budget into new solutions. While 50% of the total software budgets are still going into software operations and maintenance (Figure 1), this number has significantly dropped from 55% in 2010; spending on new software licenses will accordingly increase from 23% to 26% and custom-development budgets from 23% to 24% in 2011.
Cloud Computing Is Getting Serious
In this year’s survey, we have taken a much deeper look into companies’ strategies and plans around cloud computing besides simple adoption numbers. We have tested to what extent cloud computing makes its way from complementary services into business critical processes, replacing core applications and moving sensitive data into public clouds.
One of the face palm moments I had while researching PM's role in SaaS was the timeline for platform and app development. The traditional path for on-premise products was platform first, then application. The cloud products flip this sequence, putting the applications first, then the platform. We're so used to seeing this pattern that it's easy to take it for granted, or mistake the reasons why it exists (hence the face palm).
There were two reasons for this evolution in the natural history of a tech vendor's portfolio. The first is distance from the customer. In an on-premise world, where there's a lot of geographic and organizational distance between the producers and consumers of technology, the collection mechanisms about customer adoption (infrequent "How ya doin'?" conference calls, cryptic bug reports, etc.) are labor-intensive. For however much effort you put into this research, the information returned is often incomplete, distorted, or just plain wrong. For example, the game of Telephone played among product teams, customers, and the salespeople in between often leaves PMs with more questions than answers about what a customer really wants.
Therefore, the product strategy for on-premise products have to accommodate a lot of uncertainty about how customers use the technology. While it's not the only reason for customization and custom application development, it's certainly an important one. Rather than guess wrong about customer adoption, on-premise vendors tend to say, "Here's a toolkit. Go build what you want."
With about 41,000 attendees, 1,800 sessions, and a whooping 63,000-plus slides, Oracle OpenWorld 2010 (September 19-23) in San Francisco was certainly a mega event with more information than one could possibly digest or even collect in a week. While the main takeaway for every attendee depends, of course, on the individual’s area of interest, there was a strong focus this year on hardware due to the Sun Microsystems acquisition. I’m a strong believer in the integration story of “Hardware and Software. Engineered to Work Together.” and really liked the Iron Man 2 show-off all around the event; but, because I’m an application guy, the biggest part of the story, including the launch of Oracle Exalogic Elastic Cloud, was a bit lost on me. And the fact that Larry Ellison basically repeated the same story in his two keynotes didn’t really resonate with me — until he came to what I was most interested in: Oracle Fusion Applications!
A recent conversation with executives from Clarizen, a software company in the work/project/task management realm, shows how profoundly SaaS can change the innovation process in technology companies. However, you won't get the most beneficial changes unless you're willing to make an investment.
During our briefing, I asked the CEO of Clarizen, Avinoam Nowogrodski, and the VP of Marketing, Sharon Vardi, whether being a SaaS vendor made it any easier to resolve the sort of questions that vex technology vendors. Their response: "Of course it does."
Here's one of those vexing questions: Why don't more customers move from a pilot to full adoption? The usual first answers blame someone else's department for the disappointing conversion rate: Your product stinks. Your leads stink. Your salespeople stink.
Round-robin finger-pointing like this thrives in an informational vacuum. If the only hard fact available is the conversion rate, marketing can accuse sales of presumed incompetence; sales can claim that the current bug count might have an effect on customer satisfaction; development can claim that it's bogged down in too many special requests from strategic customers; and so on.
During last August's Agile 2010 conference, I attended a session that used a board game to simulate the collaboration between developers and UX professionals. The object of the game was to coordinate the schedules of these two groups, who normally follow the beats of different metronomes. On top of that basic timing challenge, unexpected events complicated this dance between development and UX.
While this session does show a novel application of serious gaming (one of my favorite topics, in case you hadn't noticed), the interesting aspect of this session is that it happened at all. Until recently, UX was not a major concern for Agilists – or most people developing software, for that matter. The phrase, "And then we'll throw a UI on top of it," summarized the indifference of all too many development teams to UX concerns.
In the last few years, many teams have learned a new attitude. Instead of treating UX as a tarpaulin, thrown over the application to clumsily hold it all together, UX is as much a part of the system as the technical architecture or the application logic.
When you were a child, you may have played with a paper fortune teller (a.k.a. cootie catcher). By folding and unfolding this origami-like construct, you produced answers for questions you posed.
The topic of technical debt is a lot like the paper fortune teller: the more you unfold the topic, the more interesting observations emerge. Israel Gat wrote two recent posts (click here and here) at his blog, The Agile Executive, that illustrate the sort of costs that technical debt imposes. His second post focuses on the most conspicuous cost: The more you develop, heedless of the technical debt you create, the harder and harder it becomes to make further changes. While this may seem like an obvious conclusion, it's not one that has the impact on software development that it should. In their rush into the future, building code that is supposed to expand choices, many teams are actually constraining their choices.
For ISVs, technical debt has a lot of important ramifications. Here are just a few:
For startups, aggressive product road maps can be counterproductive. The more you develop, the more competitive your product, right? That formula seems obvious to most insurgent vendors, but there's definitely a point of diminishing marginal returns, when the cost of maintaining all that aggressively-developed code exceeds the company's ability to continue developing and supporting it.
A while back, 
There are blog posts that you can write without doing any prior work (he says, looking meaningfully at himself in the mirror), and then there are blog posts that require real work. 
Two months ago, we announced our upcoming 
One of the face palm moments I had while researching PM's role in SaaS was the timeline for platform and app development. The traditional path for on-premise products was platform first, then application. The cloud products flip this sequence, putting the applications first, then the platform. We're so used to seeing this pattern that it's easy to take it for granted, or mistake the reasons why it exists (hence the face palm).
A recent conversation with 
