We work by very simple rules in our group. Maybe you will find them useful in your own projects…

[ Rule #1. KISS ]

Sometimes people simply know how to solve a particular problem. They feel the answer in their guts, they know that they’re on the right path, and they keep on going. But in other times, they overthink problems and their solutions.

In fact, your intelligence may often prevent you from achieving results – that’s when you think “someone probably has done it”, or “this app is too simple, it’ll never spread”. If you were a little dumber and didn’t ellaborate for so long, well, maybe you’d have succeeded…

So Keep It Simple, Stupid. Simpler solutions work best, cost less, and are easier to adopt. If they’re not that good, you’ll think of something better in the process of creating them. If you don’t think of something better, well, it didn’t cost you too much.

 [ Rule #2. ASAP ]

We are tired of thinking cool technology solutions to everyday problems, and then finding out that someone else has launched the exact same product or service before we did. What might be the occasion then?

• we’re thinking too much (instead of simply delivering)
• ideas are everywhere, and someone got it just before we have
• they’ve been thinking for so much longer than we have, so it’s useles caring

Whatever. When we start questioning ourselves “should we build this?”, it’s almost too late. The time to build is As Soon As Possible… So we focus, develop, and ship early. Better yet, we keep it simple, and it can be launched even sooner.

[ Rule #3. BTDT ]

That’s “Been there, done that”. 

When we talk about features or aspects of a product, we combine brainstorms and guided discussion to achieve a particular goal. During those conversations, we often catch ourselves in the middle of a terrible sentence: “I don’t like it this way – why not the other?”

We’re not supposed to like anything – the user is. Since we are the ones who are probably overthinking the product (and taking too long to launch it!), we should turn to the user profile and put ourselves in his/her shoes – observing the problem and solution, and only then saying something about it. We will only be good references to the “I like (…)” sentences if we’ve been on the user’s position in the past.

So we’re not supposed to say “I like it better” such as in “I prefer blue ‘cuz that’s mah favorite”. Either one of us KNOWS it’s better and why, or one should stay put (if you’re a newbie, we’ll still accept “I know this seems rubbish, but do you guys think blue can be a better color?” for a couple of times).

We’re all allowed to propose changes, but further analysis only comes after we’ve BTDT.

[ Conclusion ]

This may seem too straightforward, but we’ve been guiding ourselves well so far and those 3 simple rules are all the process we have. Suggestions?