Category Archives: Systems Thinking

Big Unified Index Card Productivity System #1: Nouns vs. Verbs

So I’m working on my latest Big Unified System and I ran into a theoretical question. In trying to ask some friends the question, I ended up talking myself through it instead and, in the process, finding the next interesting question.

Broadly, I’m working on organizing my life on index cards with each card representing a (big or small) goal state, broken down into a list of (big or small) steps to get there. As appropriate, each step can then get its own card and get broken down further, until the steps it’s broken down into are concrete things I can just go do.

I was initially going to put values as the top level cards, broken down into more specific target states/quality of life statements (CONNECTION > Healthy marriage / I play with my kids regularly / etc.)

But a target state like that can definitely help fulfill multiple values. (And, similarly, a single project could move me toward multiple target states.)

I was hoping to design a system where all the cards have the same fundamental design, essentially working recursively all the way up or down, but now I’m wondering if I need to distinguish between two kinds of cards, roughly target states and projects/tasks (or, you could say, nouns and verbs). 

Except I typically state my projects as a verifiable end state as well (monthly reporting completed, kitchen clean, firstborn displays willingness to come to me with problems, etc.). So I’m realizing nouns and verbs are not different kinds of cards. It’s more that the title of each card is a noun and then the items listed below that are either the verbs that would move me toward it or additional (intermediate) nouns that should then (recursively) get their own cards. 

Which means the real problem is not fundamentally different types of cards, but the many-to-many relationships that can exist between cards (and which screw up my default hierarchical/tree way of organizing this).

That’s mainly a problem because I was hoping to only ever have one pointer back up to a parent project at a time, but the more I think about it the more I’m not sure that’s accomplishing what I intended (which gets into the fiddly technicalities of implementing the system).

Anyway, turns out the real question is how to cleanly represent (and track progress in) many-to-many relationships. 

Which should be an interesting one, because a big paradigm shift earlier was when I realized that instead of picking my “top priority“ value or quality of life statement and then picking the “top priority“ project within that, it’s wiser to look at all of my goal states (at a similar level) together and creatively brainstorm to find a project that can move me closer to the collective goal state. So there’s probably some more juicy insight to be discovered in that vein.