Part 3: Planning A Mobile App Release
(This is the 3rd part in an ongoing series on the Mobile App Development Process)
Ok, your mockups are finalized, your designers have finalized your colour schemes, and your engineers have been lined up: you are ready to start building your mobile app. If only it were that easy my friends. If only.
The one part that most software projects get wrong is the very first one: Design & Planning. In most projects, and especially with startups, there is a huge rush to jump into development at the expense of clearly articulating the goals of the release. Don’t do this.
Just because you have screenshots, or maybe even a mockup at your fingertips doesn’t mean you are ready to build. The goal of the Design & Planning phase is to bring a measure of reality to your release plans. Developing software boils down to a zero-sum equation of time, resources and functionality. With startups, the imperative is to have your app hit the market quickly, but you don’t want to release something that is half-baked, or missing key functionality. Likewise, you can’t invest in building out functionality without drawing down your supply of engineering resources and pushing out your schedule. Your job in the Design & Planning phase is to find an acceptable compromise between these 3 constraints for your next release.
Software projects are notorious for never being finished on time, and you’ll be truly blessed to be on a project where the engineering estimates end up matching with reality. It’s not that software engineers are a lazy bunch, or are lacking the ability to estimate time, it’s the nature of software development. Bugs come up, unexpected behaviors and situations will arise, your schedule will slip. In general, if you get an estimate of ‘6 months’ to release the first version of your app, that’s your engineers telling you that your plans might be too ambitious. The longer the estimate given to your, the greater the likelihood you will slip.
The goal of the Design & Planning phase is to set a pragmatic roadmap for the current release, not pontificate shoot-for-the-moon ambitions. One possible output of this planning work is a prioritized set of customer scenarios you want to enable in the release. Your engineering team should commit to those scenarios, and give you not only estimates, but rough date ranges when they’ll think scenarios will come online. Now you’ll need to take these with a heavy grain of salt, but just going through the exercise will give you a good pulse check on how confident your engineers are in the plan.
Even a token amount of planning effort at the start of your release cycle will help you avoid serious issues coming up later on during development, when it’s much more costly to fix and more likely to derail your schedule. Like your mother always said, an ounce of prevention is worth a pound of cure.
Next in the series, PART 4: THE DEVELOPMENT MILESTONE