1 min read

The most important part of any project or idea is getting started. There is simply no way of getting around the fact that you can’t accomplish anything without first starting it.

What is less talked about is the finish line. Of course, many things are never truly finished – products continue to evolve, you continue to improve your skills, time marches and you must continue to adapt.

However, if you do not continually set deliberate finish lines, whether its to your team, to yourself, or to your client, it’s difficult to make progress.

In a software organization, we measure progress in releases. That is, a set of changes/improvements batched together and then put out into the world at the same time.

The classic framework is “Build, Measure, Learn.” In this method, you Build something and put it out into the world. Then you Measure the outcome of what you put into the world, and based upon the results, you Learn what to Build next. It’s a cycle.

It’s easy to get caught up in the Build step.

I know people will like this more if I add this feature.

I know that if I add more explanation here, people will better understand.

I’m not sure this is good enough to show people.

For software companies, most strive for frequent, small releases. This allows the company to make an assumption about a feature, Build that feature, and then quickly release it to the users. At that point, we can Measure the results and Learn about them.

Setting clear finish lines of each “Build” phase may be difficult, but the counterintuitive reality is it helps to iterate and move faster.