To turn an app around in 7 days, we work within a fairly tight set of guidelines to ensure everything is working smoothly. Given the number of moving parts (client vision, our own, feedback rounds, iteration, etc), we have to in order to keep things on track.
The process starts after determining the general direction for the app, where we start to decide what we’re actually going to build. Here, we compile all of the wild ideas from the previous steps and contract – as there are always way too many ideas thrown around to ever fit into one app/product/project. Contracting a set of ideas involves cutting, and even though cutting hurts, it’s critical to do so quickly and efficiently to get the wheels moving on in your project.
But contracting is easier said than done. In this post, we’ll walk you through the “Do’s” and “Don’ts” we live by to help you get through this process with as little blood, sweat, and/or tears as possible.
Don’t: Cut Overtly
Scenario A: Give a monkey 2 bananas and he’ll be thrilled. Take 1 away and he’ll throw shit at you.
Scenario B: Give a monkey 1 banana and he’ll be thrilled. Take none away and he’ll still be thrilled.
Am I calling our clients monkeys? — Yeah, pretty much. We’re all monkeys. It’s not an insult, just the reality of being human.
At the end of a brainstorm, there are 1,000 small but tasty bananas on the table that everyone wants to hoard. If someone starts taking them away right in front of us, shit will fly. I’ve seen it happen. But if we all take a break from the banana table, go munch on something else for a bit, and come back to fewer bananas, no one freaks out.
Enough about monkeys (see our post Cut by Omission next week for more monkey business) – here’s how we handle this in the real world. We take our feature brainstorm and physically remove it from everyone’s sight. Everyone knows where it is. It’s not gone forever; it’s just not in front of us right that second. Then we usually talk about how the app should look and feel – a totally different topic than the feature brainstorm that we just completed. Sometimes we’ll go grab lunch or coffee and change up our environment. Then when we come back and start talking about features again, it’s like we start with a blank piece of paper. Our facilitator will pose a question like “What are our top 3 user-priorities?” She won’t write down everything everyone says. She’ll condense and summarize things into high-level feature sets.
The ideas that most closely align with these high-level goals will naturally bubble up to the surface, while those that don’t will go away. But, now that we’ve gotten everyone thinking about the big picture rather than their specific contributions, we’ve managed to cut them, shit-free. And that’s how we turn 1,000 small but tasty bananas into just a few big and really savory ones. It’s such a simple concept, but so infrequently done.
Do: Chop & Trim
There are two ends on the spectrum of decision (to cut off). You can trim away ideas bit-by-bit or you can chop off big chunks in one slice.
Chopping is great because you can leave behind lots of mediocre or half-baked ideas quickly. An essential rule is not to be afraid to chop early on. Working with a scalpel when you should be working with an axe is a mistake which will cost you valuable time, which is valuable money. And as long as you keep all ideas and features well documented, you can re-attach them at a later point if you realize you chopped too much.
That said, your design is a living thing and if you chop too much at once, it will bleed out. Trimming is great because it’s far less painful than chopping, and helps hone the product into something super sexy and super deliverable. However, as mentioned above, if all you do is trim you may never actually reach your core feature set and move forward, so it’s important to ensure the big picture is taken care of before getting surgical.
We always do a mix of chopping and trimming so that things keep progressing but don’t bleed-out. (The Scalpel & The Axe: What To Do After The Brainstorm)
Do: Chant Non-Permanence
Once we’ve written down an idea, we never cross it out, crumple it up, or throw it away. Since cutting by omission is still an additive process, things stay positive and teammates don’t get defensive when an idea they had gets the axe. A great tactic that helps cut down on any of this defensiveness is to chant the mantra of non-permanence. Sounds Buddhist – and I guess it is a bit actually – but the concept is that all decisions are just temporary early on in a process. Just because we’re trying a particular dress on doesn’t mean we have to buy it.
Concretely, if I’m ever feeling resistance to summarizing or cutting things, I’ll write the following at the top of the piece of paper in all-caps: TENTATIVE – NOT SET IN STONE. Then I’ll keep asking my condensing question (i.e. “What are the 5 most important things the user can do with this app?” or “If you had to pick, would you rather have X or Y?”).
Don’t: Make Wimpy-Ribs
As mentioned above, chopping, while super valuable, can also be dangerous. (Disclaimer: Since I’m a Texas boy, lots of my analogies are meat related.) Occasionally, I see a design or product that’s all bone and no meat, and that’s no good. I imagine a BBQ joint that asked their butcher to cut most of the meat off of their ribs so that they could save a little money. No matter how well they’re seasoned and cooked, the BBQ business will always end up serving ribs that only have a teeny bit of meat. The customer won’t be happy and won’t come back, killing the business. If the butcher shop only sells wimpy-ribs, then they’ll go out of business eventually too.
The meat and fat that the customers are missing are the features in your app you may be tempted to chop off to save some time. But, even though you’ll save time (like how the butcher saves money), no one wants wimpy ribs. You have to find a solid middle ground between efficient processes and juicy feature sets. So when you’re in the nascent phases of feature development, remember to leave some meat and a little fat on those ribs!
Hopefully these Do’s and Don’ts will help you both speed up and improve your development process. Look out for future posts further exploring these, and other, phases in our process.