Class Four – The Third Law

The third and final law of building scalable processes is simple and easy to understand, when compared to the first two:

“A builder must focus on the minimum viable process.”

As we mentioned before, we tend to keep an additive mindset when improving pre existing processes. Our natural instinct is to keep what we have and add new things in hopes that this will lead to better results, usability or safety. More often than not, this will only lead to bloated processes with diminishing returns, harder to use and more prone to failure.

However, this is not an exclusive quirk of the old processes. This tendency of “bigger is better” can haunt process builders even when designing a process from the ground up.

Think of this: how would you design a Sales process?

Well, if we map out the client’s journey from start to end, we may get something like this:

1. Lead sees ad for your product and enters your website;
2. Lead is interested and wants to know more, so they fill out your form;
3. Sales team contacts the lead, explaining the product’s benefits and offering a discount;
4. Lead converts and becomes a client;
5. As a client, they receive invoices from the billing team;

It could get more complicated than that, of course. A client may want to leave, and you may have a team dedicated to prevent them from churning, or even going after clients that have cancelled their subscription and trying to win them back. For the purposes of this class, however, let’s focus on the process above.

When we look at it, five steps may not look like much, right?

But let’s try to build it as a single process:

1. Well, part of it is a sales funnel, so it’ll probably be a pipe;
2. We have to estimate how successful our marketing efforts are, so when a lead is created, we may want to mark their origin (such as organic or social media);
3. We’ll also probably need a lead’s contact info, such as email and phone number. Then, we’ll want to mark the date of the meeting and attach the proposal sent;
4. We may want the total amount to be billed on the record so the billing team knows how much it should put on the invoice.

So this gives us a structure like this:

It actually seems like it would work, doesn’t it?

Lead comes in, converts, billing team sends invoice at the start of each month for every record on “Won.”

Well, on a smaller scale, yes. It would work. But remember, this is about building scalable processes, so here are some questions:

1. Where and how would the marketing team insert campaign info (such as budget spent, or Cost per Lead)?
2. How would the billing team control their own process of sending invoices? Or, where would they mark that they’ve sent this month’s invoice for a client?
3. What happens if a client churns, but then returns a few months later? Would you use the same record, or start a new one? 

Using the current structure, you’ll probably have no satisfactory answer for the questions above. That’s because the structure isn’t scalable, it’s very focused and optimized for the process as it is, but won’t grow along with the company.

Also, should you add more information to the current structure, such as a “priority” field for the Sales team, you’re polluting the record for every team that won’t use that field.

The problem here is that we treated this whole sequence of events as a single process, but it isn’t. It’s actually three different processes that are connected.

1. There’s a marketing process where the input is a marketing strategy and the output is leads generated;
2. There’s a sales process where the input is leads generated and the output is clients won;
3. There’s a billing process where the input is clients won and the output is invoices sent.

So instead of this:

We actually have something like this:

As you can see, we broke down the process into three smaller one, and made it so the output of one process will feed into the next chronological process as an input.

Now we can expand on each process without interfering with the others:

1. The Marketing team has their own pipe of marketing ideas/strategies with dedicated budget, budget spent, start date and end date;
2. The Sales team has a Sales process in which the Lead’s origin is a connection to a Marketing Strategy. Let’s go ahead and use the First Law to turn Meetings and Proposals into connected tables too;
3. When a Lead is won, we’ll create a Client record and connect the Lead to that client. This way, should a client churn and come back to the sales funnel, we’ll have a history of both deals;
4. The Billing Team will have their own Invoices table and connect it to the Clients table. Then, once a month they’ll see the Active clients, send their invoice and create the appropriate record on the table.

So, the final product will look something like the sequence below. 

Here’s the Marketing funnel:

When we open a record, we can see the leads that campaign brought in:

This happens because we have a Connect Tables on the Leads pipe, that looks like this:

By opening a Lead record, we can see every proposal and meeting as a connected record, and the Sales team has access to everything, while also easily being able to create as many proposals or meetings they want from the Lead record itself.

That’s because the Meetings and Proposals tables are connected to the Leads table:

Finally, the Billing team has their own Invoices table:

As you can see, the Invoices table connects to the Clients table (as does the Leads table). So now, when we enter the Clients table…

And open a record…

We have quick access to every time this particular client’s history as a lead (even if they’ve gone through the sales funnel multiple times in their lifetime,) as well as every invoice sent.

This is a scalable structure. Each team can modify their own tables without getting in the way of the other processes. This is because the processes themselves are modular, we’re just creating the minimum viable processes for each team and connecting those self contained parts. 

In fact, each process could be entirely self reliant. If we took out the Billing process, the Sales and Marketing processes wouldn’t suffer. Even taking out the Marketing process wouldn’t hurt the Sales process: we’d lose the richness of information provided by the connections themselves, but the processes themselves wouldn’t be hurt in the process.

This structure also allows us to have richer insights and analyses by using dashboards in a way the previous structure wouldn’t:

And when we say the structure is scalable, we don’t mean just the processes themselves. You can easily add more modular processes by connecting them properly to this structure, and this wouldn’t make it more cumbersome.

A curious side effect of scalable structures is that automations and integrations tend to work way better on them, as information is better organized and there are clearly defined steps separating the processes themselves. 

With a little imagination, you can probably figure out a couple of automations that would make this combination of processes run smoother and flawlessly.

Hands-on learning

There’s nothing better to understand minimum viable processes than creating them yourself. Access your jestor account and do the following exercises:

1. Replicate the scalable structure we’ve created for the Marketing, Sales and Billing process;
2. Try to add a new process of recovering Clients that have churned. Don’t worry about automating it for now, just connect the structure properly; 
3. Build the processes below using what you’ve learned in this class.

THE SAAS STARTUP

• A startup launches new features constantly. To organize the development process, they want to build a pipe of planned features, going through the stages New Idea/In Progress/Testing/Launched;
• However, after launch, clients may report bugs they find on the features. Bugs go through a Qualification/In Progress/Solved pipe;
• After launch a feature may also be update with Improvements, which go through a New Idea/In Progress/Done cycle;
• The Marketing team sends emails to their client base with updates on the progress of new features, corrected bugs or improvements (as you can see, this is  a process that may have three different inputs). For example, a single feature may have the following email marketing campaigns:
  • New feature X on the works.
  • Feature X in Beta! Here is our preview.
  • Feature X launched! ?