Guillaume Lerouge’s blog

Jason Fried over at SVN:

I’d say “Why does it matter right now? I’m not racing anyone today. I’ll do it right at the meet this weekend.”

“I’ll tell you why it matters” he’d say, sternly. “You play like you practice. Practice sloppy and you’ll play sloppy.”

From http://37signals.com/svn/posts/3504-you-play-like-you-practice

I have seen this happen so many times, both in sports and in my professional life. Right now, my field hockey team is experiencing a very bad run : 9 losses and 2 draws out of 14 games played this year. Guess how much we practice? We don't.

The same is true with the projects we're working on. Once you've made a certain set of mistakes a number of times, you stop seeing them when you do them. They become a habit. Bad work habits are very hard to break.

An implicit message is the importance of having a coach who's there to point out your bad habits and force you to do things right. Whether while playing sports or in your job, having someone who is able to help you learn how to do things right is invaluable.

Fred Wilson at his best:

When everything goes well, you really don't need that much from a VC. Of course, I have added value in all of my winners. But its the ones that don't work that I have left my blood, sweat, and tears on. And that's the paradox of being a VC that cares. Which is the only kind of VC you want to work with.

From http://www.avc.com/a_vc/2013/03/when-things-dont-work-out.html

A good article about when giving too many options becomes a bad thing:

Most of these options exist for historical reasons — whenever there’s a new feature, it often gets a checkbox to turn it off. The other common case is when a feature isn’t obviously useful to everyone, and it’s hard to make an obvious choice about whether to have it enabled by default or not — so we build in a switch.

I believe we have been subject to this shortcoming on a regular basis with XWiki too. It happens like this:

1. Someone wants to rewrite an old feature or add a new one
2. Someone else asks: "Shouldn't we keep that old feature available? Should we really ship this new feature?"
3. People start arguing endlessly about whether or not the feature is going to be useful, most of the time without looking at any actual data about how the feature actually is being used
4. Someone jumps in with a awesome suggestion: "Let's make it optional and provide a setting in the administration / configuration file!"

While this is great for legacy compatibility and ease of customization, it can quickly lead to overly complicated situations: "-The software isn't doing this! -Did you check whether option XXX and YYY were activated? -No, how do I do that? -Well, you just have to go to screen AAA, then update setting BBB...". You get the gist. As evidenced by Barry Schwartz in this TED talk, there is such a thing as giving people too many options to choose from.

It takes determined leadership to stand in, cut the crap and remove what's no longer needed. This kind of approach can be tough to enforce in the context of an Open-Source project. Advocates of democracy, openness and freedom, I hear you. I am sympathetic to your views. They even make logical sense.

The thing is, great design requires that you keep only what is strictly necessary to build something amazing:

Apple wanted so badly to make a stunningly light and thin computer that they ruthlessly chose body design and build precision over lots of USB ports and an optical drive. Those two features are damn useful, and at the time every other computer had them. But they simply couldn’t have made such a slim, lightweight computer without a move the earthcommitment to get rid of everything that got in the way of their goal. 

From http://schloss.quora.com/The-Importance-of-Being-Ruthless-1

Options give you an easy way out of tricky design decisions. This is why you need to take them out ruthlessly if you're serious about building a great product.

Truly innovative technology products have at their core some pretty amazing technology. And then there are products that are mostly a re-packaging of something that came before in a nice wrapping. Those should not be worthy of our time and attention. This is the point E. Gün Sirer is making in a recent blog post:

But it's critical to keep tabs on the ratio known as "glue versus thought." Sure, both imply progress and both are necessary. But the former is eminently mundane, replaceable, and outsource-able. The latter is typically what gives a company its edge, what is generally regarded as a competitive advantage.

So, what is Yahoo signaling to the world? "We value glue more than thought."

Not only does the organization need to learn how customers will acquire and use the product, it is also true that the product itself may not be exactly what the market wants. In other words, launching a product is not the same thing as achieving product market fit.