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.)
A new business model is emerging, and it depends heavily on software development. Many companies are dropping many of the traditional barriers between product development and customers. Without investing in software development, these efforts, no matter how well-intentioned, will have a better chance of failing than succeeding.
The simplest term I can concoct for this business model is "the transparent company." There are other defining characteristics of this corporate strategy, such as confidence in the ability to execute, and a very different sort of relationship with customers. However, as companies have been decidedly opaque to their customers, any transparency is a striking detail in itself. Hence the term "transparent company."
Wave Hello To The Engineer Fixing Your Bug
Here's an example of what I mean. I don't have to be a customer of Atlassian to know what issues Atlassian's engineers will fix in the next release of their wiki product, Confluence. That information is publicly available at this link. Diving into an issue at random — I chose "Database deadlock during initialisation of plugins in sql server" because it sounded fairly dire — I can see which engineer is working on this issue, Don Willis. I can even see the daily activity stream for Don Willis as he works on this issue and other projects.
Every year, people talk about the future of IT, which is shorthand for, "Some big changes may be in the works." In the last year, we've had to revise that sentence to read, "Some big changes are definitely in the works." Agile practices will be a critical tool for making this transition successfully, but not because of velocity. At least, that won't be the primary virtue of Agile that helps with the transition.
One of the Founding Fathers of Agile, Jim Highsmith, recently commented on his blog about an MIT study that surveyed one face of this mountain of change:
The implications of these changes in emphasis could be significant in terms of mindset and capabilities in and out of IT departments. From a focus on standardization, optimization, and cost control, the focus shifts to innovative uses of emerging technologies such as social media, cloud computing, and mobile devices; speed to market; flexibility to follow changing opportunities, and building new products and services.
We've been talking about the next stage of application life-cycle management (ALM) for several years now. As my colleague Dave West argued, the vision of ALM 2.0 is clear, compelling, and comprehensible. While ALM tools might have a ways to go to fulfill this vision, they have made significant strides in one particular area: integration among tools, whether or not they come from the same vendor. The momentum for ALM integration isn't unique, propelled by the same forces that make integration the killer app in other segments of the software market (CRM, content management, collaboration, etc. etc.). Tools provide potentially valuable capabilities, but these capabilities don't map exactly to the way people work.
The Work Defines The Tool, Not The Other Way Around
The primacy of work over tools explains why ALM 1.0 died quickly from its own success. Having convinced app dev teams of the value of point solutions for task management, planning testing, requirements, release management, and other functions, the obvious question on practically every customer's mind was, "What other tools might help us?" We should be careful about how we understand that question, which is not synonymous with, "What other activities might we make easier or more successful?" The tools are, more often than not, part of the same activity. Planning, for example, should identify risks that shape what requirements you write and what tests you build.
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.
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.