I think there are some creative ways to break up seemingly monolithic features into bite-sized, achievable, and incremental steps. Here’s a few questions I often meditate upon when facing a largish feature request (pro-tip: they can usually be combined):
1 - Can we hardcode it?
Take a page from the Test-Driven Development playbook. If your feature is big because of complex computations that need to take place, see if there’s a way to hard-code the behavior for the most popular flavors. Ignore the other ones for now.
An Example: For a route-planning application, instead of writing logic to calculate a nice bike route between 2 arbitrary locations, show a map that lets the user pick the routes from the center of town to the ten most-popular bike destinations.
2 - Can we just do one?
Similar to hard-coding, doing one is nice when you have a feature that needs to work for a large and diverse set of items. In these cases, you might get a lot of bang for the buck by picking the simplest item or class of items from the catalog, and do your feature just for that one.
This lets you side-step some of the complexity of crafting a solution that works for the entire population. You can learn what a really good implementation takes in the simplest case. You can also hedge risk by getting the feature in front of customers early, so you can decide if it’s even *WORTH *all the extra effort to expand to the rest of the catalog. On top of that, you can get some good numbers around how long things will take: “It took us fifteen days to build it for that one product, and there was a lot of hard-coding, so let’s say it will be double that to make it work for EVERYTHING”.
If you need to show a 3D HTML5 rendering of purses on the site with zoom, mouse-over highlights, and hotspots, do it first for a single purse in the catalog. Hardcode it to be really amazing for just that bag, and don’t even bother showing the 3D option for the other 2,000 bags on the site.
3 - Can we skip part(s) of it?
This one is kind of obvious, but it’s surprisingly easy to forget about. It can be helpful to focus on a single aspect of a feature, knowing the plan is to roll out the rest of it later. It’s always handy to think about this before spending a whole lot of time designing and building. If you can strip out the non-essential parts, you can deliver something, then enhance it. Also be sure to put in an on/off switch, so it can be deployed, but disabled if necessary.