The tale of Services v.s. Cloud product organizations

As companies transition their product delivery methodology from on-premise software to a As A Service (PAAS/SAAS) model, they are confronted with very different motions across their Sales, Marketing, Development, Services and Support organizations.

One of the examples that show the difference how ‘execution’ is done in these models, is how Services and Product is managed across the organization. For larger on-premise software companies it is not uncommon to see Professional Services (PS) bookings v.s. software bookings rates of >3, meaning that customers pay more for the implementation and assistance in software management, then the actual purchase price of the software.

The Cloud delivery model has very different PS dynamic, as Waterstone reports in their 2015 report – changing Professional Services Economics ;

“There is growing preference for Cloud- and SaaS-based solutions that, on average, have a PS attach rate around 0.5x to 1.0X (versus the 2.9x PS attach rate commonly seen with traditional licensed products).”

The analysis is not strange, as Cloud is all about providing low friction of onboarding by self-service and automation. This means getting the human out of the equation, as it’s a limiting factor in scalability and raises cost.

Cloud is all about minimizing the time from idea -to- revenue, while being able to scale rapidly and keeping cost low.

The definition of ‘the product’ in a Cloud world therefore isn’t only about the bits & bytes, but includes successful onboarding of the customer and maximizing their usage.

It is not uncommon for product management to ‘only’ own the technical product management in an on-premise software company and not hold the responsibility of the full service offering. This is both due to how on-premise software companies evolved with their added PS services, as well as the evolution of the product management role in general, due to the introduction of the Agile methodology and Cloud delivery frameworks.

In a business transition, from being a on-premise software company to a Cloud product (SAAS or PAAS) company, it means the company needs to relearn what it means to be a product company.
As I regularly mention in other blogs, talks and tweets, Cloud transitions are about changing technology, process and organizational structure/culture, with the hardest parting being the organizational change.
The shift from an on-premise software to a Cloud product led company means a reset on how to run product management.

So, let’s ignore the technology and culture change in Cloud transitions for a moment (me and others have written lots about Cloud architecture and DevOps already) focus on product technology portfolio management in this change process;

The transition of on-premise products to a Cloud product should include a thoughtful evaluation of the company’s current product capabilities, feature set and market landscape, as well as the company’s ability to switch to the new delivery model across Sales, Marketing, Development, Services and Support. All these departments should evolve to fit a product’s evolution. This means dialing down effort, focus and investment in on-premise, while dialing up in a Cloud delivery motion.
The transition requires setting a multi-year roadmap for a specific feature set and then leading that execution across departments and silo’s in the organization. It needs a product leader, that can balance the current on-premise world revenue and investments, while executing against a company-wide roadmap that will transition the feature set to a Cloud delivery model; a mini-CEO for the selected feature set; a product leader.

A couple of my view points and learnings on the product leader role in a Cloud transition:

The ‘cloud product’ is a selection of features grouped in a logical way, plus the services needed to generate the total value to the customer. The cloud product therefore can be a selection of different components and services, that provide the higher level product. Handing over 10 on-premise products with very different functions and/or addressable markets to 1 product leader, will set your product leader up for failure, as the product leader role is already very broad. As products and services evolve over time, it’s okay to split or collapse these cloud product groupings and their leaders.
In a transitional model, moving from an on-premise product to a Cloud offering, the product leader is responsible for the strategic roadmap. This includes grouping different components and services together from the on-premise portfolio in to a new cloud product, as well as the decision on End of Life (EOL) of the on-premise product. Product life-cycle management is an important task for the transitional product leader.
Product leaders in a Cloud world need new skills, as rightfully pointed out in recent a McKinsey article.
Traditional on-premise Product Managers typically don’t worry too much about Non Functional Requirements (NFR) in their products. As the definition of a Cloud product includes ability to scale and run reliable at a low cost, the NFR’s will need to be included on the tactical product roadmaps. Providing the product leader with cost and SLA KPI’s will provide the right incentive during the transition.
Agile methodologies and Cloud architectures bring new dynamics to product management. For example: Building an on-premise product has the concept of ‘done’. Building a Cloud product doesn’t have the concept of ‘done’, as it is only done when the service is terminated.
Even though I don’t like the mini-CEO label, it is important the product leaders are setup for success by the companies senior leadership team. The product leader needs to lead the strategic direction across sales, marketing, services and product development/operations. The different teams and departments should act as subject matter experts, assisting the product leader on the execution of the Cloud product strategy. As there is a heavy execution reliance on R&D and Services, the product leader should have a team of product managers in his/her reporting line, that own the definition and execution of the sub-components needed to deliver the full Cloud product. There should be no other HR reporting lines in to the product leader.
The only debatable HR reporting line in to the product leader, besides product managers, is Product Marketing. My recommendation is to only do this if Product Marketing owns the pricing of the cloud product, as in my view pricing shouldn’t be part of Marketing but a Product Management function.
There is a large ongoing debate if the product leader should own a P&L. If the product leader is the mini-CEO ,why not own the P&L at the same time ? Actually in a Cloud product world the product leaders main KPI may not be the P&L, but is most of the time more focused around increasing growth, and/or reducing churn rate, and/or driving up engagement, or driving revenue. Profit and cost are good KPI’s to track for a product leader, but it is not necessary to own the P&L. Only if the leadership team feels the P&L ownership for the full Cloud product across different departments and silo’s, will help to drive alignment and behavior, I would recommend this as a last resort.
For KPI recommendations see also The Product Scorecard

