Product design has had a meteoric rise in the last decade, but most digital “products” are actually services and that slippage of meaning has consequences. In this piece I’d like to explain why I bang on about this so much.
Jesse James Garrett recently wrote a somewhat “kid’s today” article in FastCompany lamenting the current state of UX. “In the rush toward transformation, something has been lost,” he complained:
“What got lost along the way was a view of UX as something deeper and more significant than a step in the software delivery pipeline: an approach that grounds product design in a broad contextual understanding of the problem and goes beyond the line-item requirements of individual components. Also lost along the way were many of the more holistic and exploratory practices that enabled UX to deliver that kind of foundational value.
“Focusing on production-level UX allows organizations to check the “UX” box without having to deal with the messiness that sometimes results when you hire people who are charged with asking questions that have never been asked—questions senior leaders may not know the answers to, or may not want to. The factory floor prefers interchangeable, replaceable parts.”
I found this a little ironic coming from Jesse James. I gave a talk on Designing Multichannel Services for Lives Beyond the Screen for Adaptive Path’s UX Week conference in 2014. During the on-stage Q&A, Jesse James asked me how the product designers in the audience might integrate service design principles in their work.
“By product designers, you mean people who design digital touchpoints, not physical products, right?” I quipped. He responded with,, “if you want to talk semantics we can do that.” I didn’t take him up on the challenge, because it wasn’t the right time or place, plus I didn’t want to be a dick to the host on stage.
But semantics are far from an academic curiosity. As Jewish theologian Abraham Joshua Heschel said, “words create worlds.”
Recently I interviewed Teresa Torres for Power of Ten about her new book Continuous Discovery Habits (it’s very good, go read it). When we talked about this, she made the argument that it’s important to meet the language and terminology where they are, otherwise it’s a constant struggle to push back.
This if often true and service design has been plagued by being difficult to explain and a dreadful term to translate into other languages, but because words do create worlds, the language we use sets up our mental models of how the world is or should be, our terms of references and what or who is included or excluded. Ask a Guantanamo Bay inmate whether they prefer to be referred to as a “prisoner of war” (and thus have rights under the Geneva Convention) or an “enemy combatant” (and not have those rights). Or consider “asylum seeker” versus “illegal immigrant, “activist” versus “terrorist,” or “are you male or female?” Those semantic shifts ascribe or remove rights, shape our mental models of others, and are used to other.
Back in the world of products and services, a fundamental mindset shift in service thinking is away from the industrial factory model to one of service ecosystems, which we wrote about at length in the second chapter of our book Service Design: From Insight to Implementation:
“Products are discrete objects and, because of this, the companies that make, market, and sell products tend to be separated into departments that specialize in one function and have a vertical chain of command—they operate in silos.”
Services created in silos are experienced in bits, because services comprise multiple touchpoints across multiple channels and are experienced in their totality. Often, each bit of the service is well designed, but the service itself has not been designed and does not hang together as a whole. This also means services can’t be fixed in the same way as products, by just optimising the bits. Those bits have to connect together seamlessly and effectively for the whole to work properly.
When we use the shorthand of “product” in a digital context, it masks a lie. Uber isn’t a product. Airbnb isn’t a product. Netflix isn’t a product. Twitter and Facebook certainly are not. Nor are their apps – those are just touchpoints or avatars to the service. You don’t watch the Netflix app, you watch the movie. Try using it offline without any downloaded content and see how entertaining it is.
Possibly the only thing you might legitimately call a product on your iPhone is a facsimile of an actual product: the calculator. Almost everything else connects to the Internet for other services, even if just in the background, and that makes those apps touchpoints of larger service ecosystems.
As Melissa Perri writes in her excellent book, The Build Trap:
“Many companies are confused by the word product. You say product and people think of an app, a feature, or an interface. If you think back to our diagram on the value exchange […] products are vehicles for value.”
If you’re a product designer who has used the Jobs To Be Done framework, you’ve already admitted your product is a service.
When product teams are working on different touchpoints of a service ecosystem or, worse, working on different features of the same touchpoint, things can quickly go awry. Jorge Arango had a good take in his post about Slack’s abandoned plans for Connect DMs, which would have allowed any Slack user to direct message any other Slack user:
“Good on Slack for quickly pumping the brakes on this new ‘feature.’ But why was this released in this form to begin with? My sense is that Slack’s teams think of themselves as adding ‘features’ to a ‘product,’ instead of as stewards of a place where people work.”
Stewards is a good word. It suggests a longer-term view.
The “featurization” of digital services is a perfect example of how words shape the mental model, which shapes process. (Featurization is also an awful, made-up word.) When Clubhouse (remember that?) had its moment in the spotlight, Twitter, LinkedIn, Facebook and others rushed to add “social audio” to their platforms. Featurization is what happened to Microsoft Word and turned it into a bloated, unusable mess for a decade. It reveals a lack of imagination from tech companies focused on keeping up with the Joneses rather than solving real problems.
Melissa Perri again:
“When a company thinks only about the feature-level model, it loses track of the outcomes those features should produce. That is what lands you in the build trap.
Gardens are a better metaphor
It’s fair to say the straw man of my argument is that I’m talking about digital product design and creation done badly. There are plenty of awful services out there, after all. That’s why service design exists. Yet, I mostly see and hear stories of services nightmares precisely because of the language used to frame them as products and features.
You really don’t “ship” code or product anymore. You upload (or deploy, as the cool kids say) it into an existing ecosystem. It’s not a product out the door, done and dusted and never going to change. Your code has been planted and will interact with that ecosystem.
In fact, my favourite metaphor for this kind of work is a garden. Especially landscape gardens, which are long-term projects whose full maturity their designers will never live long enough to see.
You plan, prepare and plant a garden, watch it grow and evolve, and tend to the ecosystem. Some things grow quicker than you imagined and need cutting back to avoid them taking all the resources from others. Other things wither and die or need to be transplanted elsewhere. A pivot to the next divot. Bugs appear and need to be dealt with, but not too harshly otherwise you’ll destroy the balance of the ecosystem. We don’t ever think of gardens as “done”.
Nobody says, “we shipped the garden.”
All this takes time. If you are focused on velocity over outcomes, it’s like pulling on plants to make them grow faster. Speed has its place, but it’s not “go as fast as we can, whatever the consequences” but “go as fast as we can while still doing it as right as we can.”
The number one problem I hear from my coachees and clients is a lack of time to focus, to be creative, to do the job properly. There are sometimes reasons for working at pace, but often it’s simply done because everyone else is doing it. It’s not sustainable. You can’t sprint all the time without suffering exhaustion. When you’re exhausted, you run on autopilot and can only focus on mindlessly knocking things out on the assembly line.
One last quote from Melissa:
“The danger is when a product manager is 100% operational, focusing only on the process of shipping products and not on optimizing the feature from a holistic standpoint. When they only optimize for the day-to-day execution of the team, they usually fall behind in the strategy and visioning work that is needed for the success of the features.”
If you’re dividing your service ecosystem into product features and pillars, there’s a good chance you’ll lose sight of the connective tissue between them. It’s like spending all your effort building shiny cities but neglecting the roads between them. You would be surprised how much time customers spend on those muddy, unkempt roads.
The industrial legacy
I suspect one of the reasons this has become such a popular paradigm is because it’s comforting to slip back into old habits, despite all the Lean and Agile talk. The dominant management paradigm is still the industrial assembly line, in which complicated tasks are broken down into simple rote tasks that unskilled labour can repeatedly execute. In this paradigm, factory floor employees are inherently dishonest and lazy and require constant supervision from the smart managers in suits in the glass offices above the factory floor. They’re there to manage the thinking. (It’s no surprise that the Industrial Revolution in Great Britain gave rise to a management process heavily laced with classism.)
Department divisions in enterprises are often just an assembly line in disguise. A customer’s experience is passed along the line from marketing to sales to support. As with an assembly line, each department has little idea what the customer’s experience of the others is. They don’t need to know in order to achieve their individual targets set by management.
Each one adds a feature as they see fit, but without coordination, which is why I ended up with credit-card style plastic card glued to a printed leaflet referenced by an email from my telco. All three provided me the log-in details to set-up my new router. All three were different. All three were wrong. Two touchpoints were literally glued together and carried conflicting information.
It’s not about titles
Lest you think I’m trying to tell you your career as a product design doesn’t exist, I’m not making the argument for one discipline over another or that product design isn’t a thing. Despite having co-written a book on service design I view service design less as a discipline and more as an activity that a multi-disciplinary group of people engage in. Service Design is no more a discipline than Agile or Lean is. It’s a mindset and a way of working with a set of evolving methods it draws upon.
I am not arguing that you should practice service design instead of product design. I’m saying that if you do digital product design, you already are designing services. The question is whether you are doing that consciously and intentionally or not.
This post was originally part of my newsletter Doctor’s Note. Sign up if you’d like to receive more of my writing and a whole host of links and reading suggestions.
