This is part four of a series. You can read the previous installment here or start at the beginning.

Is the scope feasible or possible?

Once you’ve determined that your idea passes all these preliminary tests — is it valuable? marketable? potentially successful? — you need to work out the necessities for a minimum viable product, also known as an MVP.

When you’re creating something new, it’s very easy to get so excited that your once-feasible app snowballs into an avalanche and you get buried in features. To avoid this, make a list of the features without which your app cannot succeed; we’re talking bare minimum essentials here! If your product is a new way for users to keep track of their book collection, you’ll need to have some way to create users, to add books, to display books, maybe even sort them… but you will not need an algorithm to find recommended reading based on recently added items and you will not need a utility that pulls reviews from amazon’s website.

At least not yet. It’s good to have an idea of how you want to expand your product if and when it becomes successful. But for now, you have to focus on this MVP, because the sooner you have a product that can be released for beta-testing, the faster you can start iterating on it.

The iron triangle of software development

The so-called Iron Triangle illustrates the fundamental trade-offs that must be made in any project. Any one of the three constraints – scope, schedule, and resources – can’t be altered without affecting the others. Having unrealistic expectations in any of these areas will ultimately be to the detriment of the product quality.

We say ‘start iterating on it’ because iteration truly is key. Novelists say that 90% of writing is actually rewriting, going back through their first drafts to make them better; developers could say the same thing. The MVP of your product that you release to beta-testers will be far from perfect. There will be bugs. There will be usability problems. There will be disconnects between how you envisioned the product and how the product is. Finding these problems — and fixing them! — takes time.

It takes hundreds of people years to make a new version of Windows and it’s still buggy, crashes, and needs to be patched constantly. As somebody endeavoring to create a piece of software, this is one of the most important pieces of knowledge you can leverage, and something we remind every single client of. Your first try is never perfect, but that’s okay as long as you plan for that.

Consequently, as you think about your MVP, consider scheduling. If your product is a gift registry, you probably want to release before the holiday season. If that’s the case, you’ll want to make sure to finish initial development much sooner, possibly as early as late summer, so there’s time to fix any issues that beta-testers report. This early deadline, in turn, may affect what you deem as MVP — if it’s already March, you may have to jettison a few of the less essential features to hit the late summer deadline. This is going to be very, very hard to do, but the ability to triage features is paramount to the success of a time-sensitive project. Again, this is a hard truth that clients often struggle with. If you try to do everything at once, it’s going to take longer. If you can strip the product down to MVP then you have a much better chance of releasing on-time. You can always add more features later.

MVP and scoping are important because scoping impacts budget, and budget is king. The last consideration as you scope out your MVP is budget. It is better to overestimate costs than underestimate them. If you have a 600-hour budget, and you’ve already allotted 450 of those hours to absolutely mandatory features and tasks, you may want to hold off on that luxury feature that’s estimated at 20-30 hours — you don’t want to end up with an incomplete feature when your budget runs out and it’s time to hand the product off to beta-testers. Chefs who serve half-baked brownies don’t get good reviews!

MVP and scoping are important because scoping impacts budget, and budget is (usually) king. A good idea that you do not have the budget to build properly is not a good idea. If you can strip it down to something simpler that you do have the budget for, then it may still be a good idea, but the greatest idea in the world won’t be successful if you don’t have the resources to pull it off.

Scope creep is inherent in software development, and it’s the biggest threat to the success of a good idea after marketability. Here at Chromaplex, we always build a “padding” budget into our estimates of 25-35%. If you cannot reduce the scope of your MVP below 75% of your development budget, your good idea faces a very real chance of failing.

Next: Part – On Venture Capitalists
Previous: Part 3 – Know Your Market

Share this post: