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.)

[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.

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.