12 Secrets of Digital Transformation: Part 5

Secret #5: Products are not projects — they are a way of life

One of the major differences between a post-transformation “product” company and a pre-transformation technology-aided business is that the conventional company thinks in terms of projects. The product company thinks in terms of versions, enhancements and maintenance of the product.

A “project” starts and stops. Work on a “product” never stops. A product is enhanced and evolved continuously, in a never-ending work stream. In fact, the more continuous that work stream is, the better: supporting an uninterrupted cycle of work is an explicit goal of many Agile methodologies.

The investment horizon for a product has a timeframe of years, not weeks or months. The team who works on a product also stays pretty much the same over a long period of time—the team is not formed then re-allocated, as in a project. This is because, simply, a “product” is software used to drive the company’s business and revenues. Unless the company goes out of business—or changes businesses—the need for a product is constant. A project, on the other hand, addresses a one-time need with a largely one-time solution. Since the defining characteristic of a product is that it drives revenue over a long period of time, it makes sense to nurture, sustain and enhance it on an on-going basis. If engineering efforts start and stop, the product will predictably suffer from incompatible waves of technologies, and it will lose its coherence.

A product is driven by a roadmap that is largely independent of external events, even major ones such as acquiring a new large customer. Many software businesses, even very large ones, do indeed need to respond when they win a large customer or deal. These customers often demand new features, new integrations, and other changes on their own timetable—which may or may not coincide with the product roadmap. In the healthiest product companies, these customer demands are accommodated by adding or changing priorities on the roadmap, not by dispensing with the roadmap altogether. Those changes that are not useful for the “base product” are done by professional services using supplied customization, integration and configuration “hooks” in the base product. In other words, acquiring a new customer becomes an exercise in how the core product can be improved and configured, rather than how it can be customized or “one-off” features added.

Budgeting improvements to a product as “projects” is generally not a good idea because of the sustained effort required to keep the product maintainable and supportable. Also, because products tend to be complex, you will see major productivity and quality improvements by having a continuously staffed team who knows how things work and who understand best practices for your system. Budgeting product work as a sustained effort with potential peaks and valleys for enhancements generally proves most effective. Also, if you need it, create a separate “professional services” (PS) organization who configures and customizes (via plug-ins and integration points) the product for a given customer, on the customer’s timetable. This PS team is generally project-based.

It’s hard for many companies moving through digital transformation to move from a “project” to a “product” mindset. The way work is budgeted, communicated and planned needs to change. However, this mindset shift is core to your digital transformation into a product company. By thinking and treating the software product as core to your business—rather than peripheral supporting infrastructure—you’ve taken a large step in your transformation journey.