Why you need shadowing

The activity that will bridge the gap between your operations and your product

In 2018, I joined a company called Privateaser.

I worked on their CRM. The goal was to create marketing and sales automation that would drive our revenue up.

This is where I learned about shadowing.

Shadowing is really just watching people work.

At Privateaser I watched SDRs and AEs work. This was key for me to identify useful automation.

Here is what I learned from it and why you might want to practice shadowing too.

Productizing operations is a nasty game

All companies have manual operations.

But in the current AI revolution, the gold is in the operations.

We’re all focused on adding AI to our products, which is great. But it doesn’t guarantee a win.

However, operations are things you already do manually. So if you manage to automate them, you know this will improve a metric.

But despite knowing that, not a lot of people automate them. Why?

There are many reasons for that. But one of the reasons is that most companies don’t rely on excellent operations to survive.

Privateaser is a marketplace. They help you privatize a bar in Paris for your anniversary (b2c). Or they help you organize your yearly seminar (b2b).

There are always issues when organizing events. This is a horrible space to build software in. If Privateaser wasn’t good at operations, they would be dead.

They might be the “cool bar company in Paris”, but they’re not playing around.

At Privateaser I learned to appreciate operations and humans in the loop. This company dominates its market because of ops.

This is not a surprise I learned shadowing there.

The practice of shadowing followed me ever since. Anytime I had a virtual assistant I would have him/her shadow me. And then I would shadow him/her.

Skip a step: have your engineers shadow the manual tasks

Product managers already know shadowing. Most of them already do it. But at Privateaser I discovered a shortcut.

You see, my title was associate product manager. So It makes sense I would do shadowing.

But I was a weird product manager. Because I would also do the implementation.

CRM automation is a weird space where you can definitely write “real code” and have a real software development lifecycle.

But most of the time, you’re just deploying code in production. There is no prod and staging. You find hacks to test in prod.

So it’s a bit wasteful to have both an engineer and a product manager working on this. Which is why I was wearing the 2 hats.

Hence the shortcut:

When engineers shadow ops people, they build great automations.

“Dah. Obvious, Wayne.”

Right?

Well, I have a question for you then.

Why don’t we see more engineers shadow the work of ops people?

Product managers

Because we have product managers in between.

Am I saying PMs should die as a role? Nope.

It’s very hard to do both the role of the PM and the engineer. In fact it was very challenging for me, because I had to both manage a project and implement it.

The reality of engineering is that details really matter. It’s very hard to zoom in (engineering) and out (PM) during the same day.

However, if you can, you should.

In fact, I am going to go one step further.

Do the job, watch it being done, and automate it

Yep.

You read this right.

I am saying you should also do the job of the ops person.

It’s hard. It’s painful. And it doesn’t scale, because you can’t easily hire people wired to do all these three activities.

But I claim that whoever practices this in our day and age will produce better user experiences.

Wait, I am lying.

It’s even better than that.

The user experiences will just be of a different nature.

When you wear the hat of the doer, the watcher, and the programmer, you’re just a different beast. You understand everything on 3 different levels.

You’re not relevant, you ARE relevancy.

Sounds woowoo? I am not joking, you are relevancy because you define what relevancy means.

In fact, you can bypass the “requirements” if you want.

For the first time, you can be an engineer and say:

“Fuck requirements. Fuck software.”

And you would be right, because now that you’re also the doer and for the doer, there is only one truth: the job to be done.

The worker wearing the three hats now has the right to bypass everyone else’s requirements.

He is given a job and automates it. He might as well be a black box in the system.

He does whatever gets the job done, he watches others getting the job done and he automates whatever he thinks is the best way to get the job done.

He holds the truth.

Being the doer, watcher, and programmer is the ultimate cure for:
- engineers tired of working on stuff they find useless.
- managers wondering all day why the stuff doesn’t get done faster.
- ops people asking themselves why no one wants to automate what they do.
- products that lost touch with their users.

And all of this starts with shadowing.

Side note: I want to emphasize that it’s very hard to do all three activities, so do it step by step.

I like to say that never and always are heaven and sometimes is hell. Meaning that it’s very easy to never do something and always do something. But exceptions are where problems happen.

And when you wear the three hats, you have to wire your brain to only perform like an ops person when you’re the doer, only listen and observe when you’re the watcher, and only automate when you’re the programmer. This is hard.

And this is why these roles are usually given to 3 different brains.

Tips + Homework

When you practice shadowing:

1- The shadowee (person shadowed) should try to talk out loud.

2- The shadowee should not try to explain anything to the shadower. Because then it becomes a weird workshop.

3 a - There is no activity without deliverables. This is also true for shadowing. At the end, the shadower should write on paper the ideas he got.

3 b - But ideally, the whole session is also full of micro deliverables. And this is where I have an exception for rule 2 (I hate exceptions)

One way to have deliverable is by having the shadowee ask the shadower “What do you think I will do next?“ or “Why did I do this?“

But ideally, the opposite happens:

The shadower speaks out loud and makes predictions, or try to explain why the shadowee does something.

And this is where it kind of sucks because it can easily disrupt the session, since the shadowee will want to answer.

I have been thinking of a session with three people, where the doer only does things, without speaking, and one person tries to predict, while the other rates the predictions. But I never tried.

Anyway, I will leave you with a homework:

1- pick the task you do the most on a daily basis.

2- Hire a VA on upwork or onlinejobs.ph and jump on a call with him/her

3- Have the VA read this article before the call so they have the context and the backstory. It’s always useful to know why shadowing is done, because it’s a very weird activity to perform.

4- Have a shadowing session.

5- Switch roles, and make the session a daily habit.

If you’re doing it right, this will change your life.

AI Agents?

“Euh, what does it have to do with AI agents and agency?”

Good question.

Imagine a spectrum.

On the left you have traditional product engineering org, with a PM an engineer a designer and an end-user (who oftentimes, is not even in the team by the way)

On the right, you have product engineering orgs where everyone:
- does the job
- watches the job being done
- automate the job

I claim the best agents will be built by orgs who manage to skew the most towards the right, without falling apart.

Maybe I will back this claim in another article.

Brought to you by the agen.cy team

If you enjoyed this content, go to agen.cy to learn how we can help you!