SocialBias :: a Digital Abstraction of Michael Parkatti

Week #6 is up over at the Globe and Mail.  Full text below:

One of Y Combinator’s greatest strengths is the fixed time span of three months that it offers the founding teams. No matter how ambitious your idea is, no matter how much complexity it involves, and now matter how long it would traditionally take to build in ‘real-world’ time, every team operates on the same deadline.

Some teams had the advantage of having fairly complete products before they arrived in Boston, and some teams started with nothing. The reality is that we all have to present our progress to investors in August, and we have to reduce as much risk surrounding our product’s success as we possibly can.

There is no doubt that Mike and I have a fairly large problem to solve. All things being equal, I would rather try to solve a difficult problem than an easy one. We also want to make sure that we’re solving problems with large implications, rather than the problems of a 13-year-old on his parent’s computer.

Our product development phase will extend beyond this summer. In fact, no software product is ever “finished.” All we can do is perpetuate the dual tasks of building and commercializing.

This week we had a fantastic dinner with Bill Warner, founder of Avid Technologies and Wildfire. He talked at length about his experiences with both companies and correlated his original intentions with their eventual successes. He reminded us that the inventions we make are fuelled by our intentions — and to take the time to truly understand our own motivations behind pursuing a new venture.

Listening to him talk, I was struck by how genuine he was. It’s good to continuously re-affirm that you don’t have to be cold-hearted to succeed as an entrepreneur.

We met with Paul Graham again this week, and he gave us some good ideas about how to refine our product. In the 17 days since changing our idea, we’ve built a lot of software and made a lot of tools, but we now need to focus on how these tools come together in a coherent package. The problem we’re working on involves applying a new approach to an old problem. This means that we not only need to make our product useful, it also needs to be extremely intuitive.

A problem with a lot of software out there is that people have a high threshold of adoption. They don’t want to take the time involved to understand what it does, why it’s useful, and why they should care. People live their lives successfully without software. It’s a massive burden of proof to break through their preconceptions, and show them how their lives could be made better or simpler by using software.

We believe that what we’re doing does have potential to improve people’s lives. Essentially, we need to make other people believe the same thing.