Class Two – The First Law

If you’ve read our core material, you already know the first law of building scalable processes:

“A builder must think linear, but build parallel.”

In case you don’t know what that means, don’t worry. We’ll guide through the main points.

It’s not unusual for people trying to build processes to do the following steps in their mind:

1. Think of all the steps and data necessary for the process to run;
2. Imagine the process in chronological order;
3. Build everything as one single block putting information linearly on a single table that should be filled as the process goes on.

It might make sense at first glance, but that’s the kind of reasoning that spawns monstrous spreadsheets with dozens of columns. Not only will this kind of structure be hard to use, but you also lose key components in scalable processes: organization and adaptability.

Let’s look at a simple example. Imagine that we’re trying to build our own custom CRM. This involves having a pipe of possible deals and recording all sorts of information relating to a specific lead.

So, when we think about the process chronologically, it goes something like this:

1. Account Executive inputs lead’s contact info into the CRM, such as name, phone and email;
2. They estimate the probable contract value based on certain conditions;
3. They set a date for a meeting, after which they send a proposal;
4. After sending the proposal, they follow up with the lead to close the deal.

The list of important information, then, will look something like this.

• Client’s email and phone number;
• Meeting Date;
• Follow up Date;
• Proposal .pdf;
• Status (in which part of the funnel the lead is).

Now, so far we’re doing great! We’re thinking linearly, and have mapped all the important data we’ll collect along the way. The problem is when we start building the CRM, and apply linear building to this process.

In doing so, we’ll end up with a building block that looks something like this:

[deals: client name, client email, client phone, value, meeting date, follow up date, proposal, status]

This structure will hold up as long as the process never deviates from that standard form. However, we can quickly see that’s not the case: 

• Sometimes the Account Executive will have to schedule more than one meeting;
• Sometimes, there’ll be more than one proposal following arduous negotiation;
• Sometimes, we’ll need more than one follow up until the lead responds.

So, if we tried to modify this block to contain all possible scenarios and still build the structure linearly, we’d get something like this:

[deals: client name, client email, client phone, value, proposal, status, meeting date 1, meeting date 2, meeting date 3 . . .]

This is not a scalable structure.

If we tried to build our database on this logic, it would look like this:

It works, but barely. Not only is the data messy, the structure itself is shoddy. Will I have to create a fourth follow up column if I require for one of the clients?

It’s much better to build the whole process with different, smaller building blocks. In order to understand if a group of data should be a separate building block, there’s two questions you need to ask yourself:

1. Will this group of data be used somewhere else outside of this process? (that is: other processes may “borrow” the same structure)
2. Is this group of data repeating information? (that is: you can have many sets in one record?)

In this case, we can see that the client’s information satisfies condition one. After closing the deal, this information may be used on various other processes, such as billing or customer success.

We can also see that meetings, proposals and follow ups satisfy the second condition. They won’t be used anywhere else, but they are repeatable for a single iteration of the process: a single deal may have a variable number of meetings, for example. 

So, instead of having a massive building block, we may split all of the process into separate building blocks, even adding new information:

[deals: id, amount, status]

[clients: client name, client email, client phone]

[meetings: date, type, notes]

[proposals: amount, attachment]

[follow ups: date, done?]

Now, how do we connect all of this and build a single structure?

If you read Class One, you know that connections have a direction. This direction generally implies a hierarchy: the table you’re connecting to may have several records of the table you’re connecting from. It’s almost like a pin cushion. You may stick many pins into a single cushion, and you may have several meetings for a single deal.

So, knowing that a client may have many deals in their lifetime, and also that a single deal may have many proposals, meetings and follow ups, we can venture a guess that our building blocks will look like this:

How would this structure look on jestor?

Well, you’d have the client’s information:

Then you’d have the sales pipeline:

And then you’d have different tables for meetings, proposals and follow ups:

The best thing about this structure is how organized and scalable it is: you can quickly navigate to the client’s info just by clicking on his name from the sales pipeline.

But you can also open the deal itself and look at the connected area to see every proposal, meeting or follow up related to that specific deal.

You can even edit that information on the right panel directly on the mini table.

In the end, using our building block notation, we’ll have something like this:

[clients: client name, client email, client phone]

[deals: id, amount, status, ↑client]

[meetings: date, type, notes, ↑deal]

[proposals: amount, attachment, ↑deal]

[follow ups: date, done?, ↑deal]

Now, you get two great advantages here:

1. This is much more organized and scalable than the other structure. I won’t have dozens of fields that I may or may not use on the card: by using connected data, I have as many records I need connected to that record, not more, not less;
2. This is highly adaptable: I can change the Meetings table structure without having to worry about breaking the other tables. I can even stop using it and just leave it there as history: it won’t impact the use of the other tables.
3. This is highly iterative: if I need more building blocks (such as tasks, for example), I just have to create the table and connect it.

As you can see, a scalable process begins by thinking linearly, but can only be scalable by building parallel structures.

Hands-on learning

To really cement the concept of the First Law, access your jestor account and do the following steps:

1. Replicate the structure we’ve created for the Sales Pipeline. Navigate and explore the connected area of the records;
2. Build the process on the image below on your jestor.

You can also check out how we solved these exercises on our Class Two template in the store).