Plotting for serendipity

I rarely eat lunch at my desk. Eating lunch in a cafeteria is such a precious opportunity to waste. I plot for serendipity. That's right. Some of the best conversations that I have had with people — on my way to a cafetaria or in the cafeteria — are purely serendipitous, but they're not purely accidental. I even pick a cafeteria that requires me to walk a little more. I believe you can always create opportunities for good things to happen to you. When people say "It's a small world", they are so wrong. The world isn't small but they're at the right place at the right time to think it's a coincidence. The coincidences do happen but there's a larger force behind orchestrating the possibilities for such coincidences to occur.

The same applies to creativity. You can design an epiphany.

I have heard people say that they had an epiphany while they were in shower. It's not the shower but it's illumination followed by a prolonged incubation, two phases of creativity. The other two phases are preparation and verification. Preparation is a phase where you decide that you want to solve a specific problem. When you continue to work on a problem over a period of time, your brain, the unconscious, never stops working on it even if consciously you're not spending any time on it. This is called incubation. This lasts for a while. The "shower moment" is the illumination phase where you finally figured out a solution, after your brain unconsciously kept solving it for the entire night, and hence the metaphor of glowing bulb for innovation. What remains is the verification phase to prove that the solution works. We all do this, but we don't spend enough time on the incubation phase and hence many ideas don't go beyond that. You can plot for this epiphany by not letting a problem go for a while even though you think that you don't have enough time to work on it. I tell my students to start working on their projects early on for better results for that purpose. It feels counterintuitive that you could solve a problem by spending less time on it as long as you keep solving it for a longer duration off and on.

I have blogged about cloud being a natural platform to design tools that could create network effects. The tools that create network effects also offer an opportunity for digital serendipity. I have discovered many people through Twitter and learned quite a few things that I would have never explicitly made an attempt to learn. And, I'm not the only one who has had such an experience. I'm a big fan of social tools and platforms that enable opportunities for such serendipity to occur. There're only so many cafes and water fountains in the physical world; the digital world is far bigger in that sense.

Design your routine to plot for serendipity and epiphany and credit yourself instead of the shower. Creativity can be tricked. You will be positively surprised.

Cross-posted on my personal blog

Designing Terms Of Service Is As Important As Designing A Product

Dropbox revised their Terms of Service (TOS) over the long weekend. That triggered a flurry of activities on Twitter. Dave Winer even deleted his Dropbox account saying that he would revisit it once the dust settles. A lot of people concluded that there's nothing wrong in the new TOS and that people are simply overreacting. And then Dropbox updated their blog post, twice, explaining that there is nothing wrong with new TOS and cleared some confusion. I would let you be the judge of the situation and the new TOS. This post is not about analyzing the new TOS of Dropbox, but it's about looking at more basic issue in product design. What we witnessed was just a symptom.

Let me be very clear - your product design includes getting the TOS and End User License Agreement (EULA) right before you open up the service. The way the most TOS and EULA are worded, an average user can't even fathom what the service actually does, what information it collects, what it shares, and most importantly what's that it absolutely won't do. It's ironic that the simplicity element of Dropbox's design — there will be a folder and that will sync — made it extremely popular and when they designed the TOS, they had to publish a blog post with two updates and 3000+ comments to explain and clarify the new TOS to the very same users. There's something wrong here.

For a product or a service to have a great experiential design, it's absolutely important to get the TOS and EULA right upfront and even validated by end users. People release their product in beta and go to a great length to conduct usability study to improve the product design. Why exclude TOS?

I have worked with some great lawyers, but they don't make a good product designer. I'm a big fan of constraints-based design. Lawyers are great at giving you constraints - the things that you can and cannot do. Start there. Get a clear understanding of legal ramifications, ask someone other than a lawyer to write a TOS, get it signed off by a lawyer, and most importantly validate by end users. Then, start the product design using those constraints. If you feel too constrained, go back and iterate on TOS. Drafting a TOS is not different than prototyping a product.

I would rather have bloggers, thought leaders, and end users critique the product design on my blog instead of TOS. I would love to work on that feedback as against getting into a reactive mode to stop the bad PR and legal consequences. Thomas Otter says "law exists for a reason." Don't exclude lawyers but please don't let lawyers drive your business. Educate them on technology and end users and most importantly, involve them early on. The lawyers are paid to be risk-averse. As an entrepreneur, you need to do the right thing and challenge the status quo to innovate without jeopardizing the end users. It's a tough job, but it can be accomplished.

I don't want to single out Dropbox. There are other companies who have gone through the same cycle and yet I don't see entrepreneurs doing things differently. In this process, the cloud gets a bad rep. What happened to Dropbox has got nothing to do with what people should and should not do in the cloud. That would be a knee-jerk response. The fundamental issue is a different one. Treating symptoms won't fix the underlying chronic issue.