Knowledge is power, or..?

Lately I’ve been thinking about knowledge in a pretty practical way, less about sounding smart and more about not drowning while I try to build things.

Everything moves too fast. There’s a new tool, framework or channel every week, and twice as many opinions about all of them.

The old loop used to work for me: ship feature, check metrics, repeat. That loop isn’t enough anymore. Writing the code was never the bottleneck. Figuring out what’s actually worth building is the hard part now.

The questions that actually matter are messier: who’s really going to use this, what they’re trying to do, what they’ve already tried and abandoned, and what “solved” would even look like for them.

I stopped thinking in lists and started thinking in connections. A personal knowledge graph sounds fancy, but for me it just means connecting what I learn to what I decide.

I use Obsidian very simply: small notes, links between ideas, post-call reflections, failed experiments, surprises.

• notes about users (their words, not my interpretation)
• notes about problems (real vs assumed)
• notes about solutions (what worked, what flopped, what surprised me)
• notes about decisions (why I picked A over B)

Without my own memory system it all turns to mush: bookmarks I never reopen, chat threads I can’t find again, AI output I’ve already half-forgotten.

I use AI every day and I love it. But AI doesn’t replace understanding your user, it amplifies whatever you bring to it. Bring a shallow understanding and you get amplified noise. Bring a real one and you get signal worth having.

What’s actually helped me:

• continuous learning about users
• writing notes even when they’re messy
• linking insights to product decisions
• creating content from what I learned

When I write a post, record a short video, or share what I learned that week, the first job is just to make it stick in my own head. Any content-strategy upside comes second.

And yes, this gets overwhelming.

If you feel lost while building, you’re not alone. Most founders and product builders I know feel this. They just don’t say it out loud.

Community matters more now than it used to. Talking to other builders calibrates me far faster than sitting alone with my own assumptions. It helps to share half-formed thoughts, to ask the questions that feel too basic to ask out loud, and to hear smart people admit they don’t know either.

I don’t need to know everything about my market. I need a better map than last week.

Knowledge graphs, triplets, and why time matters

A knowledge graph is entities connected by relationships. The basic unit is a triplet:

Link triplets together and you get a graph, not a folder of disconnected notes.

The problem with static facts

Most notes are static. Product truth isn’t.

• we targeted enterprise, then pivoted to SMB in Q3
• a pricing model worked until we hit a certain scale
• competitor X mattered a lot, now competitor Y does

Drop the time dimension and your notes slowly become wrong while still looking organised.

Temporal knowledge graphs

A temporal fact is a triplet with time attached:

(subject, predicate, object, valid_from, valid_to)

or:

(subject, relation, object, timestamp)

That lets you ask what was true then, what’s true now, and exactly when it changed.

Interactive graph example

Types of facts

• atemporal: always true
• static: true from a point in time and then stable
• dynamic: changes over time

In product work, most facts that matter are dynamic. That’s exactly why they go stale so fast.

Why single-pass retrieval breaks

Research on temporal knowledge graphs suggests single-pass retrieval breaks easily. Agentic flows do better by:

1. breaking a question into sub-queries
2. retrieving with temporal constraints
3. checking whether facts are still valid
4. iterating when context is missing

That’s close to how real product debugging works anyway. Probe, compare, update your model, repeat.

Typical temporal operators:

• Search_time(query)
• Search_specific(query, t)
• Search_before(query, t)
• Search_after(query, t)
• Search_between(query, t1, t2)

Practical personal setup

Obsidian workflow

My setup is simple:

• daily notes: what changed, what confused me
• concept notes: one atomic idea per note
• project notes: decisions, trade-offs, outcomes
• links between notes
• dates on decisions

Once a week I clean duplicates, archive stale notes, and add missing links. Over time, that turns into a usable personal graph instead of a pile of disconnected notes.

Sources

• Temporal Agents with Knowledge Graphs
• TKG-Thinker paper
• Obsidian

Structured notes plus timestamps are what keep me sane while building. The product changes weekly. The map needs to keep up.