“Pa, what are you doing?”
“I’m trying to open a video file but none of the video players are working, so I’ve downloaded some codecs and installed them”
(sunken feeling as I hit CTRL-ALT-DEL ..)

“URRRGHHHHH!!!!!!”
Read the rest of this entry »
“Pa, what are you doing?”
“I’m trying to open a video file but none of the video players are working, so I’ve downloaded some codecs and installed them”
(sunken feeling as I hit CTRL-ALT-DEL ..)

“URRRGHHHHH!!!!!!”
Read the rest of this entry »
Drinking the Customer Development & Lean Startup koolaid isn’t enough even if you understand 100% what to do. Actually doing it in a team in a time crunch while being pushed by mentors is priceless (where Lean Startup Machine comes in).
This is a confession of a solo tech founder, bootstrapping a startup in Silicon Valley. Yes, I have burned my boat; my years of savings dwindle every day (no safety net when I hit $0).
Last weekend, I attended Lean Startup Machine (LSM) in San Francisco. I know what Customer Development by Steve Blank is (ok, I only read up to the Customer Validation chapter since I haven’t got past that point and it’s a heavy read). I know what Lean Startup is too, I follow Eric Ries’ preaching as well. I’ve also read the cheatsheet by Brant Cooper and Patrick Vlaskovitz. Twice.
The past month, I’ve been stuck with my startup: having trouble de-risking the market risk. Spun my wheels, really feeling that trough of sorrow, and not having a mentor to guide me and push me.
I can’t justify time & money on anything else other than my startup, but I know I needed to take a step back, reflect and learn something new, since everything I’ve been trying isn’t working. And I’m so glad I did. The typical hackathon is about hacking code whereas LSM is more about hacking your customers’ psyche [1]. My team got paying customers without writing a single line of code, over a weekend. I don’t think I’ve ever convinced a customer to give me their cold hard cash now with a promise of a product/service.
Lesson 1: It’s one thing to be actually cust-dev’ing, it’s another thing to be actually doing it right.
I *was* already cust-dev’ing: the cold calls, walking up to strangers and striking up a conversation, getting out of the f**king building, but I was doing it wrong, and with nobody to tell me I was doing it wrong … <insert fail>. I was too close to the problem, and I was inexperienced in applying the principles properly. Let me rephrase:
Lesson 1: It’s one thing to be actually cust-dev’ing and think you’re doing it right, it’s another thing to be *actually* doing it right, with the guidance of a mentor. It’s like I needed to iterate on my own understanding & application of lean startup. Sounds meta—I know, but it’s true.
Lesson 2: If you were doing it right, results you think you can accomplish in a week, a month, a Wall St. quarter, you can do in a day or two.
The same conclusion that Eric Ries said at the start of LSM: that LSM made him realize how precious a single day can be. The key of course, is to be doing it right in the first place. I now feel dumb having been stuck for a whole month; but I couldn’t possibly know what I don’t know, without a mentor.
Lesson 3: If you’re a solo founder, doing it in a team (your weekend “cofounders”) is so much more fun!
Clearly, this is contingent upon the getting the people chemistry right, which is hard. I got lucky. But as a solo-founder for months, you get a taste of what you’re missing out on. It’s lonely and there is more to do than you can humanly handle. During the crunch, everybody was firing on all cylinders, and whenever I completed my task, I would ask my team, “I’m idling, what can I help with?” and just jump in and do whatever it is that is needed next.
Lesson 4: Get a real commitment from your customer. That is, your customer gives you a scarce resource: time, attention, or money. Before you go build.
At the start of my team’s journey, we were trying to validate “will people want this?” But that was actually the wrong hypothesis to test in our situation (as the mentors corrected us), the riskiest hypothesis was actually “will people pay for this?” because if we gave it away for $0, of course people would take it! We then proceed to well, ask for money. We offered a 100% money return guarantee, no questions asked policy, so strictly speaking, there’s absolutely no risk to the customer. But by asking for money up front, we’re asking them to commit to us, because we’re committing to them too (we’re working hard to provide them value!)
This one is basically the “get the purchase order” before you build as Steve Blank says – but this one really only sunk into my head this weekend. If you’re too scared during a conversation to ask your prospect for money/time/attention, remember these words, “F*ck You. Pay Me.” at minute 2:05 (ha, just noticed that this video was also taken at Typekit’s office, where LSM was held too.)
Lesson 5: Nevermind the saying “if you fail, don’t forget the lessons”, if you fail at the wrong things.
I’ve been talking to the wrong people, testing the wrong hypothesis, asking the wrong questions. I only now know that I’ve been cust-dev’ing wrong because I learned by doing at LSM. [2]
Lesson 6: If you really have the entrepreneurship “virus”, failure sets you free. LSM validated my hypothesis that I really am addicted to “temporary organization designed to discover a profitable, scalable business model.”
I too was caught up with these worries (“garden variety” as Mark Suster might call it):
I’ve burned up yet another month of runway without progress on my startup, and thoughts of “What should I at least get out of this experience if I completely lose everything I have?” crept in to my head. Maybe I could at least become even better at my forte Django, Python, scaling LAMP (back-end web) Django. Or maybe I could become good at something I’m “just ok” at, like jQuery, CSS3, slicing PSD’s (front-end web), or maybe even design, UX, UI.
They’re all good things to have in my inventory of technical skills, should I walk away with nothing else – but I felt something missing. I couldn’t really say “get better at cust dev” as a skill, since reading the books repeatedly and failing on my own didn’t seem like it was making me better at cust-dev’ing.
I hang on to my dear startup as if it was my life, but if I fail, I’ll be doing yet another. If I succeed, I’ll also be doing yet another. After being on the team at LSM and cust-dev’ing it like there’s no tomorrow, I realize that should my startup tank, I know exactly what I want to get out of it: getting better at cust-dev’ing! Mentors halp?
I highly recommend it. Here’s what I’d do differently. When you’re picking an idea + team to join ..
Swing for the fences, or at least, don’t hedge.
Don’t optimize for an idea that’s tractable within the confines of 2 days. I thought to myself that since we only had 2 days, I’d better pick a simple idea to work on that seems tractable (Evan William’s definition tractability). I ruled out ideas that I thought were too difficult to implement much less cust-dev in 2 days. Notice how I said “implement” before “cust dev”? Engineer in me thinking about implementation risk first before market risk again. Oops. Don’t do that.
If you’re not failing enough, you’re not learning enough.
With my team, I felt as though we didn’t fail enough, which is to say we could have learned more. We largely got it right too easily. That’s not a bad thing, but if you find yourself by and large having it easy, just keep aiming higher until you get it wrong and fail. If we aimed higher, got it more wrong, we would probably still end up at where we did, but we would have learned much more.
This requires a mental shift from trying to make things look pretty and everything working nicely (to externally impress whoever), to being publicly open / honest about about how you aimed high and really screwed up. Playing it safe is not for startups. Pretending to look as good as possible is for your boss in a big company. LSM made me embrace failure even more so, and being open and public about it. Another thing to read & understand, a whole nothing thing to actually do and have that message sink in.
Set your expectations right and don’t forget it’s a team sport
One thing I suspect my team did right was we didn’t bicker about status or roles. Everybody jumped in and did whatever work (glamorous or otherwise) was needed to accomplish the overarching goal. We didn’t discuss before we started who would be CEO post-event, who would get how much equity if we got funded and IPO’d. We were one well-oiled execution machine. For me, my expectation from LSM was that I learn about lean startup and that is exactly what I got.
Camaraderie and working alongside other startups
Working alongside the other teams during LSM gave me a taste of what it feels like to be working in a startup accelerator, alongside other startups. Everybody’s fighting against a common enemy for early-stage startups: irrelevance. Non-consumption.
The alumni network built from just a 2-day LSM crunch is impressive (for 2-days, it’s very “sticky”). Many people even across different teams have developed relationships that I suspect will go much further post-LSM. I explicitly mention this because I’ve never felt this sense of belonging to a community post-event from any other startup event, code hackathons and networking events included.
A big thanks to Trevor Owens, Steven Liu, Nate Berkopec and the rest of the LSM crew I know I’ve missed out on for making this happen.
And a big thanks to the mentors!
Thanks to Dan Martell for holding my feet to the fire; Hiten Shah, Brant Cooper and Patrick Vlaskovitz for giving me advice here and there over time.
I’ll never forget what Dan Martell told me: “Do you want to be a real entrepreneur, or are you like the wannabes? If you want to be a real entrepreneur, then you must all the things that the wannabes are afraid of doing.” (paraphrased).
Just as Hacker Dojo was born as a permanent fixture of SuperHappyDevHouse success, I hope that LSM will keep snowballing larger and one day give birth to its own permanent fixture
RezAmaze came in 3rd place with best MVP (paying customers without a single LOC)!
From left to right: Navneet Loiwal, Tommy Tsai (sitting), me (standing), Jessica Rosenberg.
[1] It’s not that you can’t bust out your IDE and start stuffing your interpreter with code. Participants have only 2 days to work. Most startups are market risks (“will they come?”), as opposed to a technical risks (“can you build?”). If you can de-risk the market risk while also building product in 2 days, all the more power to you.
[2] Ok, I’m not a complete utter moron unable to grasp lean startup; I’d say I was “slightly” off, but evaluated from pure results, it was just wrong enough that I might as well be one.
I first heard this song playing at Happy Hour at Hacker Dojo and made a note to look it up. If my recent plunge and move to Silicon Valley had a theme song, this would be it!!!
Read the rest of this entry »
If you haven’t dabbled with AWS before and are impatient but want to kick off a free instance to play around with it, here’s a perspective and lessons learned from a LAMP + Django guy who had no prior experience. Caution, this is just enough for you to wrap your head around the major concepts and get your first hello world instance off the ground. Beginning is always the hardest, I hope this will help lift you off the ground as I document the things I found out the time-consuming way.
EC2 instance is like a VM – but without a local hard disk. Instead, the VM uses a highly reliable external drive (EBS). Think of EBS as a really big USB drive, and just like a USB stick, it’s a raw device that needs to be formatted first. The obvious upside of this setup is you can use a low-powered VM (to save money), and when your site gets popular and you need to scale up – just quickly turn off that low-powered VM (the EC2 instance), fire up a beefier EC2 instance and attach to it the same EBS. And just like that, you’ve got a beefier machine running to handle the load.
Note: The EC2 instance just described above is what is known as an “EBS-backed” instance (the root device is an EBS volume, which is where the OS boots from), as opposed to the other option “instance store” (a.k.a. S3-backed). The latter option is for advanced use – not the focus of this primer
So when you’re firing up your hello-world instance, choose EBS-backed, not instance store. Similarly, ignore the AMI creation process, that’s advanced stuff you can visit later. Use one of the already existing AMI’s – like the ones provided by Ubuntu. My example uses Lucid Lynx.
Statistically, EBS is also actually more reliable than a local physical hard drive. However, you’d probably want to take snapshots of the volume (how confident are you that your data is safe on a USB stick?) Snapshots are stored in S3, which is even safer because it’s stored around the world (in case one continent gets wiped off the planet). Subsequent snapshots are also incremental deltas from previous snapshots, thus you save space. Although you’re fine if you just want to keep just daily 1 snapshot (unless you have a reason to want many daily snapshots).
Ok, at this point in the post, you should go ahead and follow AWS’s guide to firing up your 1st Ubuntu instance (remember, you can ignore the AMI creation stuff for now, and choose the 8GB EBS-backed instance – especially if you want to use the 1-year free micro instance). I’ll wait.
I’m still waiting.
Ok, at this point you should have it fired up and running, and be able to ssh into it. I ssh into mine with: ssh -i username.pem ubuntu@ec2-111-222-333-444.us-west-1.compute.amazonaws.com
Now on to some basic first time house-keeping items, best practice stuff.
On your new EBS-backed instance, that EBS volume has a flag called the “delete on termination” flag, which default to true. You’d probably want to set it to false. If it’s set to true, that means EBS root volume is deleted when you terminate the instance. Instances can be started, stopped, and terminated. “Stop” means you can start it back later. “Terminate” means delete, and you can’t un-delete. The following example uses Amazon’s EC2 API tools. Be sure to download your X509 certificate and private key (these are both files you download from your Amazon account). I’m using OS X 10.5, so change accordingly. Be sure to set your Java home too.
OSX-LEOPARD:bin jliew$ export EC2_HOME=/Users/jliew/Desktop/ec2-api-tools-1.3-62308/ OSX-LEOPARD:bin jliew$ export EC2_PRIVATE_KEY=/Users/jliew/pk-q3ef98zHSDg872hGTQpoX.pem OSX-LEOPARD:bin jliew$ export EC2_CERT=/Users/jliew/cert-SDkhIzWU3HDqS83sXdsefh.pem OSX-LEOPARD:bin jliew$ export JAVA_HOME=/Library/Java/Home
Once that’s set up, you’re ready to go. Don’t forget to pass it the region (mine is us-west-1), your instance’s id, and volume id (and volume mount point):
OSX-LEOPARD:bin jliew$ ./ec2-modify-instance-attribute -b /dev/sda1=vol-wuh5da87:false i-ppo983x1 --region=us-west-1 Unexpected error: java.lang.ClassCastException: com.amazon.aes.webservices.client.InstanceBlockDeviceMappingDescription at com.amazon.aes.webservices.client.cmd.Outputter.outputInstanceAttribute(Outputter.java:664) at com.amazon.aes.webservices.client.cmd.ModifyInstanceAttribute.invokeOnline(ModifyInstanceAttribute.java:149) at com.amazon.aes.webservices.client.cmd.BaseCmd.invoke(BaseCmd.java:795) at com.amazon.aes.webservices.client.cmd.ModifyInstanceAttribute.main(ModifyInstanceAttribute.java:269) OSX-LEOPARD:bin jliew$ ./ec2-modify-instance-attribute --region=us-west-1 -b /dev/sda1=vol-wuh5da87:false i-ppo983x1
Noticed how it actually crashed with an error? Turns out, other people faced this problem too, but the command actually succeeded. To verify it succeeded, run:
OSX-LEOPARD:bin jliew$ ./ec2-describe-instance-attribute --region=us-west-1 --block-device-mapping -v i-ppo983x1
and you should notice this that somewhere within the output is a line that looks like this: <deleteOnTermination>false</deleteOnTermination> Read the rest of this entry »
Update: The idea of SHDH in San Diego was conceived from within the SD Hacker News group who then ran the event; but after the 2nd event, it’s clear that this is pretty much a movement that deserves to stand on its own (time for a “spin off”!) Official page and mailing list.
Our second ever SHDH here in San Diego just concluded, and it was a blast (again!)
Thanks again to Erica for hosting the event and Microsoft (hat tip to Aaron) for the pizzas. Having a light touch of corporate sponsorship really goes a long way for a grass-roots bring-your-own-everything event! When I asked “who wants pizzas?”, about 70% of the people raised their hands.
This time we up’d our attendance cap and had almost 30 attendees. Roughly a quarter were hardware hackers, and the rest were purely software (web apps, Android + iPhone apps + the upcoming contender, Windows Phone 7!)
Jim & Terry who started Hackerspace San Diego invited us all out to check out their co-working space in El Cajon (a large aircraft hanger), fully equipped with tools for hardware hackers.
A couple of other random things I’ve learned along the way:
We’ll keep doing SHDH-es as long as long as there is interest, for as long as we can!
Looking ahead, our possible venues for SD SHDH 3 would be Erica’s new residence (if possible), or at the Ansir Innovation Center in Clairemont Mesa (6,000 sq. ft. co-working slash startup incubator space – see pics – thanks Bin Li from Ansir Corp for offering!)
Your happy SD SHDH 2 hosts post-event:

