Digital Product Development Mindgraph
Work in progress - coming soon. Want to shape it while it is still soft? Write to sandor@aerelontech.hu.
Digital product development is the most complex domain humanity has built, and it refuses to sit still in a list. Architecture touches hiring. Hiring touches delivery speed. Delivery speed touches how much technical debt anyone is willing to admit to. Every book on the subject has to pick one order and pretend the rest follows — and every reader hits the chapter that assumes the thing they have not learned yet.
Mindgraph is the attempt to stop pretending.
The vision
A map, not a table of contents. Every concept in the Unified Theory of Digital Product Development is a node; every relationship — depends on, trades off against, is a symptom of, is the lever for — is an edge you can walk.
You arrive with a question, not a curriculum:
- Why is my team so slow to deliver new features?
- How costly is my tech debt, really?
- When do I split this service — and what breaks if I do it early?
You land on the node that answers it, and the map shows you what that answer leans on. Follow one edge and you are in the prerequisite. Follow another and you are in the consequence three quarters from now. Nothing is hidden behind "chapter 11 explains this".
Why a graph and not a mindmap
A mindmap is a tree, and a tree has already made a claim: that there is one parent for every idea. Reality does not cooperate. Team topology is a child of architecture and of hiring and of delivery. A tree makes you pick one and duplicate the rest until the duplicates drift.
A graph lets a node have several parents, contradictory neighbours, and edges that mean different things. That is a harder thing to draw and a much more honest thing to read.
What it is meant to do
- Answer a question without a course. Enter anywhere, leave when you have what you came for.
- Show the shape of what you do not know. The neighbourhood around a node is a reading list you did not have to ask anyone for.
- Carry the reasoning, not just the label. Each node holds the trade-off, not a definition you could have looked up.
- Feed the rest of the toolkit. The same structure underneath the off-the-shelf Tech North Stars, so a package and the map explain each other.
- Be readable by a model. The graph is meant to be handed to your LLM as context, so an assistant reasons about your domain with the same map you do.
Where it stands
Early. The theory exists and has been used on 20+ projects; the graph is being extracted from it node by node, and the tool that renders it is being built alongside Timelines and Tulzkit.
The first public cut will be an embedded, explorable map on the Digital-First Consultancy page — the placeholder there is holding its seat.