You're a Service Company

Service Design might be the solution startups are looking for

Hello reader 👨‍🎨

Welcome to this Sunday’s essay. Let’s dive right in.

Level 1: While SaaS companies have long adopted "service" in their monetization and distribution models, their management practices remain product-focused
Level 2: This misalignment limits the value companies provide and creates disconnects in the customer experience
Level 3: Teams that implement service design practices in their modus-operandi can support a healthy growth

Last week, my article "Beyond Feature Sets" was published in Touchpoint, the journal of Service Design Network. The publication focuses on a different topic within service design for each issue. Last issue’s main theme was the product management: “Bridging Disciplines: Service Design and Product Management." In my article, I wrote about service design approaches I've implemented across various SaaS companies I've consulted for, using PeopleBox as the main case. The core idea was “Implement service design without saying service design”. For those without access to the publication, and who only have a distant understanding of the service design concept, this essay isn't just a summary of that but rather one inspired by it.

Historically, the acronym SaaS (Software as a Service) was coined by developers to describe software that's managed remotely as cloud services. However, although the name suggests “service”, there's a fundamental misalignment between the term and the terminology used across the industry. While the work is inherently about providing continuous service, the industry focuses on product-centric language, "product managers," "product-led growth," "product roadmaps". Thus, the acronym is correctly named, but opportunities are being missed. And to be clear, by SaaS I also mean, video games, applications, operating systems, and web apps that all fall under the "X as a Service”.

First, a brief theoretical foundation: In 2004, Robert Lusch and Stephen Vargo coined "Service-Dominant Logic" in their published paper, arguing that all economic exchanges (including goods production) are fundamentally service exchanges. An automobile factory, the supplier manufacturing parts for that factory, and all employees—while seemingly engaged in mere exchange of goods—are essentially providing a service by using their knowledge and skills. Economic value isn't created by the producer alone, but co-created through the presence of all actors (producer, consumer, supplier, etc.). This dominant logic forms one of the foundational theories of service design.

So our main question is: What do we SaaS companies, gain by recognizing that the fundamental nature of our work is a Service? What are some missed opportunities? To illustrate this better, I’ve created a high-contrast comparison table between product and service paradigms.

"Product" Logic

"Service" Logic

Focus: Features and functions

Focus: Customer experience and problem solved

Success metric: Number of sales, downloads

Success metric: Customer satisfaction, loyalty, lifetime value

Updates: Major versions, scheduled intervals

Updates: Continuous improvement based on customer feedback

Customer relationship: After-sales support

Customer relationship: Continuous and evolving partnership

Design approach: Inside out (product features)

Design approach: Outside in (customer needs)

Revenue model: One-time sale focused

Revenue model: Subscription and value-based pricing

Product lifecycle: Introduction, growth, maturity, decline

Service lifecycle: Continuous evolution and adaptation

Marketing approach: Emphasizing product features

Marketing approach: Emphasizing value provided and solution

Innovation source: Internal R&D, competitive analysis

Innovation source: Customer feedback, usage data

Organizational structure: Siloed teams

Organizational structure: Cross-functional, customer-focused teams

Performance indicators: Sales figures, market share

Performance indicators: Customer retention rate, NPS score

Definition of failure: Not meeting sales targets

Definition of failure: Not solving customer problems

As seen in this comparison, the service logic focuses on solving customer problems and creating continuous value, while the product mental model focuses more on feature development and sales. Though the industry has largely adopted the business model on the right side, its lingering attachment to the left side on critical issues creates the main problem. Moreover, while startups which begin as small teams can demonstrate excellent cross-functional collaboration, gradually become more bureaucratic as they grow and start behaving like the left column.

The Conflict

When the business model resembles the right side but the behavioral model follows the left, inconsistencies begin to surface. For example, in a B2B SaaS, a salesperson who overpromises some features to meet sales targets ends up embarrassed when the product team can’t keep up with development because their increment cycles break, creating customer dissatisfaction through the team's own actions. As internal unhappiness increases, a development team that has lost focus on what they're producing for whom begins to experience burnout from trying to keep up. Silos between teams deepen, and as they deepen, customer dissatisfaction grows, leading to churn. In another scenario the same silo effect in a B2C mobile product occurs when a user contacts support with an important issue. Even if they're treated well by the support team, their problem never reaches production as a genuine need due to divisional formation within the organization.