Recap of pictures and video clips from the previous SDSHDH1.
** special story **
One thing I learned working 6 years now at a publicly traded B2B software + hardware tech co is the tension between sales and engineering that I’m sure isn’t unique. To generalize, here’s how they think of each other (at least the ones who dare publicly say it):
If you asked an engineer which department is the most important to preserve (during bad times) or pour more money into (during good times), it’ll be engineering. If you asked a sales person, it’ll be sales.
Here’s a new perspective:
A company has to build something and it into the hands of customers in exchange for money to survive. The engineers engineer the product. The sales guys engineer the (human) relationships. The lack of either 1 in the equation will result in disaster. This is similar to what Customer Development is about. A lot of times people focus on the product, but the neglect the human aspect (plug: SD Lean Startup).
In my efforts to hustle and get the word out about our events, during the days when I wonder where I’m going to find 4 walls and a roof as shelter for our next event (given that we have $0 in our bank account, or the lack of a bank account to begin with, or the lack of a membership/event fee to precede that), where I’m going to find that 4 walls for the next-next and next-next-next event … I’m reminded that as a techie at heart with a computer science background that technically, this is not a technical problem. This is a relationship problem, and this ride has forced me to get out of the classic techies’ comfort zone. Organizing these events is pretty much like running a startup: gotta make more with even less (which in our case, was zero).
Business is a human enterprise.
— Keith Ferrazzi
To that end, I’m truly proud that we’re able to keep our events free of charge for you party animals (yes we know you’re all price sensitive cheap @#$%* too
), and I’m happy when the attendees walk away happy. I’ll even go out on a limb here and risk disagreement by making the following forward-looking statement: We will never charge SHDH & SDHN attendees as a requirement. The conventional wisdom about keeping out not-genuine people doesn’t apply to us since people know what we’re about (accurate PR message) and false-positives wash themselves out after one visit (must be that stench of an intense group of highly passionate and genuine people!)
###
(imagine that the below is a scrolling list of text like you see at the end of a movie)
###
Special thanks to the people who’ve let us use their home and business for shelter so far!
(insert page break)
Tom Han (Broadway Coffee – pls write a review! God knows how many times I’ve had to stress out over when 1 person forgets to pay for their drink!)
(insert page break)
Erica Douglass (for her big heart!)
(insert page break)
Also special thanks to Joël Franusic from SHDH “HQ” for special event org advice!