Our intrepid journey to become an AI-driven company

The following post is a six page narrative I wrote for staff in October 2021. It should be noted the metrics given were as of that time period.

We adopted the six pager format after reading "Working Backwards: Insights, Stories, and Secrets from Inside Amazon."

Introduction

This is my six page narrative on the plan to transform Paubox to an AI-driven company. I began compiling it on 30 October 2021.

As of October 2021, here are the five metrics we care about:

• Annual Recurring Revenue (ARR)
• Customer Count
• Net Promoter Score
• Annual Logo Churn
• Revenue Churn

While our net promoter score, logo churn, and revenue churn are outstanding, there are aspects of the business that must improve. Failure to improve will ultimately lead to a disappointing outcome for our customers, staff, and shareholders.

First, our ability to learn and improve is too slow. It takes us too long to conduct and learn from experiments. We also don’t do enough of them. 

Second, our architecture has gotten to the point where the platform tends to break in unpredictable fashion with each sprint we push to production. 

As we continue to grow, Paubox must evolve in order to successfully reach our north star, $100M in ARR. It is my firm belief that the best way to achieve that is to change to an AI-driven operating model.

Tenet: AI-Driven Companies Yield Exceptional Shareholder Returns

A tenet, or a foundational element behind why we’re transforming our business lies in the fact that AI-driven companies yield exceptional shareholder returns.

For example, Amazon decided in 2002 to become an AI-driven company via the Bezos Mandate. Its market capitalization at the time was $7.32B; its market cap now is $1.6T. 

Google announced its strategic shift from being a mobile-first company to AI first on 17 May 2017. Its market cap in 2017 was $729.5B; its market cap today is $1.9T.

Microsoft arguably began its shift to an AI-driven company when Satya Nadella became CEO in February 2014. Its market cap in 2014 was $300B; its market cap today is $2.5T.

In summary:

• Amazon added $1,592,680,000,000 in market cap and provided an annual compounded return of 32.8%.
• Google added $1,170,500,000,000 in market cap and provided an annual compounded return of 37.8%.
• Microsoft added $2,200,000,000,000 in market cap and provided an annual compounded return of 37.6%.

The data yields a simple conclusion: Companies that adopt an AI-driven operating model produce best-in-class returns.

By achieving the same transformation, Paubox will also yield truly remarkable returns for its shareholders. 

In fact, it should no longer be a surprise to us that we are in the process of building a billion dollar company (and beyond).

The Operating Model

An operating model is how a company delivers value to its customers. While a business model describes the company’s plan for how it will deliver value, the operating model is how it actually gets done. As such, the operating model is critical in shaping the actual value of a company.

The primary objectives of an operating model are to deliver value at scale, achieve sufficient scope, and respond to changes in the market by learning. 

Scale

In our business, scale is about designing an operating model that delivers as much value to as many customers as possible at the lowest cost. 

Scope 

Scope is defined as the range of products and services a company offers. In our business, scope is also about the vertical we target, US Healthcare. 

Learning

The learning segment of an operating model is essential to delivering continuous improvement, increasing operating performance over time, and developing new solutions. 

In a nutshell, companies are both shaped and limited by their operating models. 

In our business, we can see that our ability to learn and improve is hampered by our data, as well as the way we’ve built our software. We do not have a unified data layer, nor does our software have clean, consistent interfaces. 

The AI-Driven Operating Model

The AI-driven operating model revolves around data, analytics, and artificial intelligence. 

In order for us to accomplish our goal, we’ll need to do the following:

• Remove dependencies from our code base
• Rewrite every piece of software as an API or microservice
• Build single-threaded teams
• Do not allow any data silos

Removing dependencies

In software, every dependency creates drag. For example, let’s assume the following hypothetical (as of today) Engineering departments at Paubox: Paubox Email API and Paubox Admin Panel. If the Paubox Email API team requires effort from the Paubox Admin Panel team in order to build or test a new feature, that’s a dependency. 

In essence, if multiple teams have direct access to a shared block of code or some part of a database, they slow each other down. 

To remove these dependencies and thus speed up our learning, experiments, and innovation, we must rewrite our software; either as an API or as a microservice.

Everything is an API or Microservice

Every piece of software within the Paubox platform must be securely rebuilt and clearly documented as an API. Alternatively, if a piece of software is more complex, a microservice is also allowed. 