As the Cloud product evolves with less reliance on on-premise revenue, the product leader role also evolves. As the McKinsey article points out:

“Over the next three to five years, we see the product-management role continuing to evolve toward a deeper focus on data (without losing empathy for users) and a greater influence on nonproduct decisions.
Product managers of the future will be analytics gurus and less reliant on analysts for basic questions.”

In a Cloud transition the product feature set moves in to more automation, self-service and the concept of managed hosting is fading away in favor of a shared, agile and scalable Cloud platform. This may leave a (Professional) Services organization wandering if they have become irrelevant in a Cloud world.

Where in the past the Proffesional Services (PS) department within a software company would be focused on installing, customizing and deploying on-premise or hosting applications for customers, their focus should now be shifting to assisting customers in their business transition to the Cloud. This includes design, implementation , and adoption of new technologies like machine-learning and data analytics, and migration of workloads to the Cloud. With this shift software companies become partners to their customers and not just vendors.

To help the (Professional) Services department in the transition it is important to follow a few basic rules of the Cloud world:

Successful Cloud deployments need a mix of a mix of advisory, implementation, and Customer-Success services—on top of basic Cloud deployment. Advisory services create the opportunity to be a real partner to the customer and guide them in the business process transition, that most customers are facing when moving to the Cloud. Customer Success services, that help the customer maximize value from their Cloud product, is a new but important part of the Services organization.
Custom integration work will always be part of enterprise deployments and this is no different in the Cloud. It is important to have a thigh loop between the PS resources developing these customization’s, the R&D team and the Product leader. This allows customization’s to flow back in to the Cloud product offer and become part of the standard Cloud platform offer, available to all customers. Standardization, automation and self-service are key to the succes of Cloud and PS will need to contribute to that succes with this feedback loop.
Manage incentives, as that drives behavior ; I have seen the best success in the Cloud transition by not paying full Sales bonus on PS revenue, as Sales will turn your company in to a PS shop. It can also not be zero, as then Sales will turn in to a PS prevention unit. A rethink on bonus and revenue targets for PS resources should also be done, as they should care more about good customer adoption and succes then the bonus for the finishing a project. Many SAAS companies include basic PS services in the standard SAAS rate and manage the PS teams on customer satisfaction, not on PS specific revenue. Change the incentives, change the world.
To protect the SAAS business from being taken over by PS type activity, just like it happened in the on-premise software business, closely monitor the PS revenue vs total revenue and target PS revenue to not grow above 15-25% of total for Cloud. This is not a hard limit, but going above means you are turning in to a PS shop and the feedback cycle to your cloud product is broken. In a pure SAAS play “Professional services exists to maximize ARR while not losing money.” as Dave Kellogg rightfully pointed out in his 2017 blog.

The transition from on-premise software products to the a Cloud delivery model, requires a well-balanced product strategy across the organization, with an end-to-end perspective and a rethink of the Services business models, developing new ways to establish long-term customer relationships and loyalty.

Leave a Reply Cancel reply