I’ve written a lot about the huge organizational and technical gulf between services companies and product companies. (See this and this and this and this.) At a recent workshop in Christchurch NZ, I spent several hours talking with CEOs about the challenges of changing a company from mostly services to repeatable products, and how more of the work is on the go-to-market (GTM) side versus the technical side.

First, worth carefully defining what those two categories mean to me:

• Product companies build a single instance/release/ version of each product that is sold as-is to many (hundreds, thousands, millions) of users and buyers. That lets them make nearly 100% margin on the second (and ten-thousandth) license or copy or seat, since there’s almost no post-sale technical work to customize, integrate, or extend it for the next customer. Success is measured in total number of customers (versus a few huge contracts) and sales velocity (how fast we can close the next 50 or 500 deals).
• Services companies (aka custom development, agencies, outsourcing/nearshoring, contract engineering, consultancies, any work-for-hire) primarily market/sell the time and expertise of their people. Work is quantified in hours, days, or projects. Clients own the IP and provide much of the technical direction.
  In mixed product/service companies, services include custom configuration; technical onboarding work by customer success groups; building unique data connectors; creating bespoke mobile apps; analyzing clients’ data for individual insights; building custom websites; designing marketing campaigns for clients; turning a customer’s internal toolkits or architectures into finished applications. And any software we build and sell once to the client who paid for it.
• A glance at a tech company’s website immediately tells me which kind they are. Services companies promote their skills and talents building whatever individual clients want (“bespoke”, industry talent, speed of development, geography, cost of people, success stories about delivering what one client needed). Product company websites make their products the hero: selling specific benefits of using their specific product for its specifically intended use – with financial or operational improvements that the next customer should expect. (“Our AI-based tech support lookup product will cut your support costs by 25-35%.”) No one cares how big the team is, how long it took to build, or how smart our engineers and designers are.

It's my long-standing, strongly-held assertion that tech companies must choose either a services model or a product model. Companies trying to do both will be fundamentally misaligned at the executive level, and make contradictory demands of their functional groups. I can look at a corporate org chart and immediately see which kind they are. (Even though there’s a lot of talk at dyed-in-the-wool services companies about having “products” or “platforms.”)

Why try to transform from a services company to a product company?

