Building your life like a software product

A couple years ago, in a fit of creativity and post-breakup soul-searching, I started writing down things I wanted to accomplish in my life.

I decided to create this whole concept of my existence that mimicked a product development approach. I began by defining a vision for how I want to live and tried to break it down to various sub-pursuits (projects). My thinking here was:

• Business products seek product-market fit (businesses want to make something people perceive to have value and therefore want to buy). Likewise, I want to make something out of my life that provides value to me.
• In this analogy, I am the market and my life (my relationships, income, career, etc.) is the product. I have to find a way to craft a life that I find meaningful and valuable.

I also acknowledge that this product-oriented approach is just a way, in a field of many methods, to structure one’s pursuit of meaning, happiness, and value.

So, I started with a Values Declaration, in which I lay out my mission — the various experiences that I believe make me happy. Below is a figure I drew illustrating my three main areas for self-improvement:

In this document, I also wrote a mission statement for myself. Not going to repeat it here word for word (because it sounds really cheesy like the kind of euphemistic, flowery language that some giant corporation like Target would use to describe its aims), but I will say that it helped a lot to frame how I thought about myself and the purpose/direction of my life. Things like: strong relationships with friends and loved ones, intellectual achievement, and financial comfort.

My Measurements

A good product manager uses success metrics to get a sense of how a product is doing and to make adjustments when needed. So, I created supporting KPIs (key performance indicators) to track how I progress toward each “plank” of my mission statement. I selected:

• Number of Meaningful Relationships: a spot-check of the number of people I feel I have a meaningful relationship with. The “meaningful” part of this tends to mean a relationship that is intellectually stimulating or loving: family members, my girlfriend, friends, but not brief acquaintances.
• A Relationship Quality Index: (a scale from 0–100, 100 being the highest quality) A spot check of the aggregate quality of all of the relationships I have: family, romantic, co-workers, and friends.
• Estimated Hours Devoted to Intellectual Self-Improvement: The number of hours I’ve devoted to any intellectual pursuit (film, literature, writing) over a given period of time.
• A Happiness Index: (also on a scale from 0–100, 0 being no more will to live and 100 being pure, heavenly ecstasy) Very fuzzy. This is also a spot check catch-all of how good I feel psychologically and physically, based on my relationships, job satisfaction, financial well-being, goal completion, etc.
• Net Worth: Dollar value combination of cash, investments, retirement and an estimate of the total value of my possessions.

These metrics are far from perfect in capturing the total progress toward really abstract concepts like the “quality of relationships”, but I felt it was important to take a stab at some kind of quantitative measure. I needed something to guide which projects I would take up, some numbers I could move the needle on. I started recording all of them on weekly basis in a Google Sheet, which I’ve now done for two years. I figure at some point I will have enough data to draw some interesting insights about my life — like if any of the metrics have an especially high correlation with my happiness index.

The transition from a Waterfall personal goal-tracking system to Agile

My first idea, in 2015, was to start with a five-year plan and work backward from that. I ended up with a set of google docs, respectively titled:

• Five year goals
• One year goals
• 6 month goals
• This month’s goals
• This week’s goals

The design was that this week’s goals would roll up to this month’s goals, which roll up to 6 month goals, etc.

This turned out to be very difficult to maintain and I found that it’s almost impossible to determine exactly where I wanted to be in five years, or even in one month — how do you account for all the unplanned opportunity you find along the way?

I also found this system to be pretty prohibitive of what my friend Graham calls “contingency”, or the spontaneity that gives life its tang.

I discovered later that the initial system I created was akin to the Waterfall methodology of project management, where a feature or end product is determined entirely ahead of its release. In the software development world, this means that you create user requirements, hand them off to designers to create the interface, the designers hand off their mocks and specs to engineers who code up the application to fit the designs, the engineers then send their code to quality engineers who check for bugs, and the quality engineers in turn give the go-ahead to release the code to a production environment. It flows like a waterfall, each person in the system passing the baton along when their part is complete.

The Waterfall method is typically defined by longer cycle times (from requirements development to launch) and less user-focus throughout the whole process.

In my first system, each week or month’s tasks were similar to a phase in the Waterfall lifecycle, each sub-task rolling up to another larger goal that I defined long ago.

So, as is problematic in Waterfall, I would often find myself working on goals for a given 6-month or year period, only to determine that I was no longer interested in the original goal, or a new goal had outdated it. For example, my goal to learn the Angular javascript framework became outdated when it became apparent that the React framework was what I was really interested in, or how my goal to get really good at rock climbing became less of a priority to me than backpacking and bagging more peaks because those things are just what I began to enjoy more so as time went on. The “market” (what makes me satisfied) had changed. The goal posts moved constantly.

