Just a Simple SQL Query

A saying often attributed to Socrates goes: “All I know is that I know nothing.”

In product work, we often operate in a fog of partial understanding: where the real risk isn’t what we clearly don’t know, but what we think we’ve already figured out.

I learnt this the hard way once during a database migration. Everything looked fine in testing: small user base, a quick update to user groups, no red flags. The script ran fast, the logic seemed sound, and everyone was juggling competing deadlines. So the migration was waved through. No alarms.

But production was 100x bigger, and that “simple SQL query” nearly took the system down. The assumption that staging and prod would behave the same? In hindsight, obviously dead wrong.

And the mistake wasn’t just technical. It was contextual. When you’re jumping between projects, balancing competing deadlines, and under pressure to ship, it’s easy to slip into a false sense of control.

Yes, maybe it’s not the PM’s job to check for server load impacts, but in that moment, nobody else did either.

That experience taught me a lasting lesson: never take the basics for granted. Even simple operations — especially the ones that seem obvious — deserve scrutiny. I’ve always been curious, but this drove home how important it is to question underlying assumptions, even when the task feels routine or already “solved.” As a PM, you’re often the last line of defence before something ships, which means asking the questions no one else is thinking to ask.

I’ve stopped hesitating to ask “obvious” questions. In fact, those are the most dangerous to leave unasked. If something feels fuzzy or hand-waved, I chase it down. Assumptions thrive in ambiguity, and chasing clarity is a core part of the PM job.

Not perfection. Not complete certainty. Just enough clarity to move forward without walking into a trap you didn’t see coming.

One of the best habits I picked up came from a former line manager. He was a seasoned PM who, before starting on a new platform, would sit down and read the full 300-page technical documentation. Front to back. Not to memorise it all, but to absorb just enough to understand the system’s core concepts and architecture. Enough to ask the right questions later.

That stuck with me. Because 99% of people don’t do that. They skim. They assume. They trust the summary, the bullet points, the “don’t worry about it” replies. But if you want to catch what others miss, you have to look where others don’t.

The same applies to the business side. I’ve found value in asking finance or ops teams to show me the dashboards they rely on: the raw reports, the real numbers. Sometimes it’s dry, sometimes it takes days to get access. But every time, it sharpens my instincts. I can spot when something’s missing. I can say, “hang on, can you clarify that?”

In the end, a clarity-seeking instinct is just curiosity in practice. It’s a willingness to learn things no one told you to learn, and to ask questions no one else is asking.

If there’s a principle I try to live by as a product manager, it’s this: keep learning, especially when you think you already know. The moments I’ve felt most confident have often been the ones where I missed something important. Not because I wasn’t paying attention, but because I assumed I understood enough.

We all carry mental shortcuts. We all operate on partial information. But curiosity cuts through that. Quietly, consistently, and without ego. And over time, it builds the kind of judgment you can trust. Not because it’s perfect, but because it keeps getting sharper.