The Power of Feedback Loops

In my previous article, I wanted to make one thing clear: you don't need to release every single day to benefit from DevOps practices.

But I might have left you with the wrong impression. Did I make you think you need to wait until the very end of your project before shipping anything? That's not what I meant.

And did I suggest you don't need an Operations team at all? I might have made it sound like feedback from outside your team doesn't matter. Wrong. It matters a lot.

Let me show you a different approach today, by introducing two concepts:

• Iterative releases of successive product versions (the MVP approach)
• Treating your customer as your operations department

Minimum Viable Product

What is an MVP? It's a version of your product that you can build in the shortest time possible, using the fewest resources available. You create it so you can get it into your customer's hands and test your assumptions as early as possible.

The goal is simple: by working this way, your final product will be much better from the end user's perspective. Henrik Kniberg captures this idea perfectly in this diagram.

Source: Making Sense of MVP

The bottom row shows the MVP approach. You start with something minimal but usable - a skateboard. Then a scooter. Then a bicycle. Each iteration delivers actual value to your customer while moving toward the final vision.

The top row? That's the traditional approach. You build components that don't work until everything is complete. The customer gets nothing useful until the very end.

Check out this article if you're curious about it: Making Sense of MVP by Henrik Kniberg.

Building Feedback Loops into Your Product

Get feedback from your customer. Listen to what they tell you. But more importantly? Watch what they actually do.

Base your decisions on real data, not on assumptions. Not on what you think they need. Not on what they say they want. On what they actually use.

Why does this matter? Because your assumptions about how people will use your product are probably wrong. Mine usually are. And that's okay - as long as you're willing to learn from reality.

Here's what a proper feedback loop gives you during the development phase:

• Device behavior in the field - You'll see how your hardware and firmware actually perform when they leave your controlled lab environment and enter the chaos of real-world conditions.
• Real user interactions - You'll discover that users don't read manuals. They don't use features the way you designed them to be used. They find creative workarounds you never anticipated.
• Field-only bugs - You'll catch those frustrating issues that never show up during testing. The ones triggered by specific network conditions, environmental factors, or usage patterns you couldn't reproduce in your lab.
• Feature usage patterns - You'll learn which features get used constantly and which ones nobody touches. This tells you where to invest your development time.

Want to know the real benefit? You stop wasting time building features nobody needs. You stop guessing. You start knowing.

Two Types of Feedback

Direct conversation with your customer is powerful. It doesn't matter if you're building on contract or creating a consumer product for the market. Talk to your users. In the first case, it's straightforward. In the second, you'll need to put in more effort.

But here's the catch: people don't always tell you the full story. There's a communication gap between users and engineers - different languages, different perspectives. Sometimes they can't articulate what they need. Sometimes they tell you what they think you want to hear.

That's why you need a second feedback mechanism: built-in telemetry and observability pipelines. Instrument your product to collect usage data automatically. This gives you the hard numbers that complement what people tell you.

Want to take it even further? "Testing in production" can be another powerful feedback mechanism. Check out this article if you're curious about "Shift Right Testing" from a Quality Engineering perspective: Why aren't we Talking about Shift Right in Quality Engineering? from Callum Akehurst-Ryan's Testing Blog.

Connecting this to "pocket DevOps"

Remember the diagram from my previous article? Let's see how it transforms when you add feedback loops and MVP iterations.

Two things change:

First - you release more often. Instead of one big delivery at the end, you ship multiple smaller versions throughout the project. Each one adds value. Each one teaches you something.

Second - feedback drives your decisions. You're not following a rigid plan anymore. You're responding to what your users actually need.

Notice those dashed lines on the diagram? Those represent optional steps. They don't run in every iteration - only when your feedback tells you they're actually needed.

Here's what this means in practice: You build something minimal but usable. You ship it. You watch how people use it. You collect data. Then you decide what to build next based on that information - not on your original assumptions.

The development team still handles everything within their iterative loop - just like before. But now they're making informed decisions instead of educated guesses based not only on their own analysis but also on user feedback.

Continuous Delivery Enables Fast Feedback

Now here's where it all connects. These feedback loops only work if you can act on what you learn. You discover users need feature X instead of feature Y. Great. Now what? Can you ship that change quickly? Or does it take you months to release an update?

People often misunderstand Continuous Delivery. They think it means you need to push updates to production with every single commit to your repository. Sure, that would be nice in theory. But for embedded systems? Not realistic. And that's not the point anyway.

Here's what Continuous Delivery actually means: The ability to get changes into your users' hands safely, quickly, and sustainably. New features. Configuration tweaks. Bug fixes. Experiments. All of it.

The goal? Make deployment possible on demand, at any time you choose. To get there, your product needs to always stay in a deployable state. And you need tools that will help you achieve this.

See It in Action in "comma.ai"

"Solve Self-Driving Cars While Delivering Shippable Intermediaries." That's the company motto of comma.ai. In my opinion, they've perfected this approach.

They're building autonomous driving technology. That's a massive, complex problem. But they don't wait until it's perfect to ship. They release early versions with limited capabilities. They learn from real drivers using their system in real conditions. They iterate based on that feedback. They ship again.

If you're skeptical about applying MVP and feedback loops to embedded products, study their journey. It's a masterclass. Watch how they ship something real, learn from their users, and ship again. Over and over. That's how you turn a grand vision into reality - one shippable intermediary at a time.