Of the words that get misused or oversimplified, “product” is one of my favorites. It creates such an easy image in people’s heads that often is completely inaccurate, especially in the high-tech domain.
When we hear the word “product,” we tend to think of this widget that passes hands from one of our salespeople to the customer. We get paid for it and move on with our lives. The product is simple, the sale is transactional and the relationship with the customer ceases to exist once the transaction has been completed.
In reality, this is of course completely inaccurate for, especially, software-intensive products. There are at least three reasons why the notion of “the product” is difficult to define in this context: boundaries, integrations and DevOps.
First, even if it may seem easy to define what the product is and what it isn’t, in practice, there tend to be multiple elements that are part of the overall product. Typically, there’s of course the physical product, consisting of mechanical parts, electronics and software, potentially including machine learning components. In addition, however, there often is some kind of cloud solution to complement the physical product. This cloud solution often provides a set of additional capabilities, including configuration, data-driven insights, predictive maintenance and recommendations. Finally, there might be a mobile app providing an additional interface to the physical system. All these parts, when combined, make up the offering to the customer. Many forget about everything except the physical product when referring to “the product.”
Second, even in the cases where it’s easy to put boundaries around the product by the organization providing it, customers use the product in a context together with other systems from other providers and/or internally developed solutions. This causes the product to be integrated with, potentially a plethora of, systems on the customer’s end. In those cases, even if we seek to keep boundaries clear, the customer will force us to lean over those boundaries and take responsibility for the integration. And, of course, it becomes significantly less clear what the product actually is as we’re likely getting paid for taking that responsibility.
Third, virtually all companies I work with are adopting DevOps in some way, shape or form. DevOps results in a continuous relationship with the customer, rather than a transactional one. As you push new software, data collection code and ML/DL models to systems in the field on a continuous basis, you also need to ensure that the product continues to function as intended. Not just in isolation in the test lab, but also in the specific configuration and integration context at the customer. In many companies, this has led to the business model changing from transactional to continuous as the latter aligns better with the product’s cost structure.
As a lack of clarity around the product, in terms of boundaries, integrations and continuous improvement, is counterproductive, we need to address this. The most helpful mechanism I know of is Clayton Christensen’s model of the jobs to be done. In this model, a product is ‘hired’ to do a job that the customer wants to get done.
The “jobs to be done” model reinforces a point that I think is critical to remember: no customer gives a flying hoot about your product. Except for a very small number of luxury products that are solely used for social signaling, customers acquire a product to accomplish a certain outcome. They don’t care about the product itself. In fact, many would prefer to not get the product if there was another way to achieve the same outcome.
As an example, I own a car, but I thoroughly dislike it. It takes up a lot of space, services are expensive, it costs quite a bit to drive, parking in the city is a nightmare, and so on. I only own it because I have a job that needs to get done, I have mobility needs and the car proves to be the best way to meet my needs.
For mature, stable markets, products have clear, well-defined interfaces and most of what I shared so far doesn’t really apply. For technologically advanced products, however, the interfaces are much less clear because the ‘industry-dominant design’ isn’t developed to the same extent or it’s changing at a much higher rate than for commodity products. Consequently, deeply understanding the continuously evolving “job to be done” by the product is critically important.
In the case of radical innovation where the company is seeking to introduce a fundamentally new product, the customer is often not even clear on the job to be done and what product to hire for it. So, in that situation, closely working with the customer to achieve clarity is most likely the most effective use of our time.
Although many refer to “the product,” in practice, it often is unclear what the boundaries of the product are, how it’s integrated with other systems at customers and how it evolves. To address this, companies should focus on the job to be done for which the product is ‘hired’ by customers. Starting from that understanding can significantly improve the way companies work with their products and it leads to much more clarity as to what the product actually constitutes. As Jay Abraham says, “Sell the benefit, not your company or the product. People buy results, not features.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
