As an Information Management Officer, I receive plenty of requests from colleagues looking for support in their day-to-day work. Over the years, one lesson has stood out clearly:
::: Never aim to build a perfect product from the first iteration.
Let me explain.
One the one had, it is due to the fact that the request itself is rarely perfect. When colleagues reach out, they’re often overwhelmed, mid-crisis, and just trying to stop the bleeding. Their ask is rarely about long-term structure, it’s about extinguishing the fire on their head.
On the other had, from the service provider’s perspective (those of us tasked with building solutions), expecting to deliver something polished and magical from poor or incomplete inputs is unrealistic. That’s why falling in love with your first product is a trap. You need to stay flexible, iterative, and above all, useful.
This mindset is at the heart of the Minimum Viable Product (MVP) approach. And over the past two months, I’ve had two very different projects remind me why MVPs matter.
Here’s a metaphor I use:
When someone comes to you with their head on fire, they ideally need a bucket of water. But if you don’t have one? Give them a brick that you have. They will accept it. It won’t solve everything, but it might knock out the flames, and then you go find the water.
In that spirit, I want to share two recent projects where the MVP mindset made all the difference.
Project 1: From Brick to Blueprint – A Donor Tracking Tool
One request came from a unit needing help tracking donor contributions and target requirements. To be honest, I wasn’t excited. The value-add seemed minimal at first glance. But we quickly mapped a basic information flow, and I configured a small database, just a simple structure with three features.
I handed it over. A week later, in our follow-up, the unit had already started using it and had ideas for improvements. Two or three more iterations later, the tool had grown to 24 features and became a key internal system, not just for them but for other units as well.
What began as a “brick”, something simple to stop the immediate fire, evolved into a structure that enabled strategic thinking, transparency, and accountability.
Looking back, the turning point was that first “brick” version. It helped calm the immediate chaos and gave us space to think clearly. From there, we iterated: always listening, always adapting. I didn’t overengineer. I didn’t assume I knew everything. And because I wasn’t emotionally tied to the first version, I was open to changing it completely as their needs became clearer.
The MVP worked, because it was timely, flexible, and rooted in their real pain.
Project 2: A Calm Request, But Still an MVP
The second project was very different. It involved creating a visual infographic of the organization’s winter response. This time, the unit had a clear request, good data, and enough time. No fires to extinguish, but still, an MVP mindset was invaluable.
We created a quick first draft, not perfect, but enough to spark conversation. Then something clicked: we had data from another project about attacks on energy infrastructure. That opened up an opportunity to tell a bigger story.
Instead of just showing response data, we created a narrative: energy systems under attack on one side, winterization response on the other. The result? A storytelling product, not just an infographic.
Again, it was iteration that made the difference. Feedback loops helped us go from tables to storytelling. Even with no fire, the MVP let us explore, test, and evolve into something far more impactful than what was originally asked.
What This Means for IM Officers
Whether you’re putting out fires or building with blueprints, the MVP approach is critical. Build what’s needed first, not what’s perfect. In emergencies, sometimes even a brick helps. And when you start with less, you often end up solving more.
- Don’t wait to build perfect. First, build something useful.
- Treat every request as a starting point, not a blueprint.
- Keep improving, but don’t overengineer upfront.
- Never fall in love with your first product.
MVP thinking allows us to respond faster, build smarter, and add more lasting value. Our role isn’t just delivering what’s asked, it’s helping shape what’s possible.
In the end, starting with a brick isn’t just about building small, it’s about building together. As I explored the concept of MVP more deeply, I realized that the real power of starting small is not just in faster delivery or cleaner iteration, it’s in inviting others to contribute. When you leave space for collaboration, each new idea, improvement, or adjustment becomes a brick added by someone else. What begins as a simple fix grows into a shared solution. One that’s more resilient, more relevant, and more widely owned.
This mindset works especially well in the humanitarian context, where urgency is real, resources are limited, and collaboration is essential. I believe that embracing the MVP mindset, borrowed from the startup world but shaped by field realities, can help us create solutions that don’t just respond to today’s fires, but lay the foundation for long-term, meaningful impact.