• Investor pressure for a high-value market exit. VCs and other investors value pure license ARR at 6x to 10x or more, but service revenue at 0.4x to 0.8x. So a dollar of hands-off, no-touch, high-velocity license sales (with as little human post-sale effort as possible) is worth ten times as much as a dollar of services work. Building a repeatable product is risky and expensive, but finding product-market fit with a truly packaged offering can be a license to print money.
• Reducing strategic conflicts at the executive level. I often see conflicted organizations where the Customer Success or Professional Services groups is pushing to sell and deliver more custom work, sign more development projects, grow their services teams to bill more hours – while Product/Engineering are pushing for a single released version, less single-customer development, fewer unique packages, faster average implementation time. I hear lots of shouting driven by diametrically opposed goals.
• Unblocking a mass audience of SMB and mid-tier customers, especially when R&D is currently consumed by commitments to a few huge clients. When we can sign 50 mid-sized deals with less energy than 4 big ones, we can reject the “MegaCorp demands that we implement X” hostage-taking that’s so prevalent in enterprise software. (BTW it doesn’t matter if customers pay us for our time. At services-heavy companies, we’re always bottlenecked in both Customer Success and core Engineering teams – struggling to bring on the next big customer while meeting an ever-growing stack of single-deal commitments. We're short of talent, not cash.) Low-friction products let us sell and deploy more customers faster.

So I’ll make the case here that every department/function behaves differently at a services company versus a product company. Therefore moving from services to product is a major company-wide effort that every executive must strongly support.

An Anonymized Example

Let’s imagine a B2B software company building corporate expense management applications. Their $20M run rate is 60% license revenue and 40% services. Looking for a big exit, the CEO’s (and Board’s) stated goal is to grow ARR while reducing services revenue: $28M next year with less than $6M in total services, then $35M with under $4M in services...

Under the hood, we see typical challenges for a half-services/ half-product company:

• Some license deals actually include pre-sold custom integrations or multi-year services bundles or human-powered analytics services. So pure ARR is about 50% of total revenue.
• The Customer Success (CS, aka post-sales implementation) team runs on a project model, staffing new projects as they finish current ones. They are overwhelmed with existing commitments and new deals.
• The largest clients treat Customer Success as an outsourcing resource, with a constant stream of “we need you to do vaguely related thing X to keep us happy.” Some clients don’t actually use the application themselves, instead having CS as their fingers-on-keyboards running reports or entering data or interpreting data or building CFO-level presentations. To them, the company looks like an agency rather than a software vendor.
• Since CS moves from one project to another, there’s no ongoing CS staffing for in-production customizations or integrations – which periodically break or need revisions. So the core Engineering team is often pulled in for emergency fixes, without context, on code they didn’t write. A product roadmap exists, but we notice that more than half of R&D effort is actually spent on these non-core repairs. Planning is futile; Engineering and Product are disheartened; everyone complains about a lack of innovation.
• Updating or upgrading the core software platform is increasingly difficult. Every major client is on a different version, with assorted undocumented extensions and clever workarounds that assume the underlying tech will never change. So improving the underlying architecture means testing against every customer implementation – with fingers crossed. And no one is excited to migrate. The core application is aging, fragile, unscalable. Enhancements have ground to a halt.

So unwinding our services business will be slow, risky, frustrating.

What Does Success Look Like?

Talking about a repeatable product model is mostly philosophy until we start measuring progress. My two best metrics are:

• TIME TO VALUE (TTV): the total clock/calendar time between a customer signing a purchase order and end users getting the primary value they've been promised. For our expense management application, TTV is the number of calendar days after signing when most employees can successfully request travel reimbursement. There will be a few items that we wait for the customer to do (single sign-on setup; employee notification) but we strive to reduce/eliminate everything else (connection to their finance system, sample employee invitation, logo upload, report aggregation). Could we finish everything on our side in 6 hours rather than 6 days or 6 weeks or 6 months?
• TOTAL IMPLEMENTATION EFFORT (TIE): in hours or days, the total effort by all of our internal groups to get the next customer into production. This excludes ongoing technical support, but includes set-up; configuration; matching charts of accounts to expense types; drafting custom employee emails for HR; and migrating expense data from legacy systems. Reduce from 250 hours/client to 175 to 110 to 60?
• Harder to measure, but an end goal: INCREASED SALES VELOCITY, which is the average time to close the next deal. Can we speed up the sales cycle and reduce per-deal sales effort with self-run demos, clearly posted pricing, free trials, fewer choices and configurations, improved UI/UX, default setups, wizards?

A move toward repeatable products shifts our discussion from how to close a few very large deals to the aggregate revenue from dozens of increasingly similar customers. This is a whole-company discussion, not a narrow technical distinction.

Department by Department…

We should expect lots of push-back from each of the affected corporate groups — especially Sales and Customer Success — as we shift company-level goals and metrics. So IMO the #1 determinant of success is very clear: CEO-led executive-level agreement that the whole company will make this change. Pretending it’s primarily a product/engineering challenge is assuring failure. Is the CEO willing to push hard for a whole year, repeatedly make the case, anticipate dissent, let some shiny deals go, and stay the course?

CORPORATE-WIDE

It’s important that we approach this major change with eyes wide open. Some honest assessment questions to ask:

• When will our packaged products be ready to support the company’s entire revenue target? Are we there today? Have we done enough hard-nosed analysis and forecasting that the GTM groups agree with? If revenue dips next quarter, will we revert to urgently selling services?
• Almost immediately, we’ll need a “stop the bleeding” plan, which means not signing any NEW contracts that include custom services. Do we have the stomach to enforce that? (It’s unlikely that we’ll cancel committed in-flight projects, but every new item undercuts our resolve and internal agreement.) This isn’t an intellectual question, but a C-suite behavioral question when faced with a shiny new opportunity.
• Product development always takes longer than we planned. How much leeway do we have?
• Should Finance carefully track true ARR and services work on existing deals? Should services be reclassified as a cost center?

EXTERNAL SERVICES PARTNERS

Our customers’ needs and demands don’t disappear just because we want to change our business model. They are used to us happily agreeing to their next request. Where will these go? I’d recommend identifying (wooing) at least two pure-play consulting or services firms that do good work in our space, and bringing them projects that customers will pay them for. This will be wildly unpopular with our Customer Success group, but might look like:

• Training services partners on our platform, architecture, APIs, methodology
• Considering a jump-start by “lending” a few of our best CS folks to partners
• Making ongoing referrals contingent on quality and TTV and customer feedback
• Identifying abandoned old projects that we struggle to support, so that we can pass them on to our service partners – along with customer notification of ongoing support fees to the partner

A fallback is to spin out the service group into a separate legal entity (not just a distinct operating group under the same P&L) with a plan to add at least one competing services provider.

CUSTOMER SUCCESS (Integrations/Implementation)

This group takes the brunt of a changed company strategy. They’ve been delivering revenue/margin/growth for years. Their goal is now to do less, not do more. We need to honor and appreciate their contributions

• Create CS bonuses based on faster TTV rather than increased hours invoiced. Have MBOs around clear documentation of built solutions.
• Involve CS in every step of the migration and upgrade process. They know these customers better than anyone else in the company.
• Shift accounting treatments to move revenue into licenses. (For instance, reduce separately invoiced services and raise license prices to offset it.) Growing CS is no longer our goal: it becomes a cost center, not a profit center.
• For customers with services included in their current contracts, rebundle a Gold version of the core product that includes a fixed (declining) amount of implementation work each year. That means a margin hit in Year One but increasing profit in later years. Look for product substitutes for services like “free” product upgrades or additional seats.
• Start an executive review (including Product/Eng) of customers needing more custom work. Default becomes NO rather than YES. “Who else could do that work? What product or tech alternatives do we have? Who will support that in two years?”

SALES

Salespeople do what we pay them to do, not necessarily what we want them to do. So IMO the biggest lever in changing what we sell – and who we sell it to – is driven by our sales compensation model (“comp”). In most B2B/enterprise markets, it’s probably much easier to sell services than packaged products: customers always have needs and budgets and (poorly thought-through) specs, which we’ve been eager to accept. (“Customer wants someone to run reports for them and summarize the learnings. Done!”)

So consider:

• A higher commission rate for our absolutely standard product, then deducting a multiple of services (e.g. 120% for pure ARR less 5x our services costs). No commission on services-only deals. A bonus for faster-than-average TTV, since that encourages us to sell what works today.
• A refresher course on value-based selling, i.e. the benefits that the actual features of our current product actually deliver, rather than customization or future capabilities.
• Pipeline focus on quickly qualifying out custom deals, including requests from current customers. (Saying NO to poor-fit prospects will be an executive-level organizational challenge: a skill we may have to develop.) For entertainment value, we may start referring problematic opportunities to our competition.

MARKETING

At a product company, our product and our product’s end users are the heroes of everything we share. (At services companies, the heroes are our highly skilled professionals, their segment experience, and willingness to attack uniquely hard problems.) If our marketing strategy has a services emphasis, it may need rethinking:

• Messaging and positioning focus on the product and its specific benefits/advantages. Success stories have a smiling end user or corporate buyer crowing about quantitative product outcomes.
• Moving toward volume and sales velocity makes an Ideal Customer Profile (ICP) essential, not just a talking point. We need to get 10x more prospects into the pipeline, since many won’t be qualified, and ASPs will be lower. So we’ll need tough-minded analytics and unemotional win/loss analysis to target and reach the right prospects.
• Services-heavy firms tend toward account-based marketing (ABM), with deep multi-touch outreach to known individuals at a small number of huge firms. We may need to shift toward content marketing, drip campaigns, events, and referrals. And away from hand-crafting decks and pitches for key accounts.

MAKERS (Design/Engineering/Product)

As our products become stars of the show, we have to make them easier, frictionless, self-demo’ing, self-service. A shift toward product-led growth means moving away from project-based work with:

• A relentless, ongoing identification of bottlenecks and stumbling blocks throughout the early product experience. This might be UX/design-led: where are prospects and early trial users getting stuck? When we directly observe naïve users (or dig deep into app analytics), where has our expert knowledge failed us?
• Mapping and measuring TTV, what are the slowest or longest steps to customer value? How can we engineer/design that away? Wizards, reduced options, templates, pre-populated charters of accounts, timely pointers to help, encouragement via email…
• Identifying our most frequent support tickets, help lookups, most critical training items. How to improve/speed up user experience and reduce support overhead?
• Extra focus on published APIs for customers and third-party implementers. How can we enable customization on an increasingly standardized core product?
• Standard (precise) packaging and pricing, with no easy sales-led reconfigurations or mix-n-match. Good/Better/Best or Bronze/Silver/Gold editions tied to clear customer segments.
• Heavy use of third-party connectors and instrumentation to keep our scarce development energy on differentiation.
• Identifying current customers with complex implementations. What’s our migration plan to get them on absolutely standard packaging? Which extensions can we “give” to third-party services partners for long-term support? Slowly, we'll wind down the huge support burden from custom work.
• Customers that we should drop? Rarely used features we should sunset?

HR/PEOPLE OPERATIONS

We’ll have some confused and unhappy employees, concerned about their roles/jobs and overall corporate direction. This is a company-wide change management challenge. We should plan on

• Frequent communications from the CEO about why this is critical. Reasons, impact, outcomes, encouragement, celebrations of early wins.
• Especially for Customer Success, preemptive plans around retention, executive attention, keeping great people, capturing historical knowledge. As services organizations shrink, what opportunities can we create that let us keep their hard-won expertise?

SOUND BYTE

There’s a lot of discussion about moving from services models to product models (and a ton of value to be reaped), but less thought about the department-level implications. It’s really hard, so shouldn’t be undertaken lightly. Executive teams should talk through the challenges and implications before embarking on this journey.