Every Platform Has Users You Didn't Plan For

A few weeks ago, I wrote about building a platform.

Not a Kubernetes platform. Not a developer portal. Not an internal self-service platform.

A literal platform.

A set of stairs and a landing that connected our backyard to a trampoline.

What started as a simple project quickly turned into something familiar. There was an initial MVP. There were changing requirements. There were design decisions that seemed obvious until they weren't. There were late-night iterations, unexpected dependencies, and more trips to Lowe's than I'd care to admit.

The funny part is that the project resonated with a lot of people.

I think that's because it wasn't really about the stairs.

It was about the way engineers see the world.

Years spent in developer tooling, technical support, observability, and platform engineering have a way of rewiring your brain. You stop seeing isolated problems and start seeing systems. You stop looking at individual events and start looking for patterns. You become obsessed with understanding not just what happened, but why it happened.

That's exactly what happened in my backyard.

After weeks of excavation, grading, crusher run, compaction, framing, decking, painting, and enough iteration to make any agile coach proud, the platform was finally in place. The trampoline had a clean entry point. The path was obvious. The experience was better.

The system was ready for production.

Then I looked outside and saw this.

Dunkin was standing in the middle of the trampoline.

Not near it.

Not beside it.

In it.

Completely at home.

Looking less like a dog and more like someone conducting final acceptance testing before approving a production deployment.

My first thought was:

"How did he get in there?"

My second thought was:

"Actually, I know exactly how he got in there."

I had spent weeks reducing friction.

I built stairs.

I built a platform.

I aligned it perfectly with the trampoline entrance.

I created a clear, intuitive path into the system.

Then I was surprised when someone used it.

That's platform engineering in a nutshell.

The intended users were my kids.

The actual users turned out to be my kids, adults, and apparently one extremely determined dog.

That distinction matters.

In technology, we often design platforms around a specific persona. Application developers. Platform teams. Service owners. SREs.

We define our users, build for their needs, and create what we believe is the optimal experience.

Then reality shows up.

A team uses a workflow differently than expected.

An executive starts relying on a dashboard built for engineers.

A process designed for one group becomes valuable to three others.

A use case nobody anticipated suddenly becomes the most common one.

The platform doesn't care who it was intended for.

It only knows that it reduced friction.

And reduced friction attracts users.

That's where years in observability and technical support start influencing how you think.

Most people would look at a dog on a trampoline and laugh.

I did too.

Then I started asking questions.

Why did he use it?

What behavior changed?

What assumptions did I make?

What new patterns emerged after the platform was introduced?

That's what observability teaches you. Not just to collect signals, but to pay attention to them.

Because the most valuable insights rarely come from the behavior you predicted.

They come from the behavior you didn't.

In platform engineering, we often talk about adoption as if it's the finish line.

It's not.

Adoption is the starting line.

The moment people begin using your platform is the moment you begin learning what you've actually built.

Before that, you're operating on assumptions.

After that, you're operating on evidence.

The crusher run pile taught me that.

I spent weeks building a platform. The kids spent days climbing a pile of rocks.

The stairs taught me that.

I carefully designed a path into the trampoline. The dog immediately found it too.

The backyard kept teaching the same lesson over and over:

Users don't care about your architecture.

Users care about outcomes.

And they'll interact with your system in whatever way makes the most sense to them.

The platform didn't fail—it did exactly what it was designed to do, and that's the point. Every platform reshapes behavior in ways you didn't explicitly plan for, which is why observability, feedback loops, and guardrails aren't optional—they're essential. Adoption isn't the finish line; it's the moment the real work begins. You have to ask: who's using it, how are they using it, what new behaviors have emerged, and what assumptions just broke? In this context, Dunkin wasn't a mistake—it was a signal. The system was telling me that access had expanded, the golden path was easy to find, and the user base had grown. If you're not paying attention at that moment, you're missing the most important lesson your platform can teach you.

Or, put another way:

Dunkin Wasn't a Bug

He was telemetry.

The system was behaving exactly as designed.

The requirements had simply changed.

---

Turns out the backyard keeps teaching platform engineering lessons whether I ask for them or not.