Developing Product Management[0]: Starter to Finisher

Among the first things taught to students studying physics are Newton's three laws of motion, the first of which (paraphrased) is that an object in motion tends to stay in motion unless acted upon by an outside force.

Many people struggle with being a starter and not a finisher on any number of projects, and can't keep things in motion. Countless github profiles are just like mine on the public facing side - a few repositories created or forked with good intentions, but that don't end up amounting to very many finished products if any at all.

This of course is not specific to open source contributions. Inertia is something that has loomed large for me over the last couple of years, in trying to build a business, in doing my job as a developer, and especially the not insignificant amount of time I've spent trying my hand at product management.

Coming at product management with a developer's background and mindset has been one of the biggest challenges of my career, but it has also taught me quite a bit that I plan to write about as part of a series of posts.

First - how can I apply what I've learned doing product management to leverage inertia in my own personal projects, especially those that rely almost entirely on instrinsic motivation to stay in motion?

Personally, the biggest thing that tends to kill my projects is a perceived lack of progress early on, which leads to discouragement, which leads to an object at rest; a stone gathering moss.

I don't believe anyone starts any project without some sort of plan - but how much of that plan lives completely inside the person's head working on it?

As I've quoted before, writing is thinking. Getting the plan for what needs to be done into a tangible form has multiple benefits, not only leading to better definition, but also making it easier to gauge progress.

The suck threshold is a very important concept when producing any product, but it also applies to the process of producing something as well - the more quickly one feels like a badass, the more likely it is that momentum will be conserved.

The tools used to make a tangible plan don't really matter. I'm partial to using Trello thanks to its flexibility, but plain old paper, a whiteboard, a spreadsheet, or even Microsoft Project^[1]can be made to work. The key is to find the right balance between between getting enough of the plan in a tangible form to give yourself a road map without spending so much time planning and defining that the momentum of producing is lost.

Once the high level things are understood, more detailed definition is definitely helpful, but even if just one detailed task is broken out of the larger plan and completed, that can be enough to get the momentum going on to the next one.

Common pitfalls and bad habits I run into are screwing around trying to decide what set of tools or technologies to use to accomplish something, or spending so much time trying to learn the tool vs. accomplishing something. In the case of software, things like yeoman generators and the like can help get a project moving faster without fiddling with the setup. I also find it helpful to keep this thought in mind: "what is the primary goal?" Is it to learn how to use a tool^[2] or to produce a good product?

Even if the market for that product is only the person making it, staying reminded of what it means to finish something makes it way more likely that the endeavor will result in a finished product. The more of those you have, the easier it is to keep the stone rolling and being confident in being a finisher vs just a starter.

Postscript: Now, to practice what I preach. My overall plan for this particaular series of posts is to cover more abstract topics from this perspective, mixed in with specific examples from real personal projects which I will be posting as I go, some as open source software.

(This post includes an affiliate link.)