From Tables to Decisions: What Your Database Class Teaches You About Product Management

I was recently invited as a guest speaker for a group of graduate students who had just finished a course in database management. They knew their keys, their joins and their normal forms. What they wanted to know was what comes next: how do you get from writing queries to deciding what gets built?

I started my career as a software developer, and after about twenty years in data platforms, analytics and data products, my honest answer is that the database course is not something you leave behind on the way to product management. It’s the head start. The hardest product problems I’ve worked on weren’t about algorithms or models. They were about agreeing what one row means.

I told the students three stories. Each has the same thread running through it:

Story 01

One payment, many items: a lesson in grain

In retail, tender means how a shopper paid: cash, debit, credit, or government benefits like SNAP (paid with an EBT card on eligible food) and WIC (a short list of approved items for women, infants and children). Suppliers care a lot about this, because benefit programs are one of the steadiest demand drivers in grocery. Their questions are always item-level: Which of my products are bought with benefits? Where can I grow? What should I stock?

The trouble is that payments aren’t recorded per item. They’re recorded per visit. A shopper buys five things and pays three ways, and nothing in the data says which payment bought which item.

I once saw a report that showed a television with WIC sales. WIC can’t buy a TV. What had happened was simple: someone bought a TV in the same basket as some WIC-approved milk, and because tender only existed at the basket level, every item in the basket inherited every payment in it. The sums added up. The report was still wrong.

The join every textbook warns you about

Picture the model: a visit table, a visit_item table with one row per item scanned, and a visit_tender table with one row per payment. Both children hang off visit_id, and neither knows anything about the other. Now write the obvious query:

SELECT vi.item_nbr, vt.tender_type, vt.tender_amt
FROM   visit_item vi
JOIN   visit_tender vt ON vt.visit_id = vi.visit_id;
-- 5 items × 3 payments = 15 rows

Five items times three payments gives fifteen rows. Every payment is repeated once per item, so a $45 visit sums to $225, and the socks now appear to have been paid for with WIC. It’s the classic many-to-many fan-out. It shows up in every textbook, and it still shows up in production reports.

The fix: a waterfall

Suppliers needed item-level answers, so we couldn’t just aggregate. We had to allocate each payment down to the items it could legally have paid for, most restricted payment first:

1. WIC goes only to the items where WIC was redeemed.
2. EBT is split pro rata across whatever is still unpaid on SNAP-eligible items.
3. Debit and everything else covers the remainder.

Item	Price	→ WIC	→ EBT	→ Debit
Can of corn	$10.00	$10.00	$0.00	$0.00
Gallon of milk	$5.00	$5.00	$0.00	$0.00
Cereal	$5.00	$0.00	$3.33	$1.67
Snack crackers	$10.00	$0.00	$6.67	$3.33
Package of socks	$15.00	$0.00	$0.00	$15.00
Visit total	$45.00	$15.00	$10.00	$20.00

A simplified teaching example. Each row adds up to its price, and each column adds up to what the shopper actually paid.

In SQL, the trick is to roll payments up to one row per visit before joining to items, then use a window function (SUM() OVER (PARTITION BY visit_id)) to give each item its share. Aggregate first, then join, and the fan-out disappears.

Then comes the part I care about most as a PM: reconciliation. Every row must add up to the item’s price, and every column must add up to what the shopper paid, for every visit, every day. If that check fails, the product isn’t done. I wrote about the modeling side of this problem in Untangling Retail Payment Data with AI.

Notice, too, that “WIC before EBT” isn’t a technical detail. It’s a business rule. Someone has to decide it, write it down and explain it to a supplier who asks why their number changed. Very often that someone is the product manager.

Story 02

When half your data isn’t in tables at all

The second story is about a customer insights team: researchers whose job is to understand shoppers. Their knowledge lives in four very different places:

• SharePoint: study reports, research readouts and decks
• Excel: trackers, survey exports and analyst workbooks
• Warehouse tables: sales and survey data
• Video: recorded survey responses

A researcher’s simplest question, what do we already know about this shopper?, cuts across all four. Only one of them is what a database course would call a database. So how do you join a PowerPoint to a table?

Retrieve text, query numbers

The customer intelligence platform we built treats the two kinds of data differently. Documents are parsed, chunked and embedded into a vector index, so they can be searched by meaning rather than keyword. That’s retrieval-augmented generation, or RAG. Tables stay in the warehouse and are queried with SQL. The Model Context Protocol (MCP) gives the language model one standard way to reach both, as tools it can call. The model plans the steps, calls the tools and answers with citations.

Joins don’t go away. They move into metadata.

Here’s the part that surprised the students. Take a question like “How did shoppers react to the new cereal pack in the spring study, and did sales follow?” Answering it takes a chunk of a study readout and a sales query. The only way to connect the two is shared keys: at ingestion, each document chunk is tagged with the same item, category and date keys the warehouse uses. That’s a join. It isn’t a foreign key constraint, but it’s the same idea.

And the hard part is the part you learned in class. An Excel tab says Store #, the warehouse says store_nbr, and a deck says “our flagship store.” Making those mean the same thing is entity resolution, and it’s still a data modeling job. GenAI didn’t make database skills obsolete. It made them more valuable.

The product decisions

None of the decisions that made the platform trustworthy were about which model to use:

• Permissions travel with the data. If you can’t open the file yourself, the assistant must not quote it to you.
• Freshness is a feature. Documents go stale quietly and embeddings drift. More on that in Semantic Freshness.
• Trust comes from citations. Every answer links back to the deck, sheet or query it came from.
• Evaluate it like a product. Keep a set of real questions with known answers, and re-run them on every change. It’s the GenAI version of the reconciliation check.

Story 03

Where it’s headed: modeling the shopper

Once you’ve unified what shoppers said and did, the natural next question is whether you can model them. A digital twin of a shopper, sometimes called a synthetic respondent, is a model of a shopper segment calibrated on how real people answered past studies. You can ask it new questions before you field a full survey, screen many concepts quickly, and spend real research on the most promising few.

What people say in a survey and how they react in the moment don’t always match. So the work I find most interesting pairs survey answers with video. Shoppers record responses to a concept, an ad or a pack. Computer vision reads facial expression, attention and emotional signals, and those signals are joined to what each person actually said. Yes, that’s another join, on respondent and timestamp, and the grain question comes right back: is one row a frame, a second or an answer? I went deeper on the idea in Seeing the Shopper.

This is early, and the questions matter more than the demo:

• Validation: does the twin predict a real panel it has never seen?
• Representation: whose reactions trained it, and who’s missing?
• Consent and privacy: faces on video are sensitive, so consent must be clear and retention minimal.
• Role: a twin narrows the options. Real shoppers make the final call.

If you’re starting out

Here’s what I left the students with:

1. Know the grain before you write the join. Most wrong numbers come from joining at the wrong grain, not from bad math.
2. Most “AI problems” are data unification problems first. The model is rarely the bottleneck; the keys usually are.
3. A data PM translates between the business question and the schema. That job isn’t going away. It’s getting more important.