Class Three – The Second Law

The second law of building scalable processes may seem abstract at first glance:

“A builder must use outcome oriented design.”

However, it may be best understood when we put it in a more worldly manner: throw the trash away.

Simply put, a scalable process is one that, yes, may improve upon existing processes, but is always conscious that pieces that were used in the past are not always necessary. In fact, keeping things that worked in the past may actually be harmful in the long run.

For a quick example, it was quite common for companies to require a manager’s signature on a myriad of documents before softwares allowed those same documents or processes to be digitally approved by that same manager. 

However, even after the advent of such software, a lot of companies still demand that documents should be printed and signed. There’s no special need for this requirement: it is merely an artifact carried from older iterations of the process, and is generally harmful for little gain:

1. It generates trash (as in physical waste);
2. It requires storage space (before being disposed of);
3. It’s a pain to sort through if for some reason you want to have access to it.

Now, why did those companies still keep that part of the process, even though it was eventually rendered useless? In some cases, there was a proper reason (a government or contractual requirement, for example.) However, in many others, there was no thought process involved in keeping it. It was kept purely because it already existed.

You may be wondering now what does this have to do with “outcome oriented design.” Well, ask yourself this: how do you know which parts of a process are necessary and what aren’t? How do you know if you should still collect a lead’s phone number, or stop sending an email to the inventory team after every purchase?

It’s only by knowing what are the desired outcomes of the process that you’ll be able to weed out the unnecessary parts of it. That’s what we mean by “outcome oriented design”: whatever you want as a result of the process should dictate what steps, structure and data the process needs, not the contrary.

Too often when improving upon a process, people will use the reverse logic. They try to keep whatever they have at the moment and then build more things in the hope that this will make the process better, with no regards for new technologies, goals or team capabilities. More likely than not, this kind of additive building will fail to deliver something truly scalable. 

Input Oriented Design vs Outcome Oriented Design

To show you how harmful an Input Oriented Design can be when building processes, we’re going to go through two different versions of the same process.

Picture this: a marketing agency has always used the same structure for taking requests from their clients:

1. A client will send an email with a request;
2. Upon receiving this email, an employee dedicated to this task will feed the info into a collective spreadsheet and answer the client’s email;
3. The operations team will start working on this request, often communicating through the spreadsheet or email, and send an email communicating the client whenever the request moves a stage forward;
4. Sometimes they’ll need a file from the client, requesting it and uploading it to their drive when receiving it;

Now, let’s say this agency has decided to improve their processes with jestor (good for them! ? )

They intend to automate as much as they can, but using Input Oriented Design, their rationale will be something like this:

1. We need a way for the employee to type in client requests on the Requests pipe;
2. We need to send emails when certain conditions are met;
3. We need an URL field for the client files;

So let’s go through the resources we’d need should we go with this structure:

Software/Tools:

• jestor
• E-mail
• Drive

Team:

• Operations Team
• Dedicated employee to take requests

Integrations:

• jestor + Email
• jestor + Drive

This will work, of course. It’ll, however, demand more manual tasks and, even if you try to automate some parts (like creating a request automatically upon receiving an email from your client), the truth is that fine tuning this integration will take a lot of time and probably won’t be 100% reliable.

Now, let’s use Outcome Oriented Design to build the process from the ground up.

The most important question is: what do I want from this process? 

Well, when we think of results and not of replicating what we have now, a nifty transformations occurs:

• I need to type in a client’s request -> Client’s request must reach the Operations team;
• I need to send emails -> Client needs a way of knowing how his request is moving along;
• I need to link to the drive -> I must have information readily available.

So, when we know what is our need, and not what we want to replicate, we can think of different, better ways to achieve that goal:

• We can grant clients access to our jestor so they can add requests on their own, using the permissioning control so they only see their own requests (or whatever info we want them to see);
• As they have access to their requests, they don’t really need to receive emails on each request status. They can just open jestor and see for themselves;
• The Operations Team can even request files through the request itself, and the client can upload it on an Attachment field.

If you have a keen eye for resources, you may have already noticed that this new process delivers the same results, but cuts out the need for email, drive and a dedicated employee entirely, as well as integrations. Our resources list look something like this:

Software/Tools:

• jestor

Team:

• Operations Team

It becomes incredibly more efficient in any way you try to look at it. Yes, we can then automate the process to send emails, for example, but only if we really want to as an extra feature. Integrations become improvements, rather than necessities.

This was only achieved, of course, when we changed our mindset to prioritize building the best solution towards a desired outcome, and not achieving an outcome with the solution we already have.

Cutting down to scale up

The previous example demonstrated how you can use the second law to cut down the number of resources necessary for a process to run. However, you can have efficiency gains even inside jestor itself by using Outcome Oriented Design. 

As a last example in this class, let’s think about the following process:

1. Procurement staff purchases items from suppliers;
2. When the order arrives, the staff at the warehouse checks if every item bought is accounted for;

Now, we can imagine a process in which the procurement staff emits a Purchase Order with every item bought. Then, the warehouse staff prints a list with these items and writes down the quantity received.

Traditionally, this would be done on paper. This means you’d have two separate documents, one for each step of the process.

So, if we’d tried to replicate this in jestor without using Outcome Oriented Design, we’d get something like a pipe of purchases:

Then, we’d have two connected tables. One for the items bought:

And another for items received, simulating the form the warehouse staff would fill.

The final product would look something like this:

Now, this would also work. It’s not even that cumbersome. However, these little inefficient building decisions really add up when building larger processes. 

Let’s try to apply an outcome oriented approach, shall we?

When we think about it, all we need is for the warehouse staff to do is mark if every item bought was received or not. Does it really need a separate table to do this? No, it doesn’t. We already have a table that shows a listing of items. Why don’t we just add a field where they can mark how many of each item they received? Like this:

We can even add a formula field that shows number of items bought – number of items received.

Then, we can even add a component on a dashboard to show items that show a difference, that is, where the difference between bought and received is more than zero.

As you can see, not only is the process leaner, it’s better. It lets us use the data better, which in turn can make processes more failproof and even provide insights that are not possible when information is not grouped correctly. 

Keep this in mind: processes that use Outcome Oriented Design are scalable, leaner and use the full potential of your data.

Hands-on learning

To highlight the differences between Input and Outcome Oriented Design, access your jestor account and do the following exercises:

1. Replicate the two structures we’ve created for the procurement process;
2. Try to improve the process below using Outcome Oriented Design.

THE LAB

• A Lab routinely runs experiments.
• When initiating an experiment, the staff has to write down in a form the ingredients necessary and how much of each was taken from the stock.
• Also, the staff sends an email with an  estimated end date to the management.
• After performing the experiment, the staff has to fill a different form specifying how much of each ingredient was actually used.
• They have to write down notes for each day of the experiment on a spreadsheet and categorize the days progress into Good, Regular or Bad.
• When the experiment is over, they send an email notifying the management.

Overall, the needed resources are:

• jestor
• Emails
• Spreadsheets
• 2 Forms

Use Outcome Oriented Design to slim down the process. By using connected tables and dashboards, you only need jestor for it.

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