You’ve got a great idea for a new startup.  After doing some homework and getting customer validation you’ve decided it’s time to start building product.  You reach out to friends and development shops:

“Here’s my great idea and a list of features/specs. How much is this going to cost to build?”

You get some quotes and pick the option that’s within your budget.  Fast forward a few months later, your project still hasn’t launched, you’re significantly over budget and the product experience isn’t quite right.  What went wrong?

At StartupGiraffe we believe that timeboxing projects (a flat rate for a set period of time) is a better way to build software.  Here’s why:

You don’t really know what you need yet

Unless you have a ton of experience building software products, it’s unlikely that you’ve thought through the all the details related to the implementation of your product. Unfortunately it’s very difficult to do that up front (it takes time and exploration). As part of our process we usually give a few weeks up front for user interviews and product design. While the founder(s) we’re working with have a great high level understanding of the problem space and their solution, figuring out exactly how all users will use the system takes time. Defining a fixed scope engagement allows little room or incentive for for exploration during the process.

We can make it better

In a fixed scope model there is a fear of mid-project improvement. From the developers perspective new ideas are scary since it either creates more work or initiates the dreaded “out of scope” conversations (see below). In our projects there is typically a 30% variation in scope from where we start (what we think we will build) to where we end (what we actually build). This is a really good thing. In a fixed time project everyone can be strategic in coming up with high value changes based on iterative progress (wireframe, design, code) and feedback. Throw things away that are less important and instead improve the core of your experience. Everyone can be aligned to build the best product within the time period.

It forces you to prioritize

Some founders have a constant fear that they need “one more set of features” in order to start going out to customers. You can tweak details forever, but the best way to learn is by releasing a product to a small audience of real customers. Working backwards from a launch date forces you to focus on the most important / highest value things at all times. In the earliest stages your startup is still taking broad strokes. While the details are important, we often see folks spend way too much time on things which didn’t help them test assumptions or achieve their goals. You’ll learn more by launching quickly then continuing to develop low priority items.

“The biggest mistake I see is companies waiting too long to release the product. It’s easy to let the scope of what you’re building get out of hand. But equally importantly most startups build much more than they truly need to, but this is often only realized in hindsight. Whether your product is working or not, looking back it’s easy to see that you only really needed to build a small fraction of the stuff you built. Most features/options/buttons/settings/etc. simply aren’t crucial to success or failure, and for an early stage startup that means they were wastes of time — you could have done 10x more with that same amount of time and resources.” — Jonathan Wegener, Founder, Timehop and ExitStrategy

Everyone sucks at software estimates

Seriously. Until you get into the weeds it’s very difficult to know how long a particular development task will take. Not only is there undiscovered complexity and edge cases to deal with but no matter how well things are documented there is always room for misinterpretation. The only true way to ensure everyone is on the same page is by releasing code often and in thin slices. Only once you get your hand on something and play with it can you be sure it works the way you expect it to

In scope / out of scope conversations are the worst

Feature completion and what is classified as a “bug” is subjective. There is a lot of grey area. Trying to identify whether something is “complete” is not a perfect science. You don’t want to be having these conversations.

It’s cheaper

Yes it is. Someone on the agency side needs to calculate possible failures into a fixed price – in reality, you don’t get the lowest price, rather the safest for the company. The only person paying for this overhead is you. Dealing with a company that does not have those processes means that you are saving money and paying only for the actual work and experience. – Netguru

In the past we’ve also seen other teams “bid low” for a project, knowing they can make up the difference on their real cost with “out of scope” features.

You can plan better

Working backwards from a soft launch date allows for much better planning. From the startup’s perspective they can start planning everything that surrounds a launch (customer acquisition, support, fundraising, etc…). From our perspective we have much better resource planning and know when we’ll be available for new work.

While working on a timeboxed model requires there to be trust on both sides, we’ve found our projects are much more successful this way. Questions? Let us know.