I built LaunchReady in my spare time, continuing to work fulltime during the day, spend time with the family in the evening, and jump online or hit the trails occasionally with friends. I also had a bunch of ideas, which served as interesting distractions from making it actually work. In this post I’ll share a few of the tactics I used to stay balanced, get past the distractions, and find motivation when things seemed impossible.
LaunchReady Series
1. LaunchReady: Meet the SaaS Product I Almost Built
Introduction and backlog ideas I hope folks will incorporate into their products
2. LaunchReady: Focus on the Customer
Some practices that helped me see through the customer eyes
3. LaunchReady: Don't Get Distracted, Getting Stuff Done
Ignoring the distracting cool ideas to get work done
Removing Barriers
Building a product in my spare time meant I was working within some tight constraints. It was fine if I spent a car ride thinking through interesting daydreams, but not if I spent my evening programming time daydreaming instead of making progress.
Get the distractions out of my head
One of the biggest barriers was all of the cool things I wanted to do with the system once it was built. Faced with “how do I make this database migration work” versus “how can I use machine learning to do that cool thing”, I would get sucked into daydreaming about the cool thing.
To get past the distractions, I let myself have a short 10-15 minute budget of time to draw or write the idea down. The key ingredients were (1) time-boxed permission to explore the idea, and (2) some form of storage (drawing or typing in OneNote). The time box forced focus but also provided time to explore and capture more than my poor short-term memory would normally support.
Once I was done, I would save my thinking and move on, satisfied that I had given it some focused thinking and would have it when it became more relevant. Some of these ideas evolved into the architecture, some helped shape the direction, and the rest went into the backlog of future ideas.
When in doubt, ship something
Some of the things I needed were so undefined I couldn’t figure out how to build them. I would find myself banging my head against the idea over and over, unable to make progress. When stuck, ship something. Then do it again.
The momentum of shipping small pieces helped me get moving and it started chipping away at the unknown. A smaller problem and seeing the thing taking shape in front of me provided focus and context. Eventually it would become clear and I would be unstuck, sometimes already headed in the right direction and sometimes having to backtrack and do some rework. At the end, even if I had to write some things twice, I was past the blockage and making progress.
Getting work done after a 40 hour week
Luckily this work doesn’t conflict with my day job, or else I probably would have burned out. By day I’m an engineering manager, thinking about how to help support folks, hire them, refine the organization and processes, and so on. This project needed time for writing software, doing market research, and other activities, so there was still a gear switch between them.
Make a schedule
Early on, I worked when I had time. When I was with family I would be working through ideas on the project, when I was working on the project I was worried about not spending time with the family, and I never had time for a book or game. In general it was ineffective all around.
So I made a schedule. I mapped out my week in 30 minute increments, creating a template for activities I would do each week. I included work (red), minimum family time (green), some time with friends on the weekends (blue), chores (orange), and some small and medium size blocks of project time (purple). Everything else I left blank.
Each Sunday, I would make a copy of the template and start logging my week. It never went perfect, but it helped. I had permission to focus on the project and could see I wasn’t ignoring it through the week. I could turn it off and spend time with the family. It felt a little weird that ?80% of my life was scheduled, but now things were getting my full focus.
Ship something (again)
Even with scheduled time, sometimes you sit down on a Tuesday night after a long day and just can’t get started. There’s still so much to do, I’m tired from the day, nothing seems interesting, … So I would pick one small ticket for the marketing site or the application and I would do it. Then I would pick up one more. And before I knew it it was 10PM and I had shipped 3.5 hours of features or website improvements.
But to feel a sense of accomplishment from shipping small work, I need small work to work on. Which brings me to…
Break the work down into bite-size pieces
Initially I knew what I was doing, so I broke work down functionally. First I would make some database tables, then some back end logic, later I would do the front-end.
Which ended up as a mess, with a lot of pieces that didn’t fit together.
So I stopped and closed out the functional task list and replaced it with bits of user interface and exposed features that I would build from the top all the way into the back-end database or distributed agents.
And because I needed small tasks to build momentum on tough days, I sliced these very thin so I could accomplish them and ship something small on rough days or on the two nights I only had 1.5 hours of coding time.
But keeping the tasks organized became overwhelming, so….
Use a ticket system
I started with a table of features in OneNote that was connected to a bunch of functional tasks.
This became overwhelming, so I moved them all to Trello and added even more functional tasks. When I ditched the functional tasks and started trying to identify small features, Trello became a mess. Then I found Clubhouse, which was perfect (seriously, go use this and give them money).
Clubhouse was a nice balance between the disconnected set of cards in Trello and something overboard like Jira. I used Epics to break huge features into much smaller, executable bites (still vertical slices). I used the story points for a general guesstimate of sizing, which helped break some of those down even further. I used a Milestone for the 3-4 epics I would need for an MVP and then as I finished things I got to see the charts reflect my progress, which gave me momentum for the next thing.
Seeing my progress on the larger scale was useful. This was a pretty big elephant of a project and I could see I was 1⁄4 done, 1⁄2 done, etc and descale things to hit my target dates. Besides having software tasks, it also captured things like setting up bank accounts, the legal steps for the company formation, etc. As I saw the charts march down towards an estimated completion date, I fed the data into the financial spreadsheet to help coordinate personal investments and so on.
TLDR: Create a pace of shipping small, working things
If I had to boil this all down, it is to build momentum by shipping small, working things. Most projects like this aren’t well enough defined to take a few weeks and go build just the database, etc. So start from the interface, ship small pieces, use a system to move all of those things you’re trying to remember (even the work) off your conscious brain, and be ok with the fact that sometimes it takes writing 5 things in a row in the wrong direction to figure out what the right direction should be.
I hope some of the content in this series has been helpful and good luck with your own endeavors!