This is part 3 in my ongoing series about productized services. This came out of a recent interview I had with Nathan Barry for his upcoming book: The Ladders of Wealth: How to Master the Skills of Making Money (sign up to learn more).

That conversation pulled me back into all the early mistakes I made while building Paperboy — and honestly, the mistakes I still see most agency owners make today.

BTW: even if you don’t run a "productized service", these lessons still apply. They’re really about building systems, managing clients, and creating leverage — things that matter no matter what kind of business you’re running.

--

One of the biggest traps I fell into early on at Paperboy was trying to systematize everything way too early.

When you first move into a productized model, we all hear the same damn advice:

• Build SOPs
• Create templates
• Standardize your delivery
• Automate everything you can

So that's what I did.

I spent weeks writing documentation, building out process maps, creating internal libraries, writing scripts for my team.

I let my undiagnosed OCD go wild.

And while none of those things are "bad" in and of themselves, doing them this early turned out to be a massive waste of time.

Here’s why:

When a productized service is brand new, you don’t actually know what the real process is yet.

You think you know. Or, if you're like me, you're arrogant enough to believe that you can guess...

But you don’t.

Because the moment you start delivering the service to actual clients, everything changes.

• You learn what steps actually matter
• You learn which deliverables don’t
• You learn what clients care about
• You learn where the bottlenecks really are
• You learn what your team naturally gravitates toward
• And you learn what needs to be improved, removed, or rebuilt

And every time the service evolves (which it should, constantly), all those early SOPs and systems get thrown out.

Can't tell you how many times I cringed when I had to archive yet another outdated document.

In fact, I’ve probably deleted more documentation than I’ve ever used.

FML.

So now I follow a simple rule:

I don’t fully systematize anything until we’ve run it for at least 3 months in real-world conditions.

Three months gives us enough reps to see the patterns.

It shows us which steps are permanent and which were just "guesses".

It forces us to build systems based on reality rather than hypotheticals.

Now don't get me wrong. That doesn’t mean everything is chaos for 90 days. We still outline a basic process. We still write a loose checklist. We still record a Loom walking through how we think we’ll do something.

But we keep it lightweight — just enough structure to give the team direction, without locking us into a bad process.

Think of it as a minimum viable system.

Then, once we’ve run it long enough to understand the truth of the service, we go back and build the polished SOPs, templates, automations, onboarding flows, and training docs. All the good stuff.

So what's the lesson?

Don’t try to build a perfect system before the service itself is proven.

Systems should follow clarity — not try to create it.

— Shane