I published the following post while I was the CEO at Plainflow, Inc. on September 29, 2017.
At this year’s SaaStock conference, I had the opportunity to talk with a lot of amazing people (founders of SaaS-oriented companies, marketers, salespeople, C-levels). Many of them thought that I was in marketing or that I previously worked for a marketing services company or similar.
Instead, my path couldn’t be more different. I’m a technical guy who has spent his career in the IT world. I founded my first IT company when I was 17. I spent the next 13 years building reliable IT infrastructures and web apps. I had the opportunity to see a startup grow from 3 to 60+ employees. I also lived the exciting experience of joining the 500 Startups family in 2014 (batch 11).
I credit these experiences for helping me understand the walls that tend to separate Marketing, Sales, Product/Engineering, and Customer Service from one another. More importantly, they also show me how we can tear them down.
If you are part of a Marketing or a Growth team of a SaaS company, you already know how much friction you need to overcome when you ask the Product team for changes or the deep integration of new tools. In the best case scenario, your tasks will be added to the development backlog with the lowest priority; in the worst case scenario, they’ll just be rejected entirely.
Product and/or Engineering managers typically push back on Marketing/Sales requests due to a misalignment of company goals. Even if the goals of a single team don’t seem to conflict with one another, there are often hidden cross-dependencies that can prevent a team from reaching them.
Goal misalignments are quite common and easy to explain. Here is an example:
- To improve the onboarding process, the growth team wants to run two experiments within a specific timeframe.
- At the same time, the product team needs to launch a new product feature by the end of the quarter.
- The product team will push back any growth related task until the next quarter.
- The growth team is therefore stuck and at the mercy of the product team.
You may think that the solution is to hire/move a few engineers for/to the growth team. That’s usually a bad move.
Why? Developers are famously protective of their code; they don’t want anyone to touch it and they want to maintain ownership of it and insulate it from other teams.
When the product developers lose part of the code ownership, they may think they did a poor job. Devs will not be psychologically inclined to help their colleagues and, even worse, they may try to sabotage their colleagues rejecting the new code during the code reviews or the QA process.
So, how can we fix this mess?
It starts with how companies measure the success of their teams. “Siloed” KPIs are not the only way to measure a team’s success (e.g. MQLs generated per month, the Lead Conversion Rate, and so on). Instead, they should also adopt several cross-team and company-wide KPIs that are related to product consumption and customer satisfaction.
The Customer Lifetime Value (LTV) is an example of a good company-wide KPI. I will use it throughout this post.
The LTV measures the amount of gross profit that is generated from a customer over the entire time they do business with a company. For SaaS businesses that employ a subscription based business model, LTV is calculated by multiplying the average period payment, by the average gross margin, by the number of periods the customer is expected to make a payment.
Let’s imagine that all of your teams, from Marketing to Product, and Sales to Customer Support, are now focused on improving the LTV as their main goal. You can accomplish that goal in many ways:
- (Marketing and Sales) Target the right people and communicate honestly. Onboarding non-target customers increases the churn rate and the number of open support tickets.
- (Product and Engineering) Add new features or improve existing ones. They increase the perceived value of your product and that can allow you to change your pricing, and/or increase the Serviceable Available Market (SAM).
- (Product and Growth) Implementing growth experiments in a timely manner.
- (Customer Support) Improve the ticket response time and the quality of the responses, improve the product documentation, FAQs, and so on. Happy customers are less inclined to churn, of course.
If employees share the same KPI(s), the friction across your teams is automatically lowered or eliminated.
As a result, product/project managers allocate time for requests from the Marketing/Growth team because it is in their interest to do so. Now, product consumption or the reliability of the web-app they are developing aren’t the only ways their performance is being measured.
Even if you have the full support of the company founders (or the company board), changing the way you measure the company’s success isn’t easy.
The Shared Responsibility Model
Let me introduce a model that comes from the engineering world: the Shared Responsibility Model.
The Shared Responsibility Model is used by Amazon Web Services (AWS) to explain how the security of a cloud infrastructure is shared between Amazon and their customers.
An IT infrastructure is composed of several components: data centers, networking, servers, operating systems, software, etc. If Amazon doesn’t prevent intrusions in their data centers, the security is screwed. If Amazon customers don’t perform all of the necessary security configuration and management tasks, the security is screwed.
Essentially, _a company is composed of many teams that have specific functions, but all of them are responsible for company’s success_.
At Plainflow, we want to apply the shared responsibility model across our teams.
If one team fails, the company fails. If a team is in trouble, they must ask for help and receive it from other teams.
Paul English, co-founder of Kayak, did something similar in the early days of the company. He put his product engineers in the shoes of its customer support staff.
I bought a red telephone with a really loud ringer for the office. Whenever a customer calls the help number on our website, that phone rings. The engineers initially complained about it. They said, “That’s so friggin’ annoying!” And I’d say, “There’s a really simple solution: Answer the friggin’ phone and do whatever it takes to make that customer happy. Then hang up, unplug the phone, walk it down to the other end of the office, and plug it in down there.”
It’s like hot potato. Except I take it seriously. When the phone rings, I literally jump over the desks just so I can get to the phone before anyone else
-Paul English
I’m convinced that one of my main duties as a CEO is making sure that the ego of a single employee or a team cannot destroy the company. If that happens, I will have failed as CEO.
One of the reasons that my co-founders and I decided to build Plainflow is to help people in marketing and in product to integrate different tools with minimum or no product/engineering effort and friction. And then help them to exploit all their customer data by removing the silos between the tools in their stack.
We want to improve the way marketing, sales and product teams operate by introducing several methodologies and tools already used in other departments (engineering, operations, etc).
We will do it also integrating services that are not pure marketing or sales, but that can allow you to break new ground for finding new customers or improving their happiness.