Today, I chatted with a friend who’s building a new software company. He shared his milestones with me, and I asked how he came up with them. His answer was simple. There’s a major industry conference in March. He wants to do a big launch at that conference, so that’s the date of his public launch. He needs to test it beforehand, so he’s doing a beta launch in the first week of February to select users. He shipped an early version of the product last week to get something out the door so he can iterate before the beta launch.

His approach makes a lot of sense. Pick an event where you want to make the product available to everyone, and then work backward. Create milestones so you can take advantage of feedback cycles and improve the product.

I like his strategy because choosing a public launch day that’s aligned with an event means the launch date can’t change. There’s no pushing it back. You either hit the date or you miss a big opportunity. This adds urgency, and setting mini milestones a few months ahead creates accountability. You can’t wait until the last minute to prepare for the public launch. It also allows you to get and incorporate feedback from early users and adjust the product before the general public sees it.