Think building everything on your app wish list for initial launch is a good idea? You may want to think again.
All of the heavy hitters – AirBnB, Uber, Spotify, etc. – didn’t do this, and for good reason. More often than not, it is a massive waste of time and money.
Project scope isn’t talked about enough, yet it’s extremely important. Scope affects timeline, development costs, even the ability for you to meet your business objectives. The majority of people we speak to have a laundry list of features that must be included in version one of their app, and the desire to have your entire app as you envisioned it built in one go is understandable. But this mindset often does more harm than good, and can actually hurt the chances of your app being successful in the market.
So far, what we’ve said may seem counterintuitive. But there are huge risks with the “build everything at once” method:
In every project, there will be a number of assumptions you are making. In agile methodology, where iterative development and continuous delivery is practiced, you are able to test and validate your assumptions by monitoring performance and collecting real user feedback. These learnings are then used to improve your product. When you build everything out at once, you are making more assumptions than if you were to approach development iteratively, which means more time and money invested in validating or invalidating these assumptions.
Going hand-in-hand with making assumptions, your app is being developed to add value to your business and users – what is the problem you are trying to solve? Believe it or not, many businesses miss the mark on this completely. The importance of particular business problems or features can be high from your team’s perception, yet insignificant to your customers. If you build everything at once, you risk losing focus on your real business objective and will spend more time and money testing assumptions and collecting user feedback to build what your users really want.
One of the most common issues with trying to build everything at once is that it can affect both your time-to-market and your budget. We’ve already discussed the way this approach can result in wasted time and money, particularly if you fail to focus on key business objectives or find that many of your assumptions are disproven – it means you need to put even more time and money into development in order to get to a point you could have reached with smaller, iterative product releases.
In mobile app development, it’s rare that timelines are completely inflexible. However, sometimes a product needs to be launched by a certain date, for a variety of reasons. For example, we worked with a client that needed an Apple TV app ready for the Rio Olympics. In this case, the timeline was not flexible. The majority of cases where time-to-market is set in stone are when products need to be ready for major events, though it can also be business and stakeholder needs or coincide with things like ad sales, the launch of hardware that works with the app, or other stakeholder or business deadlines.
In most cases, initial ask isn’t feasible due to budget. When the initial ask is very large, there is a risk to the budget given the number of assumptions and uncertainties, which can result in unforeseen costs. You also are trying to stretch your budget over many different features and priorities – again, perhaps not even solving the most salient problem or addressing your primary business objective. Taking an iterative approach helps to avoid this so you can reduce the risk of going over budget.
Nobody wants to hear it, but in many cases, it is much better to scale down the original scope of your mobile app. This doesn’t mean building an inferior product: quite the opposite. It’s agile development 101, and it comes with a myriad of benefits.
Smart scoping allows you to focus on what the highest priority is, either to meet your business objective or to address user pain points (ideally both). Focusing on a central feature or problem for version one of your app allows you to build something that will have the most impact in the fastest time.
Focusing your mobile app scope allows you to get your product to market more quickly so you can validate or invalidate assumptions and gather feedback to improve future versions. This includes benefits such as tracking analytics, tracking usage behavior, and gathering real user feedback from actual app users. These learnings can tell you more about what your users want and need than any user research you do prior to launch, and this intelligence can be used to improve future releases of your app.
Since you are able to test assumptions with real users and information, yet with smaller project scope, you are effectively able to lower your overall costs. Releasing a larger product at an initial launch carries greater risk and costs more to develop. Reducing your initial scope for the first version, therefore, can help you create a better product, for less money and reduced risk, in the long-term.
Reducing the scope of your mobile app doesn’t necessarily mean a smaller, less feature-rich product over the long-term. It simply means that the product will have better direction and benefit from the learnings we’ve discussed above. Even still, reducing scope is often seen in a negative light. However, there are a number of scenarios in which you should consider de-scoping:
What it comes down to is the ability to deliver a high-quality product that meets business objectives, adds value to users, and aligns with your budget and timeline. Determining a suitable project scope will help to ensure these things, especially for the initial launch of your product. The thought process behind the “build everything at once” approach is understandable, but it increases risk and can actually harm your chances of launching a successful product. By scoping intelligently, you are able to keep the budget and timeline in check, test assumptions for less money, and collect real user feedback in order to improve your product with every subsequent release.