Patience and Execution

A New Side Project for 2021

Corey Garvey
4 min readJan 3, 2021

Two days into 2021 and my push to build a software side project, writing down my thoughts feels like the right move. I’ve quickly been reminded that the hardest part is managing my own head, particularly having the patience to set clear milestones and only change course after hitting a milestone and reevaluating. No better way to manage my crazy head than by writing.

Right now, I’m starting with very little conviction in any specific product. It’s a good sign I think, maybe it means I’ve been totally focused on other things for the last few months. Even so, it doesn’t make it any easier to get moving on a new side project with confidence. Rather than jump on a project that I’d briefly thought about before, I’m reevaluating the market and my own feelings toward different spaces and solutions.

Two things are pushing me to start fresh (rather than working on a project I’ve somewhat vetted already)

  1. It’s a new world
  2. I have new goals

It’s a New World

I’ve heard a lot of smart people mention that COVID has accelerated progress, perhaps not altering the trajectory but leaving us in a fast forwarded world. I agree and a lot of the change I’ve seen has been present in my life for a few years already. Working partially or fully remote from an office, constant video conferencing, freedom to move and live almost anywhere. I’ve been lucky to live and work like this for several years and I know how many difficulties it presents. Tools are needed to make many aspects of life easier.

I Have New Goals

I’ve worked on a lot of side projects over the last seven years. Software applications have mostly been fodder for interviews at established companies. Thankfully, they’ve been quality fodder. Four different software projects never saw a true external user but helped me land a job that I was very happy to have. I’m actually quite content with this. I never pushed into the product enough for it to gain traction, never really searched for product market fit, and that held them back. But, I’ve been able to learn a ton, line by line, bug after bug, by working on these projects.

I’ve also been fairly successful with two content projects, a weekly newsletter and a podcast. Neither brought in any money (other than a couple bucks on Patreon), but that was on purpose. I always felt that charging for these would jeopardize the quality of the content, which was my real goal. Life has put these both on hold, but they shall return eventually, when I can no longer stay quiet.

Now, my goals are a mix of what I’ve done in these previous projects. I’m going to build software — tight, well defined, purposeful software — that is absolutely valuable, monetarily, for a set of users. I mention the monetary point because it’s the best way I know to measure value. If they’ll pay, it must be worth something.

Determining what to work on will focus on these two points, a new world and new goals. My path starts at the beginning, brainstorming on potential markets and ideas, researching potential value, scoping out the work needed, defining the MVP, and how to measure success.

I’m building on a process used in a mechanical engineering product design class my senior year of college. We broke up into teams of 16, and for a few weeks broke that team down into two teams of eight. Our group of eight individually went home and brainstormed ideas for the theme that year: “Emergency”. Everyone returned with some simple sketches of a few potential products. The eight of us discussed and narrowed all the ideas down to (I believe) eight. The other half of the group did the same. With these eight, we each went off and poked at the ideas. Was this solving for a real emergency? Was there a large market? Could we build the solution? We returned and whittled the list down to four. Here we started to get into the designs and how the products would operate. What materials would we need, would it scale, would it operate consistently? After narrowing to two products, we started working on very rough proofs of concept with foam, cardboard, and other cheap materials. Each team of eight then chose their top product idea. We joined back together and worked on two products. We created MVPs that could actually work. Unrefined and simple as they were, we now had real products to compare. From here we selected one and built out the true, refined prototype.

This process had a lot of advantages compared to brainstorming and jumping right in, two which stick out to me now. First, we vetted our ideas thoroughly. It takes time to understand the challenges that creating a product will bring, from a lack of market to the practicalities of building. We worked through more of these questions on the products we liked most. The final choice had basically “survived” the process. It was the strongest based on a true test of different aspects. Second, for the product chosen, we worked through many of the kinks before jumping into building the prototype. We new where possible issues existed and how to manage them. The product was on its fourth iteration by that point and each iteration was time boxed so the process moved along at a nice pace.

I have no plans to build out eight software products, but starting from square one I’ll be working in this tournament style, multiple iteration process until I’m confident with the product I’m working on. There’s a far bigger risk for me jumping into the wrong idea than determining the right idea a couple weeks later.

Slow is smooth, smooth is fast.

--

--

No responses yet