I’ve recently stumbled upon a few companies that are thinking seriously about or are in the process of making the transition from a software services/project-oriented business to a software product business. I must admit during most of my career this type of evolution was not on my radar at all. I was a consultant for several years in the 90s, but for a major software vendor (IBM/Lotus) building customer-specific solutions on top of an established software portfolio. I didn’t have much insight into more traditional consulting firms that develop client-specific software from the ground up as part of consulting projects. It turns out that transitioning from a services organization that delivers software assets as part of a project to a company that ships products can be far more challenging than it might first appear. This change also raises plenty of fascinating questions about all kinds of software development topics, including software product management.
As these consulting/services organizations rationalize software re-use over time, they sometimes reach the conclusion (for various motivations I’ll address later) that they would like to ship “proper” products rather than customer-specific software assets. Although transitioning from a services-based business model to shipping products can affect virtually every aspect of a development organization, I’ll first focus on product management in future posts after laying a little ground work. Truth is, this topic is so complex and rich, I could probably write for months on the topic.
One of the things I’ve noticed in each of the companies that I’ve observed is the immediate struggle with terminology and concepts when the idea of developing products is broached. You might assume most people who develop products could understand the idea of a software project readily. Software releases have historically been managed as projects after all. You might also assume that folks delivering custom software projects for specific customers “get” products. I mean they buy products of various types regularly, including software products, right? However, in each of the cases I’ve seen, it was painfully evident that this assumption is completely wrong. In particular I’ve seen significant difficulty with project-oriented professionals understanding what a product is and what the implications of product development are to a software development organization.
Let’s quickly take a step back and define a key term: product. Although there is no shortage of definitions of this term (just ask Google), in my mind, a piece of software classifies as a product when it is delivered in the exact same form to multiple customers and is managed throughout its life cycle at these customers. That means no customer-specific versions or forking the code for every new customer project. Every customer over time has essentially the same executables and calls the same support line if (let's face it, when) there's trouble.
It is also helpful to define the term “solution”. I consider a solution an aggregation of products, services and other solutions that solve a customer’s problems. Solutions are important because services-oriented companies typically don’t deliver a software product alone -- they sell products as part of broader solution that often includes a significant amount of consulting and customer development work.
So what might motivate and organization to deliver products? Here are the ones I'm most familiar with:
Profitability
After years slugging it out in competitive situations for each project and developing software that only a single customer can use, the idea of building something once and selling it to a number of customers that is often an order of magnitude greater than the current client base can sound very attractive. It seems attractive on the revenue and cost sides (developing one thing instead of many things at least seems cheaper). In a future post, I’ll articulate the key differences between a services-oriented approach and shipping products, including the revenue model.
Valuation
Some companies would like to go public or get acquired. Typically, a company selling products is valued much higher than a services company as the latter has a built-in constraint on revenue: the number of person hours available to bill (these firms, of course have other ways to generate revenue, but the number of billable hours for a given workforce and "cost plus" pricing are clearly constraints). My cursory research shows that, ceteris parabis, a product company is valued at a much higher multiple (of revenue) than a services company.
Support Cost and Complexity
Once custom solutions have been delivered to multiple customers, often with slightly different versions of the same code base, organizations realize that the cost of supporting all these versions and managing the concomitant development complexity is unbearable. The notion of having a single software product that evolves and is managed holistically can be irresistible to these firms.
Customer Perception
Some firms feel pressure to move to the product paradigm because their customers want the perceived security of buying a product rather than what they perceive as a bespoke solution cobbled together during a project. Products have track records and other customers that can share knowledge and experience. The upshot is, organizations with products are often perceived as being more mature and thus more reliable.
In my next post on this topic, I'll discuss the perennial challenges or hurdles I see these organizations facing as they attempt to make a profound change to their organization, its process and roles.
Do you know of organizations considering making this change or already engaged in it? What was their motivation?
No comments:
Post a Comment