3 Comments
User's avatar
Dean Peters's avatar

This hits. You don’t win arguments in product ... you win *experiments*.

Convincing fragile egos is a waste of cycles. Let the data do the talking. If someone won’t even try a reversible test, they’re not protecting the product ... they’re protecting their comfort.

Shift from persuasion to proof. And keep the door open on your way out.

Expand full comment
Alexis Kirienko's avatar

Hi Maarten!

Thank you for sharing your insights; I find them very valuable.

I mostly agree with your article and often use a similar approach in my work.

Sometimes, it's better to be flexible and try new things rather than sticking to what we think shouldn't be done.

You mentioned:

>"If the problem is that you’re not allowed to run experiments, even for easily reversible changes, then something is clearly rotten in your company."

But what should we do when there's a debate about how something affects people, and running an experiment could harm their experience?

For example, if we're discussing whether regular overtime leads to burnout, I wouldn't want to conduct an experiment that proves a point but demotivates the team.

It feels like a hollow victory.

This leads me to my second question: Is there a way to share our experiences with others, or are we just doomed to repeat the same mistakes?

Expand full comment
Maarten Dalmijn's avatar

Hi Alexis!

It depends on the kind of harm.

E.g. the overtime decision, will be made or not, even if you don't run an experiment.

If they decide for no overtime, I'd not run an experiment because it's not in my interest to do overtime.

If they do decide for overtime, I'd ask to compare it to a no overtime situation afterward.

There is a lot of research on this already, especially regarding code quality.

The problem is that shared experience is highly context-dependent.

Your situation could be so highly dissimilar that an anti-pattern for one team may become a best-practice for another team and the other way around.

Expand full comment