What Do Your Business Processes Actually Do?
Spoiler: They are probably more complex than they need to be.
Welcome to my 6-part series on The Core Principles of Creating Scalable Business Processes, where I take a software engineering lens to how fast-growing startups can scale their operations.
This is part 1, The Introduction, and where we start from the basics: What do your business processes actually do?
Spoiler alert: They are probably more complex than they need to be, and that is blocking you from making the changes you need.
In Part 2, we will examine why every process is secretly a product, and how you can use that to design processes people will actually use.
In Part 3, we will create a solid foundation with a normalized and relational data structure.
In Part 4, we will keep things simple by embracing The Single Responsibility Principle.
In Part 5, we will learn how to get the data that matters by closing the loop.
And in Part 6, we will put it all together and imagine what a system like this could look like, and how it can enable 2-5x revenue growth.
But, first a story. Let me know if you can relate to this . . .
Clint’s startup was growing. Fast.
His [redacted] service had clearly found product-market fit. He had more qualified leads than him and his team of assistants, customer support reps, and software engineers could handle.
Slowing down was not an option. In fact, to impress investors, Clint needed to grow even faster - the expectation was clear: double or triple in size in the next 12 months. To get to the next round, Clint had to focus nearly 100% of his energy on growth.
Before we spoke, Clint had already set out to automate as much of his startup’s lead flow and fulfillment as possible. Using his mantra of “move fast & break things”, he quickly spun up a system that included a dozen Google Sheets spread across several workbooks, and 36 different automated workflows implemented in 3 different tools.
It was supposed to automatically follow up with clients, track shipments, and allow fast insights into what needed to be done when..
In reality, simple but important things kept slipping through the cracks. No one actually knew what they were supposed to be doing, so Clint’s employees flooded his desk with questions about all the simple tasks he had hired them to take care of. 15 hours days spent just handling all the emergencies that cropped up became the norm. Actually growing this dumpster fire was the farthest thing from Clint’s mind.
Which all led him here: telling me, a guy he had just met, that “If I have to go through this for another month, I am going to have a nervous breakdown.” The irony that his setup had the exact opposite effect of what he had intended wasn’t lost on either of us.
For Clint, the path forward seemed strewn with fear and confusion. Everything he had worked so hard to help his business was actually hurting it, and even making one small change felt like risking catastrophe.
Little did Clint know that he was only four insights away from cutting the time he spent managing the day-to-day of his business by 75%, while doubling or even tripling in size. Misconceptions in his business strategy had brought him here, and only through changing how he thought about his business could we get him back his time & sanity.
It was time to start back at the beginning and answer a simple, but fundamental question:
What do your business processes actually do?
If you are like Clint or the other entrepreneurs behind fast-growing startups I’ve worked with, your back-of-house/fulfillment system/sales CRM probably only needs to do 5 things:
Accept & store information (probably from a web form)
Allow you & your employees to review & make changes to that information
Send messages to leads/clients/stakeholders (definitely via email & maybe via text or Slack too)
Send & receive information from a handful of external services (e.g. track shipping status, alert when systems are down, etc.)
Summarize all of this data in pretty graphs & pie charts & pivot tables so you know where to improve
Sounds simple, right? Then why is it so damn hard?!
Because your system, as implemented, probably looks something like this:
Web form gets submitted
The form responses show up in a Google Sheet or other Excel-like software.
Those form responses are copied to other Google Sheets and/or a marketing automation tool like Hubspot or ActiveCampaign. This must work perfectly 100% of the time or everything is f#*!ed.
The form responses are reviewed in the Google Sheet & some information is added or edited (e.g. confirm the prospect is a sales qualified lead, etc.). These changes are once again copied to other Google Sheets that represent different stages in your pipeline. Don’t forget to copy these changes to your marketing automation tool too! Oh, and this also must work perfectly 100% of the time or everything is f*****. Repeat this process for a dozen different edits you could make at any given time.
Trigger a multi-step zap, possibly with several branches (Zapier calls these paths) that goes into one of a dozen marketing automation workflows, each with about 20 steps that look something like this: Send email, delay for a few days, check: Do we need to send a reminder email? If yes, send the next email. And maybe a text to go with it. Delay. Check again: Do we need to send another reminder email? Repeat until you decide that’s enough reminder emails.
If that describes you & what you’ve created, it’s because you’re missing the fundamentals of software architecture. Fundamentally, what you are doing is software engineering -- you aren’t typing code into an editor, but you are connecting Zapier to your database and some front-end interface to achieve the same effect.
As a software engineer, it’s easy for me to diagnose these issues: they were the same problems I had seen in software development teams. Stacks of books have been written on how to solve these problems for software teams. Now, it’s time to apply them to your business processes.
Follow these five steps and you will be able to create tech-empowered processes that help rather than hinder:
In Part 2, we will examine why every process is secretly a product, and how you can use that to design processes people will actually use.
In Part 3, we will create a solid foundation with a normalized and relational data structure.
In Part 4, we will keep things simple by embracing The Single Responsibility Principle.
In Part 5, we will learn how to get the data that matters by closing the loop.
And in Part 6, we will put it all together and imagine what a system like this could look like, and how it can enable 2-5x revenue growth..
Until next time!
Cheers,
Jackson