The service experience gap is often times filled by UX, other times by product management. However, their limitation in a growing startup is that they remain confined to their defined areas, lacking the authority and responsibility for holistic thinking and action. That's why, as Airbnb co-founder Brian Chesky mentioned on Lenny's Podcast, product managers transform into program managers—people who coordinate the implementation of existing features, manage processes, organize meetings, and facilitate communication between teams. This explains why five thousand designers at Figma cheered when Chesky declared "I eliminated the product management role" while giving a talk at the company . I recommend watching the podcast through a service design lens. Particularly because there's a two-word solution to every single one of the problems Chesky describes: Service Design.

By definition, Service Design is a human-centric discipline, taking care of both customers and employees. It combines frontstage and backstage (it’s not frontend and backend), which means users, marketing, sales, development, and all after-sales into a holistic single management, often visualized by a service blueprint. As I discussed in my article, Chesky is doing it "without naming it”. When he says "I eliminated product management," he actually means bringing marketing, product development and several other roles under a single umbrella.

A Roadmap

Looking back, thanks to the freedom my consultant position provided me, I successfully implemented service design thinking in various SaaS teams. While the position allowed me to work side by side with founders to set service visions, it also allowed me to fight in trenches alongside developers. I deliberately took on the scrum master role because it’s partly the closest one to a service designer, facilitating, coaching, organizing, and easing communication to improve team effectiveness while keeping them happy. In the current digital product paradigm, there's no defined role, title, or organizational scheme for the whole service design work, and that’s the problem. But there should be.

Founders should start hiring service designers who speak digital product. Meanwhile, service designers should learn more about digital product management and invest in tech literacy. Service designers who already find themselves in such positions should forget the post-it/workshop style service design practices they've done over the years, and be ready to fight on the frontlines with developers.

5 Practical Steps

  1. Work on Shared Blueprint
    A Service Blueprint is a visualization tool that defines how the product/service system works both in front stage (audience) and backstage (team work and processes). Unlike a user flow or a journey map, it not only follows user actions but shows how all the background processes and team interactions shape it. It allows teams to see beyond feature lists and understand the holistic experience.

  2. Service User Stories
    Create "service user stories" within your backlog that specifically address experience improvements beyond feature delivery

  3. Adopt Service Prototyping
    Instead of just Figma prototypes, learn more about service prototyping and iterate whole service experiences across all touchpoints.

  4. Merge Roadmaps
    It's critically important to have product, design, development, marketing, and customer success teams working in a unified manner on the same track/roadmap.

  5. Track Unified Service Metrics
    Move beyond feature usage and adoption rates to measure cross-touchpoint satisfaction, resolution times, and even scrum scores to retention correlations. We accomplished this by using only Notion and saw tremendous benefits in a short time (It wasn’t easy at all). We have seen up to 80% improvements in team performance and up to 10-point NPS gains.

"The words you speak become the house you live in"
Hafiz (Persian lyric poet)

Although in my Touchpoint article I discussed "doing service design without saying service design," words are determinative in vision and attitudes. Words influence how a company defines itself, and subsequently all the titles and functions within it become product-focused. Nevertheless, I think via opening these discussions we're on level 1 in bringing service design into digital product world. I believe that after awareness develops and implementation gradually begins, we'll transition to level 2, where holistic practices and relevant new terminology occur.

In conclusion, even if you don't realize it, you're a service company. The sooner you accept this reality, the faster you'll adapt and get ahead.

Time Capsule

Salesforce's Launch in 1999 Revolutionary because: It emerged as the first true SaaS company with the "No Software" slogan Current legacy: As a pioneer of the subscription-based software model, it brought a service-oriented business model to the entire digital product ecosystem Note: Marc Benioff was initially not taken seriously by traditional software companies, but his vision sparked a business model revolution.

Tiny Challenge

Try to identify the person or role in your company who is holistically responsible for the entire experience a customer has from their first sign-up to their final departure.

Node Mode [Off][ ]

Peace,
Aydıncan.

Reply

or to participate.