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.
The Oil And Gas Information Technology Innovation Dilemma
The hydrocarbon logistics chain of natural gas and crude oil connects globally distributed exploration and production sites with industrial and private consumers via pipelines, tankers, rail cars, and trucks with massive intermediate buffering storage and conversion facilities (tank farms, refineries, gas plants); it is the lifeblood of our energy supply chain today and for the coming decades.
More than 75 million barrels of oil and 300 billion cubic feet of natural gas are produced, transported, and consumed all over the globe — every day. Along the complex transportation chain, these special bulk products, both liquids and gases, are transferred between the different modes of transportation, resulting in a number of challenges based on complex measurements of product volumes and masses:
Measurement accuracy. In an ideal world, we would always determine the mass of crude oil and natural gas at each measurement point; however, due to the large quantities involved, weighing is possible only at the very end of the logistics chain. Consequently, we have to live with measurement data that typically carries an uncertainty of 0.1% to 0.5 %, depending on the measurement devices’ intrinsic accuracy.
Practically everyone who visits the Vatican stops to take a picture of the Swiss Guards. Ditto for the Queen's Guard at Windsor Castle, the Royal Life Guards at Rosenborg Castle in Copenhagen, and the Evzones at Greece's Tomb of the Unknown Soldier. Those multicolored uniforms may not have a place on the modern battlefield, where camouflage is far more important than panache, but they do attract the tourists.
If, by this measure, these ceremonial units have some value (albeit none militarily), why not have more of them? You could post the newly created Sartorial Guard at tourist locations that haven't been attracting enough foot traffic lately. And who knows, they might even attract more recruits into the real military. (Though I'm not sure what the career path is once you've held the rank of Feldweibel in the Swiss Guards.)
Obviously, I'm not being serious. Once you start manufacturing new ceremonial units, you cheapen the brand. You don't need more than one as a "loss leader" in the military, and there's no need to get the people who actually fight up in arms. Figuratively, that is.
Here's why managing a portfolio is critical for managing products. It wouldn't be hard to find some enterprising "champion" for a new Swiss Guards-ish unit who was willing to sew the uniforms and stand around looking fierce. (We call them re-enactors, and we don't put them on the public payroll.) No matter how much attention they attract, they'll still be a failure from a national perspective.
I'm a dedicated podcast listener, and one of my current favorites is the BBC's In Our Time. The host, Melvyn Bragg, selects a bewildering array of topics, such as Daoism, the Battle of Bannockburn, random numbers, the medieval university, and metaphor. A recent episode about the Industrial Revolution unexpectedly and unintentionally turned into a very lively discussion about the sources of invention, a topic that's near and dear to application development and delivery professionals.
Here's the punch line to this discussion: Not everyone's brain is ready to conjure up new ideas, so you need a catalyst. And here's the connection to this blog: serious games can be that catalyst. Our brains regularly need to be shaken up this way, during both those magisterial moments when we're trying to look over the horizon and the more desperate moments when, as I discuss in a new study, we need to dig ourselves out of a hole.
During my research for the just-published document "For Developers, Dog Food And Champagne Can't Be The Only Items On The Menu," I had an interesting conversation with the team at Adobe that handles internal pilots, which in their case entails more than just putting the next version of an Adobe product on the network for people to try. Instead of the typical "spaghetti against the wall" approach to "eating your own dog food" (to mix food metaphors), the Adobe team actively looks for use cases that fit the product. If a product like Flex or Photoshop is a tool, then it should be the right tool for some job. (And if you can't find any use for the software, you're definitely in trouble.)
This approach might require additional work above the "spaghetti against the wall" approach, but it definitely has dividends for many different groups. The product team identifies functionality gaps or usability flaws. Marketers and salespeople have a much easier time figuring out what to demo. As a result, Adobe runs a better chance of both building technology that's compelling, and then explaining what's compelling about it to potential customers.
Recently, I spoke with a major airline about their adoption of Agile, which they considered critical for a major customer loyalty project. Based on previous experience, the dev team expected the business users involved in this project to move slowly, so they saw Agile as a strategy for being ready to pounce on any opportunity to make progress. How slowly? The current estimation for the project's completion was....[drumroll]...five years. Now that's a customer loyalty program ensured to be left with just the most loyal customers imaginable.
As hair-raising a situation as this might be, it's hardly unique. App dev teams contributing embedded software elements to hardware products must time their deliverables to arrive at key landmarks in the overall release schedule. Compliance requirements weigh down software development with extra documentation and validation. Flawed requirements force teams to go back to the drawing board. Dev managers live and die by the schedule, and there's always something that could jeopardize the schedule. Development is pretty pointless unless someone delivers the bits and bytes, but dev ops still remains a relatively mysterious and unpredictable process for dev teams, over which they have little control once they throw their code over the wall.
A big part of my research agenda for this year is productization. Many app dev teams see productization as a way to innovate better, achieve more sustainable results at a lower cost, deal with some of the tough challenges downstream, and in general lead a happier and more productive life. The allure of productization varies across different types of organization, as do the approaches. Therefore, to do the product justice, we're going to look at five different settings in which app dev teams are striving to productize their work:
Companies that have customer-facing applications on their websites. The classic example is online banking, but there are plenty of others. Some of these applications are tools for existing customers, while others are mechanisms for interactive marketing.
IT departments. In this case, productization is a way to improve the long-term return on technology investments, by treating them as products and assigning them a product owner.
Services companies. Productization may reduce inefficiencies in developing and delivering offerings, as well as marketing and selling them.
Embedded software. The ubiquity of software as a component of a larger product (car, medical device, etc.) creates new challenges in defining what the product is, and where software development fits into it. That's one reason why PTC, a product lifecycle management (PLM) vendor, was interested in acquiring MKS. (Other than their shared interest in TLAs.)
Product strategists at Mars, Incorporated are experimenting with mass customized offerings quite a bit. In addition to their build-to-order customized M&Ms offering, their subsidiary Wrigley has just rolled out MyExtra gum, which prints personalized wrappers on Extra gum packs.
Product strategists at Wrigley declined Forrester’s recent request for a research interview, but judging from the myextragum website and their press release, the offering is a really interesting example of a creatively mass customized product strategy. Why? Product strategists at Wrigley have:
Redefined the product using customization. Myextragum isn’t just gum with a customized wrapper. Instead, it’s a greeting card (Mother’s day, birthday, other holiday) or a business card (to be given to patrons) plus gum. Wrigley is moving into a non-adjacent, previously orthogonal product market in one fell swoop. That’s aggressive and creative.
Justified the higher price point. At $4.99 – though the price reduces with bulk orders – the product is pretty expensive for a pack of gum. But, again, it’s not a pack of gum – it’s a greeting card or business card that also has gum inside. This pricing makes sense when you think of the price of Hallmark cards or custom business cards.
Mass customization has been the “next big thing” in product strategy for a very long time. Theorists have been talking about it as the future of products since at least 1970, when Alvin Toffler presaged the concept. Important books from 1992 and 2000 further promoted the idea that mass customization was the future of products.
Yet for years, mass customization has disappointed. Some failures were due to execution: Levi Strauss, which sold customized jeans from 1993-2003, never offered consumers choice over a key product feature – color. In other cases, changing market conditions undermined the business model: Dell, once the most prominent practitioner of mass customization, failed spectacularly, reporting that the model had become “too complex and costly.”
Overall, the “next big thing” has remained an elusive strategy in the real world, keeping product strategists away in droves.
Both Agile and Lean have an ethos that, at least on paper, acknowledges the noble failure. "Fail fast" is part of the Agile credo. Although it sounds as though it contradicts the "fail fast" approach, Lean's admonition to delay decisions for as long as possible is actually very complementary. The first draft of anything, from automotive design to software architecture to student papers, always contains elements that could be improved or that are just flat-out wrong. Practices that sit beneath the banner of Agile or Lean, such as set-based development, provide further ways to make mistakes and overcome them.
To a large extent, these practices deal with the easier varieties of failure. Prototyping a feature quickly, so that you can invite feedback when you actually have enough time to respond to it, is an extremely valuable technique for lowering the risk that you build something the wrong way. You need a different approach to identifying the features that you should not build, period.
Over the weekend, I attended the Silicon Valley Product Camp, one of the yearly un-conferences for product managers in the US, Canada, and beyond. During one of my sessions, a look into the role of product management in the innovation process, I posed some basic questions to the audience. What is innovation? As a group, we had lots of potential definitions. What is a product? This question elicited almost no answers.
That result wasn't a surprise. For years, we've been hearing about how difficult it is to define product management. Perhaps that has something to do with the difficulty of defining the thing that product managers manage. We think we know products when we see them, in much the same fashion as Justice Potter Stewart famously defined obscenity, but we're a bit challenged to put into words exactly what they are. We can easily define them in the negative, such as consulting offerings that aren't products or IT projects that aren't products. We've all heard that products have life cycles, which isn't nearly as Darwinian as one might expect. (Many ideas that don't deserve to become products, do. Many that deserve to die, don't.) But, if pressed, we're at a loss to define what products are.
The hydrocarbon logistics chain of natural gas and crude oil connects globally distributed exploration and production sites with industrial and private consumers via pipelines, tankers, rail cars, and trucks with massive intermediate buffering storage and conversion facilities (tank farms, refineries, gas plants); it is the lifeblood of our energy supply chain today and for the coming decades.
Practically everyone who visits the Vatican stops to take a picture of the Swiss Guards. Ditto for the Queen's Guard at Windsor Castle, the Royal Life Guards at Rosenborg Castle in Copenhagen, and the Evzones at Greece's Tomb of the Unknown Soldier. Those multicolored uniforms may not have a place on the modern battlefield, where camouflage is far more important than panache, but they do attract the tourists.
I'm a dedicated podcast listener, and one of my current favorites is the BBC's In Our Time. The host, Melvyn Bragg, selects a bewildering array of topics, such as Daoism, the Battle of Bannockburn, random numbers, the medieval university, and metaphor. 
During my research for the just-published document 
[For the first part in this series, 
A big part of my research agenda for this year is productization. Many app dev teams see productization as a way to innovate better, achieve more sustainable results at a lower cost, deal with some of the tough challenges downstream, and in general lead a happier and more productive life. The allure of productization varies across different types of organization, as do the approaches. Therefore, to do the product justice, we're going to look at five different settings in which app dev teams are striving to productize their work:
Both Agile and Lean have an ethos that, at least on paper, acknowledges the noble failure. "Fail fast" is part of the Agile credo. Although it sounds as though it contradicts the "fail fast" approach, Lean's admonition to delay decisions for as long as possible is actually very complementary. The first draft of anything, from automotive design to software architecture to student papers, always contains elements that could be improved or that are just flat-out wrong. Practices that sit beneath the banner of Agile or Lean, such as set-based development, provide further ways to make mistakes and overcome them.
Over the weekend, I attended 