Article · Field notes
Knowledge is power, or..?
13 Feb 2026 5 min read
I’ve been thinking about knowledge in a practical way lately. Less “look how smart this is”, more “how do I not drown while building products right now?”
Everything moves too fast. New tools every week, new frameworks, new channels, new opinions, new noise.
The old loop used to work for me: ship feature, check metrics, repeat. That loop isn’t enough anymore. The hard part isn’t writing code. It’s deciding what deserves to be built.
Who’s the actual user? What problem are they really trying to solve? What have they already tried? What are they afraid of? What does “solved” 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, everything becomes random: random bookmarks, random chat threads, random AI output, random half-memory.
I use AI every day and I love it. But AI doesn’t replace understanding your user, it amplifies what you already have. Shallow understanding gets you amplified noise. Strong understanding gets you amplified leverage.
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 weekly lessons, the first purpose is consolidation. Memory. The content strategy part 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 faster than sitting alone with assumptions. Sharing unfinished thoughts helps. Asking “basic” questions helps. Hearing “I don’t know” from smart people helps.
I don’t need to know everything about my market. I need a better map than last week.
Deep-dive: knowledge graphs, triplets, and why time matters
A knowledge graph is entities connected by relationships. The basic unit is a triplet:
(subject, predicate, object)
Triplet examples
(User-segment-A, struggles-with, onboarding-flow)(Feature-X, solves, Problem-Y)(Project-Z, uses, Postgres)(Decision-123, was-driven-by, user-feedback)
Link triplets together and you get a graph. Not a folder. Not a static list.
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.
A fact without a timestamp is a rumor waiting to mislead you.
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 agents are interesting here
Research on temporal knowledge graphs suggests single-pass retrieval breaks easily. Agentic flows do better by:
- breaking a question into sub-queries
- retrieving with temporal constraints
- checking whether facts are still valid
- 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
You don't need a full system
You don’t need to build a full temporal graph system to get value from this.
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
Structured notes plus timestamps are what keep me sane while building. The product changes weekly. The map needs to keep up.