Continuing the above hypothetical example, the Paubox Email API team will then be able to connect to components of the Paubox Admin Panel via API calls, rather than coordinating with engineers. This method will decimate the likelihood of a change in the codebase in one place corrupting or crashing the platform in another.

Single-threaded teams

We will create small, autonomous teams to move, learn, and innovate faster. Each team will have a single area of focus, work independently of other teams, and be no larger than 10 people. 

Being single-threaded means the team doesn’t work on anything else. In addition, these teams have clear ownership of a specific Paubox function (e.g., Paubox Email API) and can deliver results with a minimum of reliance or impact upon others. 

If a team member needs to interface with a set of software outside their team, they will do so via APIs.

Single-threaded teams are also built for speed. As such, each team will have a leader who will be responsible for all aspects of its area of focus.

In addition, each single-threaded team:

• Has a well-defined purpose.
• Boundaries of ownership are understood. In the beginning, these lines will be admittedly blurry. As we add engineering headcount however, our single-threaded teams should assemble in such a way that there are no gaps in ownership.
• Metrics to measure progress are agreed upon. For example, one of Paubox Marketing team’s metrics to measure will be its freemium-to-paid conversion rate (%). We are using the Level 10 meeting format to assemble a weekly scorecard to track relevant metrics.

In order to become a single threaded team within Paubox, the following must be in place:

• Compile a 6 pager for its revenue plan and have it approved by Daniel and HG.
• Each team must have a leader and a revenue plan (or otherwise well-defined purpose). These items will be spelled out in clear detail in the aforementioned 6 pager.
• The team must have at least two people dedicated full-time to it and no more than ten.
• Conduct one mandatory Level 10 meeting per week, for an hour.

No Data Silos

Enterprise software has generally improved the performance of many traditional operating model processes. Common examples are accounting, enterprise resource planning (ERP), and customer relationship management (CRM). As we’ve previously mentioned however, companies are both shaped and limited by their operating models. 

In the case of enterprise software, data tends to be placed in siloed and on specialized architecture. These include databases, data models, and outdated servers that don’t talk to each other. We are not going to allow that to happen at Paubox. 

As a rule, If a vendor holds customer or company data and does not provide an API by which to access it, we do not continue doing business with them.

In summary, I believe proper execution of an AI-driven operating model will allow Paubox to successfully compete in multiple verticals, countries, and product lines.

The Big Ideas at Paubox 

In our business, we know customers want security, reliability, and ease of use. These are big ideas that will not change over time.

For example, there’s precisely a 0% chance a customer ten years from now will come to us and say, “I really love Paubox, but could you make it a little less secure?”

The same goes for a customer telling us, “Big fan of Paubox, but could you throw in more downtime?” or “Hey, can you make Paubox harder to use? Can you make it harder for us to get in touch with tech support?”

We can build sound business strategies around big ideas that remain stable over time. 

In conclusion, the AI-driven operating model simultaneously achieves all three big ideas. It is worth any amount of work to achieve.

FAQ

Q: Why is it important for this narrative to be six pages?

A: The average human takes three minutes to read a page. This report should therefore take about 20 minutes to read, which then leaves 40 minutes for active discussion. I prefer our meetings to be an hour, as it’s an achievable amount of time for a human to apply focused concentration.

Q: How long did it take you to write this?

A: It’s taken me about 8 hours.

Q: How long will it take us to complete this transformation?

A: From what I’ve read, it took Amazon and Microsoft longer than they planned for. I expect our experience to be the same. In other words, I think it will be more than 12 months of work.

Q: How many pieces of code will we need to rewrite as APIs or microservices?

A: No idea! We will take an inventory of them in Q1 2022 as part of the Engineering team’s OKRs.

Q: How many pieces of code have we rewritten as an API so far?

A: The blacklist bot was our first one. It was released on 4 November 2021.

Q: If we’re trying to be efficient with time, why not send the six pager beforehand?

A: The time it takes to write this and the time available before the actual meeting may likely be condensed. As such, we cannot assume all attendees will have time to read it beforehand. In addition, the six pager replaces the slide deck, so no time is effectively lost during the meeting, as we’re swapping one format out for another. Lastly, this approach gives the presenting team (in this case, me) the most possible time to complete it.

Q: Does the Appendix count towards the six page limit?

A: No.

Mahalo,

Hoala Greevy

Founder CEO

Paubox, Inc.