I've been getting a lot of positive responses to this framework that I've posted on Twitter and in my Developer Microskills newsletter, so I thought I'd share it here with you all in case it's helpful!
Tell me you've done this before:
Why do we do this!?
The simple answer is of course that having ideas is way more fun than seeing them through. That would be adequate if it wasn't so discouraging to repeat this cycle all the time. It starts to creep from "I have a bunch of unfinished projects" to "I'm just not the kind of person who finishes things" and that can be really disheartening.
In this article, we're going to talk about finishing what you start. We'll talk about:
Let's dig in!
Like most behaviors, un-finishing (a word I just made up) stems from our beliefs about ourselves. Here are three that I've wrestled with over time:
Any of those resonate with you? These three have definitely kept me from hitting the publish button or starting to build out an idea I had.
What do we do about this? I could sit here and give you logical arguments as to why each of these mindsets is wrong. The problem is that we're not logical with ourselves when we feel these things. I'm never able to out-argue my emotions. My brain can rationalize any left-field self-loathing that comes my way if I'm in the wrong headspace.
What helps overcome all of these mindsets is action, which translates into experience.
We believe a lot of stories about ourselves that we've told and re-told a million times. Some of them are accurate, but most of them aren't. Arguing with the story doesn't work very well, but living out a different one will change the way you see yourself.
To that end, let's dig into the practical and help you rack up some wins.
The first step to finishing more of what you start is reducing your idea backlog. Repeat after me:
Not every idea you have needs to be executed.
Put another way: Not every idea needs to become a project.
Some ideas are good, some...aren't. What you need is a good way to capture these ideas and decide which ones are worth working on and which aren't.
You can get really sophisticated with this and build a system around it, but for now, why don't you just open a text editor and write out a list of every unfinished idea or project you have? (Or just set a timer for 15 minutes if you're a modern DaVinci.)
Do you have your list of ideas and projects? Great. Now you need to process them. For each project, you're going to give it one of three outcomes:
Try to narrow that big initial list down to just a handful of viable ideas. You're looking for the ones that you have the time and resources to work on right now. Not all at once, just at all; if you were to pick one, it might feel a little overwhelming but not impossible.
(Okay, in truth I actually kind of liked the Virtual Boy, but I think it was because as a 10-year-old kid it seemed futuristic and cool. How was I supposed to know it was a flop?)
Okay, so let's say you've got a clean list of 3-5 solid ideas. They seem equally valuable with regard to profit, career growth, fun, or impact. How do you pick?
The best thing to do here is the JPS strategy: Just Pick Something. Throw a dart at the list, randomly generate a number, or play pin-the-tail-on-the-idea. Just pick something. Why? A few different things might happen when you pick something and start working on it:
You may be thinking, "But Sam, if I pick something that I end up disliking or fails, didn't I just waste a bunch of time?" That depends on how you big you make the project.
Now that you've picked something, it's time to reduce its scope so you can actually ship something into the world. Take the dream and scale it way down to a Minimum Viable Product. This works equally well for content and dev projects, by the way. A few examples:
Dream: A global AirBnB for dogs
MVP: Basic website, forum (Discourse), and payment system (Stripe)
Dream: Ultimate guide to full stack TypeScript apps
MVP: A single article on setting up Express with TypeScript
Dream: Learn Golang
MVP: Build and deploy first tiny app
So there you have it: the secret to getting more done is lowering your standards. 😅 No, no, there's a reason for this. Scoping down projects is all about validation. Remember when I mentioned risk? Let's talk about that.
Your goal with a new project isn't to get 100k users, make a million dollars, or change the planet. Your goal is to validate your idea with a few people. This might mean comments on some content, a kind message from someone, or a few people (who aren't related to you) buying a product or service you put out.
You're looking for quality over quantity here, because if something resonates with or helps a few people, it will likely scale to bigger numbers as you put more effort into creating and promoting the project.
Validating an idea saves you a lot of time in the long run. Imagine secretly building a massive project or piece of content only to have it flop. This happens a lot and it's very hard to learn from these. Was it the topic? The format? The way you marketed it? The platform you used?
Validating tiny experiments lets you get feedback and improve. If your tiny experiment gets zero traction, you could tweak a few things and try again or you could drop or defer it.
Once the idea is validated, you can take the next steps: build the next feature, write the next article, or update and improve to release the next version. As you continue to build a body of work in an area, the results will compound. You'll be able to cross-reference material you've created, build a network of people who are interested in the same topic, and establish yourself as a credible source and helpful community member.
I used this same "validate and iterate" process to write Getting Started in Developer Relations. I had a hunch that a book like that would get a good response. Rather than agonize over every decision to create a perfect book, I time-boxed the initial production to 2 weeks. Granted, I have a lot of writing and product experience at this point, so I wasn't totally starting from scratch, but I was able to get something I was proud of out into the world and see what kind of response it would get. To my delight, it's been a great response!
Now that I know the idea is valid, I am working on a revised and expanded version that incorporates feedback I've gotten from readers.
You could also choose to abandon a successful experiment. Maybe you got what you wanted out of it or it wasn't as fulfilling as you thought it would be. Either way, you gave it a shot, created something, and grew.
This "tiny experiment" framework is helpful everywhere, not just with dev or content. I've used it for everything from nutrition to home improvement projects.
If you're curious where this kind of thing comes from, there are a few answers, but one I'll leave you with is called construal level theory in social psychology. This is basically saying (as I understand it) that the farther away something is (whether physically, psychologically, chronologically, or otherwise), the more abstract it appears. This is why we don't plan for retirement soon enough. It's also why "start a 1 million user SaaS" isn't a great project; if you've never done that before, you have no idea what the steps are to get there. It feels abstract and complex so you'll likely abandon it. Here's a great article on that subject by a research scientist named Jude King.
Try this framework out and see if it works for you. I've used it in all kinds of areas of my life, not just developer or dev rel projects. As always, I'd love to hear if it's helpful for you and how you've added your own spin to it!