These problems, that my goal-tracking system was cumbersome and that my changing desires were outdating the plans I’d made, was something that dogged me for at least a year and a half, until I found a solution.

“Agile” is a software development method that became very popular after the 2001 Agile Manifesto (written by a variety of software engineers at a conference at Snowbird, Utah), and it aspires to the following:

• Individuals and Interactions more than processes and tools
• Working Software more than comprehensive documentation
• Customer Collaboration more than contract negotiation
• Responding to Change more than following a plan

— http://agilemanifesto.org/

To be more user-focused (me-focused) with my goal planning and to respond better to change, I decided earlier this year to switch my entire goal-tracking system to a formal agile method and away from my first, homegrown system.

My mission statement and KPIs are really the only parts of my goal-tracking system that have stayed consistent. I underwent a significant change in my day-to-day goal tracking system, moving from a system of rigidly planning everything up front, to a more fluid, adaptable method.

How I manage my goals now

I don’t mean to make it sound like I don’t do long-term goal planning any more. I do, but I try to be more vague and flexible about longer-range objectives. For instance, I don’t like to try to write out in advance exactly how I’ll achieve my desired future income, as I believe that curtails opportunistic thinking and it’s nearly impossible to do anyway, I’ll just write down my aspirational target.

There are lots of ways to “do agile”, but I use the SCRUM framework, which endorses a particular set of artifacts and processes:

Artifacts (components of my agile board):

• Personal backlog, I now use the cloud-version of JIRA to manage my backlog. From using this software all the time at work, I found that I really like JIRA’s information architecture and that it contains all of the tools you really need for SCRUM.

A screenshot of my JIRA board

• User stories are the individual tasks on the cards above, the most granular form of goal. For example: “Draft a Medium/site piece on managing your life like a product”.
• Since there are only so many things I can get done in a particular time period, I scope each story with story points. Story points are an abstraction of effort and time. I use the Fibonacci sequence (1, 2, 3, 5, 8, 13…) to make estimates on how large of an ask each story is. A “1” is a quick and simple task and a “13” is a highly complex and involved task.
• I bundle user stories into epics, or higher-level initiatives that comprise lots of different stories (epics are the colored labels on the stories in the picture). For instance, “Plan a trip with friends” contains lots of sub-stories: Agree on dates, agree on a place, agree on a budget, secure commitments, etc. To complete an epic, all sub-stories must be complete.
• I have two different types of epics: *one-time *(e.g. read Lord of the Rings) and *routine/ongoing *(e.g. Personal Finance). I color the one-time epics blue and routine epics orange (just my personal preference).
• Epics fit into components (the row of blue links on the top of the board). These are broader areas of my life, like “Adventure/Travel” that span many epics.

Non-JIRA stuff:

• I still use Google Drive for a lot of documentation, like extra info or background that doesn’t fit into a JIRA issue that nicely. I also keep a google doc “Daily Notes” that I use religiously to manage daily tasks and and a lot of small trivial stuff that I don’t need to track on my JIRA board.
• I map out what I’d like to get done in coming sprints (at the epic-level — calling out important stories below) in a *roadmap *(below). But I constantly manage my roadmap due to ever-changing personal circumstances. It’s more of a guide than a rigid plan.

Processes

• I operate in two-week personal sprints, which contain what I want to accomplish in that time-span.
• To figure out what should be in each sprint, I have an 30 minute-long personal sprint-planning session every other Monday morning, where I add and update stories to the upcoming sprint backlog.
• I have daily 10-minute standups with myself (which sounds incredibly dorky as I write this) to take stock of how I’m progressing through my sprint backlog. I’ll often fill out my agenda for the day during this time, which I then use to guide my day.
• At the end of each two-week sprint, right before I begin the next one, I have a retrospective, about 15 minutes where I figure out what I can do better in future sprints and I record my metrics. Since it’s just me managing the whole process, I often make many small tweaks to my process (the way I write stories, or adjustments to how I scope). Summary listing of the documents/systems I use

Personal JIRA agile board

Google Drive:

• “Daily Notes” doc
• “Personal Metrics” sheet (for recording KPI data points at end of sprint)
• “Values Declaration” doc
• “Roadmap” sheet
• Drive folder containing any additional documentation on specific stories

Conclusion

I’m still pretty early into using JIRA and managing my life in this way, but over time I’ll starting using the software’s native reporting tools for velocity tracking (how many story points I average in a sprint) to get a sense of how much scope I can accommodate. JIRA offers a lot of really cool reporting graphs.

Already, I’m seeing the benefits and flexibility of an agile personal goal-tracking system for myself. I’m completing more and the system feels much lighter. I’m no longer spending long hours drafting out long-term plans that get outdated or are forced to change with new circumstances.