The Meal is Not the Product

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

There are many reasons that people go out to eat. Some of those reasons involve food; many do not. If you’re going out to watch a game with friends, for example, the number and size of TVs is at least as important as the menu. For a date, the chef is generally important, but so is the ambiance from lighting to noise level. Successful restaurants, regardless of classification, understand that the meal is part of their product, not the whole product.

The technology world, for the most part, has yet to learn this lesson. With rare exceptions such as Apple that will advertise a phone by describing the pictures it takes, producers of technology tend to be myopically focused on technical achievement. Technology is difficult enough to create that it leads engineers to conflate challenge with value and interest. “Of course this technology will sell, do you know how hard it was to build?”

This is the same mindset that has lead some phone manufacturers to tout technical specifications such as clock speed or screen resolution as actual selling points.

Unfortunately, the degree of difficulty tends to have very little in common with what Clayton Christensen refers to as the Job to be Done. The clock speed of a phone may be relevant to its performance, but an average user will not understand how to attach that to what they actually want the phone to do. The camera, on the other hand, is directly and immediately relevant. Christensen’s Jobs to be Done framework, as most RedMonk customers have heard at some point, provides a useful frame and vocabulary for understanding both current and future market conditions.

Consider IBM. Many startups today have grown up using no IBM technologies, and as a result have a difficult time understanding even Big Blue’s diminished account presence and control. With a step back, however, it’s easier to understand. In years past, while other companies focused on products, IBM was selling something of higher value: peace of mind. Part of every IBM sale is a set of implicit promises regarding longevity, support, credibility and enterprise-readiness, the ultimate impact of which can be summed up in the old industry adage: “You don’t get fired for buying IBM.” Both implicitly and explicitly at times, IBM has understood that that is an important Job to be Done for its customer. Many vendors can sell a product; comparatively few vendors can sell job security.

More recently is the case of Pivotal. As the original author of the Cloud Foundry project, one easy way to understand the company is as a would-be heir to the middleware businesses of WebLogic or WebSphere. But, like any product-focused analysis, that obscures the bigger picture. As important as projects like Cloud Foundry have been to the marketplace, for Pivotal it’s arguably just a means to a larger end, or different job. Today, many Java shops are at a rare inflection point. They have massive existing Java investments, but understand that whether they leverage the public cloud or merely attempt to compete with it, the infrastructure their applications live on is going to either be cloud or look like one. Pivotal’s co-opting of the “Cloud Native” term provided these Java-based enterprises with a modern path to aspire to. More important than vision, however, is Pivotal’s ability to work side-by-side with customers’ development staffs in an effort to teach them what they need to get themselves there. Many vendors can sell software; comparatively few vendors can sell a modern development organization.

As Peter Drucker observed, customers rarely buy what a company thinks it sells, which is why Pivotal’s surprising decision to support Kubernetes is not surprising.

Understanding the wider context of a product and its usage – the Job to be Done – is fundamental to success generally, but never more so than right now for two reasons.

  1. Software vs Software-as-a-Service:
    Directionally, the trajectory of the market is clear: services are where growth is occurring. From Amazon’s overnight ascension to IBM’s furious transition to service-based offerings to Red Hat’s just announced expansion of its Amazon partnership, it is generally accepted that while everything won’t go cloud, that is where the growth will come from. Which is why it’s so surprising to talk to software vendors today who still believe their biggest threat is other software players, not service-based implementations of same. If we step back and use the lens of Jobs to be Done, the differences between traditional software-only players and service equivalents are stark. On the one hand, customers can pursue a software strategy that requires difficult evaluation and choice, large up front CAPEX investments, ongoing maintenance and support and so on. On the other, choice is largely gone, along with up front CAPEX costs and ops responsibilities. As an end user, if my Job to be Done is executing a business priority, one of those two approaches accomplishes much more of the Job to be Done for me.

  2. Fragmentation:
    For at least eight years RedMonk has been discussing the implications of fragmentation on the industry. In every infrastructure category, there has been an explosion of options and choice. On the one hand, choice is preferable to the alternative. But choice, particularly the amount of choices involved in infrastructure today, does not come without a cost. If it’s difficult even for elite developers to keep up with the rate of new technologies’ arrival, imagine the position that enterprises still struggling to understand the differences between containers and virtual machines are in. It’s important, therefore, for technology providers to factor this fragmentation in to their messaging, product and go to market, because it’s an important part of the Job to be Done for customers. If you don’t consider it, a better packager will.

To be clear, none of the above should diminish the importance of product. While there are many examples of poor technology becoming successful in spite of its original design, there are orders of magnitude more of poor products that get the reception they deserve. Fortunately, however, embracing a Jobs to be Done philosophy is not an either/or proposition. If anything, product management should be improved and refined from a broader understanding of what precisely customers are trying to do with what the company is selling. The problem isn’t, in other words, that the Jobs to be Done methodology is incompatible with technical development, it’s that most in the industry don’t perceive the problem.

The first step to remedying a problem is, of course, acknowledging the problem exists. Receptions to the concepts embodied in the Jobs to be Done methodology tend to vary. On the one hand, developers and companies that understand the value of packaging, for example, grasp the concept quickly. At the other end of the spectrum lie those that believe that marketing has no purpose or importance. That audience, unsurprisingly, is unsympathetic to the idea that something other than the core technology can be relevant to a decision about it.

For that audience, perhaps the best way to put it is this: if you run the kind of restaurant that cares solely about the meal and not the environment it’s served in, it would probably be wise to make plans for your post-restaurant career.

Disclosure: AWS, the Cloud Foundry Foundation, IBM, Pivotal and Red Hat are RedMonk customers. Apple is not a RedMonk customer.

No Comments

Leave a Reply

Your email address will not be published.