How Should You Master Your Data Model?

Back in the 90s in USA, my mom had mastered the art of Thursday night dinner parties.

There was always this routine trip to our favorite grocery store for the pre-party stock-fest. Being the youngest one, I was often recruited as my mom's sidekick.

In the grocery store, my mom was always in her element. She was like a field marshal getting ready for battle.

Her vigilant eyes scanned the price tags and noticed all the sales in one efficient sweep. She knew the layout of the aisles like the back of her hand.

Her discount maths was quicker than my ABCs.

Things would hit the trolley floor from all directions. Sometimes they would just magically appear. I suspected that she had some Jean Grey in her.

She'd also dispatch me on little mini-missions to get the regular stuff that presumably had low margin of error e.g. milk cartons and juice boxes.

On one occassion, I had the audacity to make some suggestions.

Me: "Mom, let's get tomatoes."

Mom: "No, we already have a kilo and half at home in the sack."

Me: "Yoghurt? I didn't see any in the fridge. "

Mom: "Sweety, there's a carton on the second rack tucked behind the watermelon".

Me: "Disposable cups?"

Mom: "Planning to take out my new glass set that's locked in the attic."

Me: "Omg. Mom, how in the world do you remember all this?"

Mom: "Just like you know where your favorites games are on your computer, honey."

-

This stunning awareness of "what we have" and "what we need" is what a Product Manager should aspire to have with respect to their product's data model.

If you know exactly what data points you store, how you store it, where you store it and how easy/hard it is to retrieve them, you instantly dial up your feasibility analysis game manifold.

When you build specs, you already have a sense of how much your data store will change and extend.

In fact, I'd often get into conversations with developers where they'd be planning to add a new table or fieldset when there was no need. I'd propose them to pick up values from pre-existing tables (or replace unneeded ones) or at best transform them to avoid work.

Knowing your data landscape also allows you to gain self-sufficiency in reporting, especially if you know SQL (query language).

I'd even say that before embracing a programming language, PMs looking for a technical edge should learn databases & SQL first.

DB & server logs tend to hold accurate data (at times, more so than analytics tools) and if you know how to mine them, you don't need to wait for devs to build reporting interfaces & follow up on JIRA tickets.

Just make sure you're loading heavy queries on DB mirrors rather than production. I've landed in hot waters before for flatlining the website before. Guilty!

And if your product uses noSql (ex: MongoDB) or GraphQL, I'd still suggest start with understanding relational models before graduating to other forms.

Tldr? Be a master of your data model.