It started with a conversation this week with our chief scientist about subscription and add-on systems — plans, tiers, add-ons, devices, and the tangle of rules tying them together. He argued for modeling it as a graph instead of as rigid tables, and said it would both simplify the architecture and maximize its flexibility. That's the part that snagged me. Simpler and more flexible usually pull against each other. So why not here?
What does graph thinking actually mean?
I quickly pulled some info to learn, and one definition worth pinning down: graph thinking means treating the relationships between things as the primary object of attention, rather than the things themselves.
In a graph, entities are nodes and the relationships between them are edges, and crucially, those relationships are stored directly, not reconstructed every time you ask a question.
Here's what I think I understand so far about why that matters. In rigid tables, every new relationship is a change to the structure itself: a new add-on type, a new bundling rule, another column or join. The structure quietly resists the one thing the business keeps asking of it: change. A graph flips that. The relationships are the data instead of a constraint baked into the tables, so you can add or rewire them without tearing anything down underneath. The flexibility and the simplicity come from the same place: the relationships are first-class.
Why does this matter for product managers?
I don't think the lesson is "go learn graph databases." I think it's smaller and more useful: stop treating the entities as the point, and start paying attention to the relationships between them. For a product manager, the nodes are users, devices, subscriptions, and add-ons. The edges are the verbs: owns, upgraded-from, churned-to, co-purchased. And the signal I care about most: retention, upsell, abuse, seems to live in those edges, not in any single node. A table asks how many users churned. The more interesting question is which users churned, and what path led them there?
Isn't this just relational vs. NoSQL databases?
I don't think it is. Most NoSQL went the opposite way: key-value and document stores threw away relationships to fetch records fast at scale. Graph databases are the odd ones out that went the other direction and made relationships more central. A relational database actually sits in the middle of that spectrum.
The reframe I keep coming back to is a filing cabinet versus a map. A filing cabinet is built to pull out one record. A map shows you how things connect and where the routes are. For the questions I lose sleep over, I think I needed a map all along, and I'd been filing everything in cabinets.
Where graph thinking changes product decisions
A few places this might actually shift something, though I'm still learning and testing them:
Upsell becomes a traversal. Not people who bought X also bought Y, but a walk through the graph: this user, on this tier, likes these other users, who added this next. The next-best add-on is a "customers like you" path, not a flat correlation.
Churn stops blaming one cause. Not "price went up, people left," but a path: a price increase plus a weak value or experience plus a single-device household with nothing anchoring them. No single node explains it, but the combination does, and it points at a very different fix than "stop raising prices."
Abuse becomes a shape, not a row.
When graph thinking is the wrong tool
I want to be honest about the limit because I can feel myself getting excited, and that's usually when I overreach. Not everything is a relationship problem. If the question is "how many units in inventory," that's just a table, and dressing it up as a network adds nothing. The test I'm trying to hold myself to: does tracing the connections actually change what I'd do? If yes, think in graphs. If the answer is one number off a dashboard, leave it alone. A relationship you model but never act on is one you shouldn't have modeled.
The takeaways I'm holding onto (so far)
Relationships, not entities, carry most of the product signal: retention, upsell, and abuse live in the edges. The shift isn't "relational → NoSQL." It's relationships as an afterthought you reconstruct → relationships as the primary thing you store and traverse. Graph thinking earns its place only when tracing connections changes a decision. Otherwise, a table is better. You don't need a graph database to think this way; you need to start asking path questions instead of node questions.
What I'm going to try next
Take one real decision on my plate right now and, before I finalize it, re-ask it as a path question: what relationships predict the outcome I care about? and see if the answer shifts. Maybe it does, and I've found something. Maybe it doesn't, and I've learned this isn't the right lens for that problem. Either way, I'll know more than I do now.