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.
As readers of this blog know, I have a keen interest in serious games. Among other virtues, they provide a way to deal with tough circumstances by changing the way team members interact. In an upcoming research document on the subject, I relate the story of a development team that had to rewrite a creaky old application from scratch. Which features did the team need to re-implement right away? By running a serious game with the stakeholders, the team pinpointed which features were essential and why.
[With apologies to all those of you who had already read this, I'm re-publishing this as the Forrester gremlins ate my previous post.]
For the past few years, many eBusiness and channel strategy executives in financial services have had a nagging sense that today's websites would be rendered obsolete as new technologies emerged or younger consumers developed radically different behaviour patterns. We think that time if fast coming upon us.
For the past six months we've been working on our vision of the Next Generation of Digital Financial Services, led by my colleague Alexander Hesse and inspired by the work of leading eBusiness teams worldwide. Although our vision is not an exact description of how all digital financial services will evolve, given the wide variety of markets that eBusiness executives operate in and the different strategies of their firms, we think the next generation of digital financial services will be characterized by five things:
Simplicity. Making it easy for customers to achieve their goals.
Ubiquity. Interacting with customers wherever they want.
Personalization. Making the entire experience relevant to individual needs.
Empowerment. Enabling customers to take action by themselves.
Reassurance. Providing human help whenever it adds value.
He's absolutely right. Adoption is often unrelated to the potential value of technology or the intensity of a person's need for it. An entire branch of social science started because farmers wouldn't always adopt better-producing seeds and people living in areas at high risk of an epidemic wouldn't take the medicine needed to prevent infection. Many doctors don't like electronic medical records because they're used to pen and paper. This sort of resistance can arise from a variety of sources, many of which are not strictly "political" in the way we commonly use that word.
While that might be an easy principle to accept, here's a corollary that's much harder one to swallow: Nobody is immune. If you think you're somehow smarter about technology decisions than a farmer, think again.
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.
Recently, the city of San Jose used a serious game, Buy A Feature, to address some tough budgetary challenges. Since serious games have relevance across a wide range of contexts, including application development and delivery, it's worth relating one anecdote from San Jose's exercise that demonstrates the importance of having a shared vision.
I was a "facilitator" for this exercise, which involved more than 100 members of the community, plus a couple dozen city officials, including Mayor Chuck Reed. According to the ground rules of this exercise, organized by Innovation Games, each group of several community members had to decide which municipal projects (libraries, parks, school programs, fire, police, etc.) to fund and which not to. These "wish list" items formed List A. A complementary List B included other projects that the participants could decide to cut and then shift the money into projects from List A.
Every participant had a small amount of money, but not enough to buy anything from List A outright. Funding anyone's favored project, therefore, required investment from more than one person. Money from any List B project was available only if everyone at the table agreed to cut it.
For the past few years I have watched enviously as the Finovate online financial technology show has gone from strength to strength in San Francisco and New York. So I was thrilled to hear that Finovate was coming to Europe and today I was lucky enough to go along to the show in London.
For those of you who aren’t familiar with Finovate, it’s a fast-paced format with seven-minute live demos and pitches from 35 financial technology vendors. It’s produced by Online Financial Innovations, the people behind the excellent NetBanker blog.
During one of my gigs as a product manager, an executive in our company was overjoyed to have a US Defense Department client. He was eager to land a reference customer, but he fundamentally misunderstood how easy it would be to get a military organization to join the ranks of success stories. He wrongly assumed, in this very hierarchical organization, successful adoption of our collaboration tool was the simple process of (1) the general in charge ordering people to use it, followed by (2) people under his command dutifully using it. The military doesn't work that way, in large part because, when faced with a bad order that might kill them, military professionals learn how to wriggle out of these diktats. (Which is why there's a fine line between initiative and insubordination.)
Even if our executive's assumptions about how the military operated were correct, that formula might spell doom for the project. What happens when the general in charge moves on to another post? No assignment is forever, and the next officer in charge might have a far lower opinion of our product. The crisis might happen earlier, if the current general got impatient with the progress of the project. Fearful of these potential outcomes, this executive bet the entire project on maintaining good relations with the general and his immediate subordinates, including the irascible project lead, whose view of technology adoption was summarized in his comment during a meeting with us: "Users are stupid, so they don't know what they want."
[For earlier posts in this series, click here and here.]
Imagine that you're dining at a new Italian restaurant that just opened in your neighborhood. You've heard that the chef is well known and widely respected, so you're expecting a great first experience.
You sit down, and the waiter hands you a menu. Actually, it's not a menu, but a listing of all the top-quality ingredients in the restaurant's refrigerator. Some ingredients suggest the kind of recipes that the chef might prepare: For example, the veal shank might be destined to become Osso Bucco. Since you're not an expert in Italian cuisine, it's hard to guess what kind of recipe might require some of the other ingredients (rabbit, goat, boar, etc.).
The waiter is no help. He'll dutifully return to the kitchen with the ingredients you tell him the chef should prepare, but he won't tell you if that combination will transform into a delicious meal or an indigestible lump.
In this scenario, chances are slim that you'll get the sort of dining experience you expected. If you were hoping for an experience you've never had before, the kind that a world-class chef could provide, the odds are even worse.
Sadly, this is exactly the way in which technology companies have pitched their products. Rather than explaining the experience you should have, they leave it up to you to figure out what experience might be possible, given the ingredients (features and functions) available in the product. This approach has two pernicious consequences:
Scott Sehlhorst has an outstanding post at Tyner Blaine about documentation. Not technical documentation, but the information you write down to make the development process work. By work, I don't mean just the activities within the development team, but also the rest of the value chain, too.
Scott is talking about the role of documentation in Agile development, but his points are relevant to any team, Agile or not. Agile creates greater sensitivity to the issue, since too much documentation can cripple the team's velocity. Of course, the lack of documentation can damage the team's success:
Some collaboration is transient – communication happens right now, and is only important right now. Other communications are persistent – the collaboration happens right now, but we need to remember later what we agreed upon and why.
Scott's post is a great illustration of what I was discussing yesterday about treating requirements as conversations, not dictionaries. Requirements are part of the conversation, but a lot of the same content that defines what to build, and why, gets recycled later when you need to describe what you built, and why. For example, personas get passed around quite a bit among groups. Perhaps the originate in the development team, but people in sales, marketing, support, and other downstream groups have a keen interest in that information.
Forrester’s recent book, Empowered, describes the type of technology-based innovation by frontline employees that can cause nightmares for enterprise architects. New tools for business innovation are readily available to anyone, ranging from cloud computing and mobile apps to social networks, scripting languages, and mashups. Faced with long IT backlogs and high IT costs, frontline employees are building their own solutions to push business forward.
What worries architects is that (1) solutions built with these new tools — with little or no vetting — are being hooked to enterprise systems and data, opening potentially big risks to reliability and security, and (2) the siloed, quick-hit nature of these solutions will drive up ongoing costs of maintenance and support. Traditionally, architects use enterprise standards as their primary tool to ensure the quality, efficiency, and security of their organization’s technology base. However, when applied in the typical “lockdown” fashion, standards can stifle innovation — often because vetting a new technology takes longer than the perceived window of business opportunity.
To deal with these conflicting pressures, architects must forge a new equation between responsiveness and technology control. The business value of responsiveness, combined with the typically limited size of enterprise architecture teams, means that most organizations cannot wait for architects to vet every possible new technology. Thus, you must find ways to use architecture to navigate the tension between the business value of responsiveness and the business value of a high-quality technology base. The key is to build innovation zones into your architecture; Forrester defines these as:
As readers of this blog know, I have a keen interest in serious games. Among other virtues, they provide a way to deal with tough circumstances by changing the way team members interact. In an upcoming research document on the subject, I relate the story of a development team that had to rewrite a creaky old application from scratch. Which features did the team need to re-implement right away? By running a serious game with the stakeholders, the team pinpointed which features were essential and why.
Colleague Mike Gualtieri, king of the sharp (
A while back, 
Recently, the city of San Jose used a serious game, 
During one of my gigs as a product manager, an executive in our company was overjoyed to have a US Defense Department client. He was eager to land a reference customer, but he fundamentally misunderstood how easy it would be to get a military organization to join the ranks of success stories. He wrongly assumed, in this very hierarchical organization, successful adoption of our collaboration tool was the simple process of (1) the general in charge ordering people to use it, followed by (2) people under his command dutifully using it. The military doesn't work that way, in large part because, when faced with a bad order that might kill them, military professionals learn how to wriggle out of these diktats. (Which is why there's a fine line between initiative and insubordination.)
Scott Sehlhorst
