Startup weekend – startup lessons learned presentation

During the demo’s at a recent startup weekend event in Edmonton I was fortunate enough to have the opportunity to share the experience of starting a technology company and eventually selling it.  I also highlighted some lessons learned, things we did right, and things we failed at.
I plan on writing posts that dive a little deeper into the presentation, but for now, here’s the slide deck from the presentation.

What not to do when creating a software demo

I recently went through the pains of making a demo for an upcoming product. Perhaps the most obvious thing that I learned from this trial was that there is a reason people do this sort of thing professionally!

Needless to say, I took my lumps and in the end generated something that closely resembled a big steaming pile of poo for a demo. Fortunately, there will be a second crack … and we received some awesome feedback from Steven Blank, author of The Four Steps to Epiphany, a classic on bringing a product to market. Some lessons learned when making a demo:

4. Slow down
People watching the demo haven’t lived, breathed, and dreamed Attassa for the last year and a half. Chances are, it’ll take them a bit more time for things to sink in and make sense.

Screens need to be displayed for more than a fraction of a second, actions need to be explicitly pointed out, introduced, and explained.

3. Keep a running dashboard of benefits
One of the best suggestions that Steven had was to create a running list of benefits. As these benefits were being demonstrated, check them off of a list; making them painfully obvious. Clear Context does a nice job of the running dashboard of values.

2 . Create a demo scenario, not just a list of features to demonstrate
The most compelling demos are those that are able to show a real life usage that resonates with viewers. Without getting overly specific in any scenario, you can usually come up with one that is generic enough to convey value, while specific enough that the practicality of the software is beleviable.

1. The point of the demo is demonstrate value
It took me about 2 minutes to lose track of this and my engineering side to pop out as I proudly sliced together clips, transitioned audio, and in general, used every feature of the screen capturing software.

The face behind a name … and a title.


My girlfriend dislikes being called doctor.

A quick survey of the large stack of mail that typically resides on her coffee table reveals that none is addressed to “Dr.”, and if asked, she would show you that the cards in her wallet would indicate no such intitials. Furthermore, when asked by a stranger what she does, she responds by saying “I work at the hospital.” Her next response is typically, “Actually I’m a physician.” Of course, this response is required to correct a typical “oh, you’re a nurse” declaration by the stranger. I admire this modesty in her; perhaps even more than I admire the determination, intellect, talent, sacrifice, and grueling hard work that has entitled her to these initials. I reflect upon my own level of humbleness and the real face behind the “founder of a startup company” title I often mention.

After listening to a “White coat, Black artpodcast on CBC radio one exploring how MDs haul out their credentials to get perks; I reflected upon my own behavior. It seems as though in our software industry, to many, “founder in a startup company”, is viewed as a glamorous position. This was certainly reflected at Seattle Startup Weekend at Adobe. In contrast to obscuring these credentials, I take every opportunity to make them known. From my blog, business cards, collabomatic t-shirts, to conversations with my hairdresser, I far from hide my occupation.

Perhaps I just realize that the life as a founder of a startup is fundamentally fleeting …. subject to a ticking clock and the maturity of the company. Unlike a lifetime with a “Dr.” title, I am simply making the most of the small window of time. Furthermore, core to the success of your company is exposure of both the company and its founders, so on occasion self promotion is required.

Without a doubt, the effort and sacrifices in founding a startup are something to very much be proud of. However, I think there’s a line between enjoying the moment, being proud, gaining exposure …. and … bragging. I’ve probably stepped over this line on occasion.

Modern user interfaces could learn a lot from Tecmo Super bowl

My fellow NFL enthusiasts from Canada and I were engaged in a conversation this past weekend regarding “the best hit in NFL history” which lead to a Youtube search of “Christian Okoye Steve Atwater.” If you’re an NFL fan, you know what video clip we were in search of. However, instead of the mind blowing Steve Atwater hit we were seeking, the majority of search results were actually of the classic Nintendo cult hit “Tecmo Super Bowl.”

Watching these old clips from the game, frustrations of just getting spanked 38-0 in NFL 08 on the Xbox 360, and a recent Collabomatic UI design session reminded me how simplicity is often a design decision that is overlooked in favor of using every bell and whistle in the book.

In the old Nintendo classic, functionality was dead easy. Offensively 8 plays were at your dispense, defensively, Quarterback controls were limited to 2 buttons (cycling through intended receivers with ‘A’ and throwing with ‘B’). Madden 2008 on the other hand allows for about 9 formations, each with 20 plays, each with audibles, players in motion etc etc. Obviously, Madden appeals to power users.

I’m not suggesting that there isn’t a time and a place to cater to the power user and allow for highly customizable functionality, but I do believe that the in 99% of software interfaces, customization hasn’t delivered enough value to make up for the loss of ease of use.

I think that most if not all software systems start with simplicity being an initial goal; but I see a couple obvious reasons why this goal becomes convoluted.

1. As you start to gain traction, some percentage of users start to ask the “how do I” questions. Because we’re geeks and always looking to make people happy, the easy non-confrontational solution is to build this feature if it’s not already there.

2. As your system progresses, other technologies (hardware, supporting libraries, platforms, frameworks) become available for usage. Because we’re geeks and want to be using the latest and greatest, we often leverage these systems, This is one of the things that Tecmo Super bowl resisted doing. When the game was moved from the Nintendo to the Sega Genesis, the decision was made to stick to using just 2 buttons, even though the Genesis made 3 buttons available.

Neither of these reasons is deserving of catering to the few and sacrificing simplicity.

Off to the Seahawks game.