Step back and think of your product as a swarm of service-delivering robots. Serve your customer, and not the product.

Some late night rambling…

SaaS companies are service ecosystems. By “service” I am not talking about professional services (though SaaS companies can certainly offer these)

. I’m talking about service as:

the production of an essentially intangible benefit … which through some form of exchange, satisfies an identified need (source)Imagine a restaurant with robot chefs and waiters. Your code is basically scripted service design and delivery. You can pay an accountant for tax “services”. Or you can pay Intuit for tax “services”. Intuit uses code (as well as humans) to orchestrate the service delivery.

When we “ship a feature” we are adding some sort of service delivery capability. It is only valuable when it “satisfies an identified need”. The code itself is like a recipe for robot chefs. If the food sucks, or people don’t eat the food, the recipe is not valuable. There needs to be an exchange. Yes people buy on the items on the menu, but they renew on the quality of the exchange.

Robots? Sure. Consider the increasing use of AI and machine learning in B2B SaaS products. Often we refer to SaaS products as “tools”. Consider that we perceive of these products as tools because we (the user) USE the tool. It feels like a hammer, darkroom, nail gun, or calculator. Fair enough. But we use these tools to achieve an outcome. What if the outcome was delivered by our code-drive-robot virtual assistant? The photo is retouched, or math problem calculated. Hmm … that feels like a service.

The context for our SaaS service delivery machine is constantly evolving. The actors in the system — prospects, customers, employees, technology touch points, partners, the broader competitive landscape — are not motionless. They are all “the product”. Our engineers are the product. HR is the product. The distinctions between engineering and the product team are imaginary.

As SaaS product managers we don’t ship product like a shoe company ships shoes. Rather, we oversee the emergence of a service delivery ecosystem. You can view Apple as a product and/or design company (and they certainly do both very well). Or you can view them as master service designers providing a lifetime of touch-point enabled experiences. Apple Care! Apple Store! Geniuses!

I frequently hear UX designers complain about agile software development. It causes us to cut corners! When can never “get it right”. I think that these things are vestiges of shipping wrapped/fixed/tangible products. And if you view it like that, an agile approach to software development will always feel shitty. It’s like design-by-a-thousand-cuts or building a grand sand castle one grain at a time … it feels incomplete and clumsy

But step back and think of your product as a swarm of service-delivering robots (and your human staff as a team of smart, warm, breathing service delivery agents), and suddenly the ability to change course, evolve, and adapt — like a restaurant evolving its menu and service — makes sense.

Consider all customer interactions with your company. Serve the customer, and not the product.