Ship It
Here we have yet another blog article espousing all the ways to break through roadblocks to getting your project over the line and into your customer’s hands. I don’t know how much of this will be new. Probably less than 1%. That doesn’t mean it is irrelevant. Time and time again, I run across teams who have trouble covering the last 10% of the ground necessary to release their project.
The first step to finding a solution is to identify your roadblocks. What are you getting hung up on? Perfectionism is a common one. Lack of understanding of the final mission is another one. Fear of your customers is a surprising one. Analysis Paralysis certainly has killed its fair share of projects. Budget and/or resources are a big one. Let’s explore some of these in more detail.
Perfectionism. We want to do a good job. We take pride in a well-crafted piece of code that elegantly expresses some necessary functionality in a clear, concise way. It makes life easier in six months when you inevitably revisit the code to extend or adjust something. Unfortunately, sometimes the quest to do a good job ends up spiraling out of control. You write the necessary function, but then throw it away because it isn’t quite as awesome as you intended. On the second write, you get closer, but then you realize that there are several edge cases that might come up. You build out logic to handle those edge cases, and then end up with a disorganized mess, so you throw it away and start over a third time. By this point, your timeline is either in jeopardy, or completely blown. Sometimes good enough needs to be good enough. Add a comment on what your vision is, then move on. Call out some of the edge cases as possible problems, but then wait for the field to confirm whether they are actually problems or not. Remember, good and shipped is better than perfect and unreleased.
Lack of understanding of the final mission. This one is a bit more abstract. If you don’t clearly understand the mission or purpose of what you’re building, it is very easy to build something that misses the target, and then gets kicked back, potentially causing a missed deadline. There is usually a little misinterpretation, but if you understand the purpose of what you’re building, it will help you get closer to the mark. The appropriate cliché here is “measure twice, cut once.”
Fear of your customers rears its head in funny ways. If you have yet to launch, then all your assumptions and projections are hypothetical. As such, they are neither too rosy nor too bleak. This provides a warped security blanket that allows you to avoid actual market forces for a time. It can also manifest as a sense that you only get one chance to impress your customers, so it better be perfect. See the perfectionism paragraph above. Do right by your customers, be responsive, and listen to them, and most will give you more than one attempt to impress. In fact, they will help you find your actual target by uncovering all of the flaws in your plan. Get to market and start learning from your customers. If you demonstrate that you value them, you run the risk of turning them in to your biggest fans and evangelists.
Analysis paralysis is a phrase describing an inability to make progress because you have too many options in front of you without enough information to determine which option is the right one. If you find yourself suffering from this malady, then go back to the mission. Pick the option that either gets you to market quicker, or best fits the mission. If you still have too many viable options, then treat them as equivalent. It doesn’t matter which one you pick as long as you get your solution out there. If you were wrong, you may find that your choice was good enough. If not, you can adapt and adjust. You won’t get every single decision correct. It can’t happen. If you’re given two options that are equal, all things considered, flip a coin and move on.
Budget and time are finite resources. When building a solution, you have to be economical with both. That isn’t a justification for making bad decisions, but it is a reminder to be pragmatic. Sometimes the correct way isn’t the best way. Sometimes you need to take into account the bigger picture, and do something in a minimal, or non-ideal way in order to get your solution into the hands of customers so you can gather data or test a hypothesis. Be pessimistic with your estimates, and then work to stay ahead of them. If your pessimistic estimate indicates a project is too expensive to explore, then congratulations, you just dodged a bullet. Perhaps there is another option that can achieve the same goal. If your pessimistic goal wasn’t pessimistic enough, address it as early as possible, don’t just continue on and hope you’ll catch up. If you find you got done way early, then you can add some of those deferred “nice to have” requests. Keep an eye on your time and budget constraints, and don’t let them become a reason you failed.
Ultimately, if you can determine what encumbrances you have to shipping your particular project, you can then formulate a plan to deal with them, then execute. Shipping software is gratifying. It is necessary to your progress. Learning from real world data is an order of magnitude more valuable than hypothesizing. There are many factors that build a culture of completing and shipping projects. An upcoming article will explore some of the factors around team dynamics and the mindset necessary to consistently ship software. In the meantime, take a hard look at what is hanging your team up. Even though it doesn’t ever feel ready, just ship it.
-Joe