Building the Foundation from Scratch — Rever
When I joined Rever, the product was an MVP built by a software agency in Guadalajara — a mobile-first app designed for manufacturing workers to capture improvement ideas on the floor. The hypothesis was that workers would use their phones. That turned out to be wrong — phones were restricted or outright banned in many manufacturing environments, which meant we eventually had to provide tablets as shared devices on the floor. That adaptation is a story of its own. What I can say here is that the product's first assumptions about access didn't survive contact with the real world, and navigating that became one of the defining challenges of the early days.
As is typical with agency-built products, it came with significant technical debt and instability. The CTO — who split his time between Barcelona and Guadalajara — was focused almost entirely on keeping the mobile app running. The team was lean: two engineers, a freelance designer, and a CEO who was also functioning as the Chief Product Officer.
I was brought in to build the first support team. But from day one, my role was never just support — it was about closing the gap between what the product could do and what customers actually needed.
We had one client. But that client could be worth a lot. And that changed how I thought about every decision I made.
Before I could build anything, I had to understand who we were building for — and we had two very different users.
The first was the frontline worker: high volume, mostly mobile, generating the ideas that the platform was meant to capture. The second was the program manager: the person responsible for running the improvement program inside the company, reporting up to leadership, and ultimately the person who decided whether the product would be renewed or cancelled.
The program manager's experience was broken. Reporting still happened in Excel. Metrics were weak or missing. And if their job wasn't getting easier, the product wasn't solving the real problem.
I documented these needs early. Not all of it made it into the product quickly — there were too many constraints — but naming the problem clearly was itself a decision. It meant the team stopped treating the manager persona as secondary. That documentation became a reference point for months.
The second urgent problem was stability. An app that crashes isn't a product — it's friction. So we prioritized bug resolution and performance aggressively, even before new features. This wasn't glamorous work, but it was the foundation everything else needed.
When the product couldn't generate a report a client needed, I generated it manually. I sent it myself. I didn't wait for an engineering sprint. That's product thinking in its earliest form — delivering value to the customer by any means available, while you build the system that will deliver it automatically.
Growth brought a challenge that no one had anticipated. Rever's data structure was originally built around tags — flexible labels that connected ideas to plants, product lines, business units. Flexible was good for the early days. But when we landed our first global enterprise client, we realized that flexibility would become our biggest liability.
At global scale, tags multiply fast. Without governance, you end up with hundreds of near-duplicate labels created by different teams in different plants in different countries. The system becomes unusable for the people who need to report across it — exactly the program managers whose experience we were trying to protect.
We needed a new structure: something hierarchical, more like an org chart or folder system, that could hold the complexity of a multinational organization without collapsing under it. This wasn't a UI change. It was a deep architectural shift.
We ran the process the right way: prototypes shared with actual companies, feedback loops before implementation, adjustments made before a single line of production code was written. The clients stayed. And what we shipped became the foundation for everything that came after.
One of the most persistent challenges at Rever was access — specifically, getting our product into the hands of workers inside large manufacturing facilities. Enterprise organizations are unpredictable. Procurement says yes. IT says maybe. Plant managers say they're aligned. Then rollout stalls.
This led us seriously down a path: what if we controlled the hardware? What if workers accessed Rever through devices we provided, so we weren't dependent on corporate IT ecosystems or bring-your-own-device policies? We ran pilots. The signals weren't good. And more importantly, we did the math: maintaining both a software product and a hardware operation at our stage and with our resources wasn't realistic.
Knowing when to double down on what you're building — instead of expanding into what you could build — is one of the harder disciplines in product.
I came in as someone who believed in customer centricity. I left as someone who understood what it actually means to practice it under pressure.
The biggest shift wasn't philosophical — it was methodological. I had always believed in talking to customers. What I learned at Rever is that talking isn't enough. You have to watch. You have to sit with the gap between what customers say they do and what they actually do. You have to think beyond the scope you were given.
Leading product through those years — through instability, through a global architecture change, through the hardware pivot, through teams growing from three to something larger — taught me that the best product decisions aren't the ones that make the roadmap look clean. They're the ones that keep the customer at the center of the room, even when the room is on fire.
That's what I carry into every engagement now.
Rever is a continuous improvement platform designed for manufacturing organizations. During my time as Head of Product, the company grew from a single-client MVP to a global product serving enterprise clients across multiple continents.