The Reports That Disagreed With Each Other

At a Glance

Problem: Two reports, same underlying data, different numbers. Not close. Different. The platform was split across Dynamo and OpenSearch, and independent sync meant independent drift. Ask the same question two ways and you got two different answers.

Why I acted: I came in as the first product person on this platform. Once I understood the architecture, I stopped trusting the dashboards and started running my own queries straight from Snowflake. When leadership started routing through me instead of their own tools, that became the clearest signal I had that something underneath needed fixing.

Approach: I flagged the architecture as a real risk, not a rough edge. Built the case for a relational database migration to Postgres, and helped hire the engineering leader who would own the execution. Then I left before it shipped, so I’m being precise about what’s mine to claim and what isn’t.

Outcome: A former colleague confirmed the migration landed. Data availability and consistency are meaningfully better. The discrepancy problem that started this is solved. Reporting works for end users and business admins without a person standing in the middle of it.

The platform that didn’t agree with itself

The early technical bet was Dynamo and OpenSearch instead of a relational database. That decision predated me. What I inherited was a platform where two reports, pulling from the same underlying data, could return different numbers depending on which system each one happened to query.

The cause wasn’t a bug in either report. It was the architecture. Dynamo and OpenSearch synced independently, and independent sync means independent drift. By the time you noticed the discrepancy, there was no clean way to know which number was right, because both were pulled from real data.

That is not a reporting problem you fix with a ticket. It is a foundation problem.

Going around the platform to get the truth

I stopped trusting the platform’s own numbers early. When I needed something real, I went straight to Snowflake and ran the query myself. AI helped me write the more complex ones so I could keep up with the pace of the questions.

That habit turned into something I didn’t expect. Other leaders started coming to me instead of the dashboards. Not because it was my job to be the data person. Because my numbers were the ones that held up under a second look.

When you become the place the answer doesn’t change depending on who asks, people start routing through you. That is a useful position to be in. It is also a warning sign. If leadership needs a person standing between them and the platform to trust a number, the platform is the thing that needs fixing.

Building the case

I flagged the architecture as a risk early. Not a preference, not a technical opinion. A liability. Two systems that don’t agree with each other in a business that runs on reporting is a real problem, not a rough edge to smooth out later.

I made the case for moving to Postgres: one source of truth instead of two systems racing each other to be right. Around the same time, I was part of hiring the senior engineering manager who would own that decision. Once she was in seat, she looked at the same evidence and agreed. The migration became real because the technical case and the technical leader landed at the same time.

What’s mine, and what isn’t

I left before the migration shipped. That matters, and I want to be straight about it.

What’s mine: spotting the risk, building the case, protecting roadmap space for the migration to happen, and working alongside engineering through most of the execution. What isn’t mine: the launch itself. I left before it shipped, and I am not going to describe a cutover I wasn’t in the room for.

What actually happened

I checked in with a former colleague who is still there. The migration is done. Data availability and consistency are a lot better. They are still working through bugs from a move that size, which is normal and worth saying plainly rather than pretending the migration was clean.

But the problem that mattered, the one that had leadership routing through me instead of their own dashboards, is solved. Reporting is smarter now for both end users and business admins, built on one source instead of two that occasionally disagreed with each other.

The lesson

Technical judgment as a product leader isn’t about writing the code. It’s about knowing when you can’t trust what the platform is telling you, and being willing to go get the real answer yourself instead of confidently reporting the wrong one.

Being the source of truth felt useful at the time. It was also the clearest signal I had that something underneath needed to change.