One of the big challenges that we deal while developing apps is knowing when to ship them to the app marketplaces for consumers. When we’re working on a project for a client, we have a definition of how the app must function and how it must look, so we know pretty well what success is. This makes it simple for us to know when app is ready.
When working on our own products, though, there is much less definition for when the app is ready to ship. Software these days is continuously developed through updates, essentially preventing any app from ever being “finished.” Parkinson’s Law – the idea that any task will expand or contract to fill the time you allow it, also plays a big part in all of this.
When we start brainstorming for an app, anything is possible. It’s easy to get lost in a long list of ideas for the greatest app in the world that sorts your email and runs your dishwasher while also letting you catch up with that TV show you missed last night. Very big ideas here – disruptive stuff. There is a point at which that app could be “ready,” but have no real focus, making it a difficult to know when to stop adding new features and release it.
It’s important that we drill down to the core of the product early in the development cycle. If a feature can be cut from the app without greatly affecting the overarching goals of it, that feature should be left behind. The result of this process is a focused idea often referred to as the Minimum Viable Product, or MVP. This is the simplest working version of the app that gives users the function and usefulness that we’re aiming for.
If we’re working toward an update for an app, we start with any bugs that might exist and then build a list of features we’re planning to add into the app to improve it. Whether version 1.0 or update version 15, we work to establish a solid set of goals for each version before development for that version even begins. This way, we know what success looks and functions like.
Even with this, it’s still a challenge to know when to stop. “It’s done when it’s ready” is a convenient response, and one that I’ve heard elsewhere, but it ignores the realities of development. Code can always be cleaner or better optimized, and art can always be polished. There’s always a bit more that can be done.
While developing an app, there are often ideas that come up in the middle of the process. Implementing a new feature or tweaking the UI just a bit more feels good, but can be a problem as more ideas are added in the name of making the app better. Features can continue to creep in and it can quickly spin out of control. That “when it’s ready” point moves out further with every feature that gets added. If we’re not careful to consider these ideas before pursuing them, the app may lose focus as features are piled onto the core idea.
If a user has no idea what to do with an app because it does too many things, valuable time has been wasted on unnecessary features that could have been put on the list for future updates and assessed later. The user is likely gone, and unlikely to return to the app.
Much like spending too much time on an app can lead to a product that does a lot without doing anything well, an app that we don’t spend enough time on will have problems all its own. It may be filled with bugs, each of which diminishes the experience for users. In addition, underdeveloped features may be included, and users might have a hard time finding the value in the app. Bugs and unrealized potential will push users away as badly, if not worse, as having an app without focus.
The idea in all of this is to ship at the point between spending too little time and too much time.
If we’ve hit the goals for this version of the app, have tested it and it’s working as originally expected, then we should ship it. In addition, we can put Parkinson’s Law to use by setting a deadline to limit to the amount of time we spend on something.
If there’s any question about our timing, it’s often better to release a working app a bit too early than to wait on it longer. After all, bugs can be fixed, existing features polished and new functionality added in updates. Eventually, as we continue to iterate, what started as the MVP can become something much more sophisticated, reaching a point where it will be as finished as we can make it. All the while, we’ll keep getting better at planning and working to find the perfect time to ship that next update.