Typically at Faceyspacey we keep the scope of a brand new startup small, but quite a bit larger than what you’d get with one iteration. One typical iteration wouldn’t be what you feel is suitable to launch to the public. So we’d spec the startup down to what a multi-million dollar startup might accomplish in about 10 small iterations/sprints as they figure out their product. In short, we determine the concise set of features that capture the essence of how you want to present to the public, and make sure not to waste any energy and resources going farther than absolutely necessary.

So what that means you need to imagine a complete product from the beginning, but as small as absolutely possible. In the last phase of the Speccing process--the Sprint Planning phase--we’ll break up the plan into 5-10 sprints.

Ok so how do you optimize scope realistically? First you pinpoint your single value proposition you must get right. Without this working perfectly with a great user experience, you know you have nothing. So for one of our past startups, SnackSquare, that value proposition was the delivery of SMS text messages to people nearby your local store front. For this startup, I won’t lie, we actually didn’t do what I’m about to say here, which is how we’ve come to learn how important this technique of scope optimization is. So I’m going to work my way backward pinpointing our mistakes, and then summarize what we would have done differently.

First off, we imagined absolutely everything possible the startup would need. This included a way for merchants to add multiple stores, ways to add multiple coupons that could each exist at multiple stores (i.e. a many-to-many relationship), tools to track customers across multiple stores they may visit (or be near) and the different coupons they may use at different stores, and ways (i.e. entities) to represent the proximity-based connections between customers and a store when they are near it, entities to represent campaigns across all the previous entities and ultimately a lot more.

So hopefully you get the idea that we had to model a lot of real-world entities and the connections between them. We would have been a lot better off if we dropped the concept of coupons all together and even campaigns, as that was what everyone else was doing, and not central to our core value proposition of SMS delivery.

Instead, we would have simply allowed you to add stores. You wouldn’t create campaigns because it would be a given that a single global campaign was operating against all your stores. In terms of metrics, instead of tracking the performance of coupons, campaigns, stores and customers, we’d track just the aggregate performance of all your stores. We wouldn’t even let you drill down to the metrics on a store by store basis or the metrics for each customer (i.e. how many times they frequent your stores). We’d focus on aggregate system-wide stats, and make sure those text messages go out immediately when a potential customer is near your store. And we’d even let you only set one message at a time that would go out, i.e. a global campaign. We wouldn’t have done that whole thing where you can set the timeing and dates of multiple simultaneously-running campaigns. Maybe we’d let you set the dates and times, but that’s where it would end, and it would be one message that goes out.

The reason reducing the scope so much was so important was because the technology to track customers was so damn complicated that we needed to put all our attention on that. We were completely at the mercy of changing/evolving APIs that were at the cutting edge of “geo” and just experimenting themselves with what data they provided. We had to track checkins on Foursquare, Facebook, and Twitter, all with various techniques tailored to each social network and how it produces geo-tagged checkins/tweets/updates with lat/lng coordinates, and as we went the APIs changed--usually for the better.

So anyway, that’s an example that should highlight how to reduce the scope for your startup. To put it in more abstract terms that summarizes what we did, I’ll explain it like this:

1) FEW CODE ENTITIES -  keep the real life entities you have to model in code down to a bare minimum

2) PINPOINT SINGLE VALUE PROPOSITION - find your core value proposition and understand technically all that’s required to execute it at a very deep level before you start. It’s really hard to go that deep into the tech specs of a project at the beginning, but if you can narrow it down to that one thing, it makes it a lot easier to go the mile in breaking down the technical ramifications.

3) ONE MAJOR INTERFACE - imagine only one key interface where all the magic happens. Don’t have 2+ sick interfaces that do lots of cool stuff. So that means you can have a bunch of standard web pages for your account info, and even a graph/analytics page. But only have one page where your end user gets his value from the application. Everything else could basically not exist.

This sort of thinking is completely in vogue right now in the “Techcrunch scene” as I like to call it, i.e. KISS (“keep it simple stupid”). And for very good reasons: it’s really hard to imagine everything you need to do to get your application to launch. You’ll save yourself a lot of heart-ache by putting your mind to doing just the minimum you need, i.e. get out that MVP (“minimal viable product”). Ingrain these acronyms in your head. It’s the only way you’ll succeed.