Last week I saw OneFineStay COO Demetrios Zoppos give some advice on fundraising. He said to assume investors will have pattern recognition on common categories like ecommerce. They’ll know what the numbers are and when to start paying attention.
I had an idea of where he was going with this, but reading this blog post from Fred Destin helped put things into context:
If you want to win in e-commerce, you’ve got to be crystal clear about the dimensions on which you are going to compete. Scale will crush you unless you fully understand your angles. Without an angle that helps you achieve better margins, whether on customer acquisition, buy-side margins or recurrence, it’s going to very, very hard.
Read it here
A few years ago I saw a B-school lecture on Technology Push vs. Market Pull. Discussion focused on the Segway as an example of a failed technology push venture.
Remember the Segway? It was going to revolutionize walking. Steve Jobs called it “as big a deal as the PC” and John Doerr said it “may be bigger than the Internet”. Nowadays “walking reinveted” pretty much serves as a tourist gimmick.
A key mistake for the Segway venture was failure to validate demand. The technology excited entrepreneurs and investors so much that they looked at the wrong problems prematurely. They put $126,000,000 into the company, addressing risks such as limited manufacturing capacity before there was proven demand for the product.
A funny, illustrative example from the lecture was the three wheel Segway ripoff. This would have been a simple way to test people’s appetite for replacing walking without all the expensive tech required. MVP much?
Much like product features, business risks need to be prioritized. Segway’s (drastically oversimplified) business risk backlog may have looked something like this:
- Steve jobs won’t give us a pithy quote
- We won’t be able to build enough of them!
- There’s no demand for revolutionizing walking
Hindsight is a harsh mistress, but it’s pretty clear that the demand risk belongs at the top. And Steve Jobs goes at the bottom.
- There’s no demand for revolutionizing walking
- We won’t be able to build enough of them!
- Steve jobs won’t give us a pithy quote
Like any good product backlog, risks have dependencies. You can’t release the world’s best spell checker before having a word editor, so it’s obvious what to focuson first. In the same way the scaling risk above is only applicable if the demand risk is mitigated in the first place. A risk register is a good place to start for keeping track of things and it helps to categorize them by business area if you’re having trouble prioritizing.
Collective Wisdom & Gospel
Collective wisdom has moved on since the post-dot-com crash. Between Marc Andreesen, Steve Blank, Eric Ries, et. al. the terms customer development and product market fit have become synonymous with new technology ventures. That doesn’t make it any less fun to use spectacular failures from the past to keep us alert.
Beware treating demand-driven-development as gospel, though. A lot of technology products are decidedly short on innovation and a lot of innovation comes from technology pushes. Think of the world wide web, the music synthesizer, the first video game. You couldn’t go around customer validating these terribly well, but if you’re building them on limited time and budget, there comes a time to validate demand. Figuring out when is still more art than science.
Saw a cool image this morning:
Played with GIMP to make a wallpaper:
Credit to startup philosopher FAKE GRIMLOCK via Brad Feld’s Blog,
Like most creative professionals my command of Intellectual Property law is woefully inadequate. I wouldn’t even be aware of this if I wasn’t for the constant reminders of lawyer friends who a) know much more about IP than me, and b) consider their own knowledge inadequate.
As someone whose livelihood depends in many ways on Intellectual Property, what am I to do? The answer, of course, is to devour information, learn from your mistakes, and get professional advice.
In the meantime, here’s a short story about the invention of a heuristic invented by my friend Andrew. It’s called the Sex Tape Litmus Test:
After a year of working at Sony Computer Entertainment the standard employment contracts were changed and employees were asked to agree to new terms. This took the form of a nagging email reminder that sent you to an ‘Accept’ button on the company intranet. The problem was that the new contracts had a much broader definition of IP.
The gist of the original contract was: *
Sony has the right of first refusal on any video game related IP you develop in your own time.
The new agreement said something along these lines:*
Any IP you develop at any time over the course of your employment belongs to Sony.
After reading the terms and ignoring the emails for a few weeks a “Sarbox Compliance Officer” was assigned the unenviable task of harranging me into clicking the button. This brought on a conversation with Andrew and a subsequent discussion with Human Resources in which Andrew offered a delightfully ridiculous test of the new terms:
“If I make a sex tape with my girlfriend, according to this agreement the IP automatically belongs to Sony.”
And with that, was born a new bare minimum heuristic for overly restrictive IP clauses in employment contracts: The Sex Tape Litmus test: don’t get caught with your pants down.
Discuss this post on Hacker News
* I don’t have copies of both contracts, so these are not actual quotes, merely an approximation of the differences. Please don’t make any life decisions based on my shoddy recollection of a lengthy legal document.
Note: This is an extremely low bar. For your own ‘protection’ you’ll want something better as an employee. Having said that, I am not a lawyer. Please don’t treat this as legal advice - see a professional if you need help.
Parse has been growing in popularity and mind share. It’s a quick way to get a mobile application with a networked back end up and running. It saves you time from creating a REST API for your application’s back end, and a mobile developer can build an entire app in native code, including the data model
Quick iteration times - If you want a simple CRUD application that allows your users to authenticate via facebook, retrieve some information, and maybe leave a rating or a comment with a simple data model Parse is very useful.
Native development - A mobile developer can do everything from the client side as the network layer and data store interface are baked into the Parse SDK. No need to deal with server deployment, scaling, uptime, etc.
Server-side logic - Parse does not allow you to run logic on your server. This means a certain class of problems that aren’t simple database access (product recommendations, user matchmaking) are much harder than they need to be.
Scalability control - I’m sure Parse.com employs some good scalability engineers and can run their own platform well, but that’s a far cry from being able to handle a scalability issue on your team when time is critical.
Lock in - Since you’re using the Parse SDK, if you ever wanted to have more flexibility and control by switching to your own back end, it will take a lot of work extracting the Parse SDK from your client. In essence it can result in a large amount of technical debt you have to pay down.
The Bottom Line
It’s good for a mobile hacker to Parse in his or her toolkit. It lets you quickly build an app with a back end and does a lot of heavy lifting for you.
If you’re trying to build a business for the long term and control over your scalability is significant concern, or you require significant server-side logic, you’re better off with your own back end. You could still integrate with Parse for some of its nifty features, but having your own server stack will give you control when you need it.
As with any technology decision, in the end it’s largely dependent on your use case.
Here’s a quick video of the protoype I hacked together over a weekend last month while in Berlin.
It’s a social marketplace app for browsing design products with a fun browsing & feedback interface – swipe left for next, up to discard item, down to ‘favorite’. There’s also a product upload/download feature to a Parse.com back end, which has its limitations but is great for a quick hack.
First line of code to project demo/pitch was a mere 36 hours, with a bit of commute + sleep in between :)
What went right:
Good team composition
We had 9 people at the start and there was a good mix of people with different skills - 5 hackers of some sort, 4 non-hackers. Not everyone made it through until the end but we still had a good mix of technical and business talent.
Getting out of the building - Credit to our biz guys Christian and John M. When we needed some customer feedback they ran around tirelessly talking to people. They knocked on coworking space doors (on the weekend) to get some insight and generally provided a good shot of energy to the team.
Determination - Everyone left by Sunday evening had pitched in and done their part after a long weekend. @missuze kept the vision AND knocked out our demo site; @raisercostin calmly reminded us of the objectives when things got frantic and pitched in wherever possible; Christian presented and brought lots of energy; @jonmathews put together the deck and the numbers; and @johnvdenley got user feedback and took the Ninja plunge.
Team DeskNinja.com Sunday Evening
The Ninja - Christian and John also came back with a Ninja costume. This seemed a bit silly at the time since nobody wanted to embarrass themselves by wearing it. Big John eventually gathered more courage than the rest of us to try on the costume. Once he had it on he wouldn’t take it off and it made the presentation and event memorable and fun.
What went wrong:
No designated project manager - A designated project manager was a must according to the guidelines. We failed to designate one and suffered accordingly. I tried to do as much of this as possible, but splitting time between managing and hacking is challenging under the best of circumstances, and a team that size needed better organisation.
Attrition - We lost a third of our 9 person team by Saturday evening, including the person who controlled the domain, which made things a bit challenging. Some of it was just down to people’s reasons for being there, but a better evaluation of people’s skills and commensurate roles and responsibilities might have kept everyone involved.
Execution - As a result of some early customer feedback and finding a number of established competitors we were thinking about changing our tactics well into Sunday morning. This distracted us from getting everything done and setting a clear goal.
Tools - In retrospect a lot of tools would have been useful from the start. We made a shared Google Doc, but we could have used Dropbox to share files, a simple email group to share things via email, etc.
The DeskNinja himself!
Designate a project manager - Someone needs to organise the team, assign roles, and plan the weekend. Decide what the final deliverable is and plan backwards on the critical stuff.
Start at the top - Do proper introductions to get an idea of people’s skills and desires. This takes just a few minutes but I feel that it’s critical to make sure people are involved and contributing.
Focus on the product/user - UX & Design is important. Start with the customer and work backwards. This means both the user of your service, and the judges who you’re presenting to. Look at things from their side and figure out what needs to be done to get there.
Let individual contributors get on with it - We had trouble picking a tech strategy because everyone knew different stuff. We also wavered on our approach too much after talking to mentors and judges. (Their advice was superb, but you have to be realistic about what you can achieve in a weekend.)
Execution matters - When push came to shove around lunchtime on Sunday we started focusing on the presentation at the cost of a demo, including a working iOs client. In retrospect a good working demo wasn’t just one of the judging criteria, it was a key way to communicate what your team had accomplished.
Looking forward to @sc_seedhack to apply some on the weekend!]]></content:encoded>
I was at Startup Weekend London at Google’s new Campus London this past weekend. I had a load of fun, learned a lot and would recommend it to just about anyone.
Startup Weekend is essentially a Hackathon on steroids. The objective is to go from an idea to a Minimum Viable Product over the course of the weekend with a team of enthusiastic people put together on the spot. The formula is a winner.
There are lots of activities to encourage networking and team-building and the energy was buzzing. Things started out with a mixer activity that saw randomly thrown together teams pick a pair of words (kinky/fast anyone?) and pitch an idea to get people in the mood. Afterwards about a third of the 150 or so attendants pitched an idea. People were given time to discuss and vote for their favorites. After some last minute instructions teams formed for the evening and people went home.
I was torn between a couple ideas. One was a mobile travel app “What Now” that provided ‘in-destination planning’ by letting you prepare your daily plans on Hotel wifi to avoid expensive roaming charges. This is definitely something I’ve tried to do in a cobbled together approach so it sounded good.
The other team, the team I eventually joined, was “DeskNinja” - basically a marketplace for empty desks (AirBnB for Workspace). I put my name down for DeskNinja, we formed a team of interested people, and everyone left for the evening. Team creation was a sight in itself - lots of recruiting, smooth talking, and last minute changes of mind!
The rest of the weekend was a whirlwind of planning, organising, talking to customers, hacking, and pitching. The gamut of emotions included despondency, terror, and exhiliration. The best part was meeting lots of people from different backgrounds excited about starting something new. The group of 15 or so stragglers that ended up at the Hoxton Hotel as Sunday gave way to Monday clearly didn’t want the weekend to end, and who could blame them?
A few months ago I decided I would start using Vim again. I tried switching a few times before but never stuck with it, mostly because of the abrupt changes from using Notepad++ at work and TextMate at home.
My motivation was the rather sensible Pragmatic Programmer advice about using a single editor well. Vim is as ubiquitous as it gets and its presence on every Unix machine I’ve ever used sealed the deal over emacs.
I had tried switching to Vim with limited success before. A big help in sticking with it was a mental approach inspired by a Yehuda Katz post on reducing friction while switching to vim.
Using MacVim and sticking with my normal editor habits (cmd-t for new tabs, cmd-c, cmd-v, etc) was very useful - it let me resort to a lot of familiar approaches while learning some unfamiliar ones.
The problem with the ‘one editor’ thing is that Gvim on Windows just isn’t as nice as MacVim. Os X’s apple key leaves the control key open for all the standard Vim commands like ctrl-r (undo) ctrl-v (selection) etc. A number of these have to be remapped in Windows, which means that the whole ‘one editor’ thing is a bit of a fallacy. The same goes for using the editor on a remote machine - while using vim via a console can force you to get familiar with the h j k l keys for directions and such, any productivity-related improvements made via the .vimrc file or plugins are missing.
Be that as it may, I’m glad I’ve been working with Vim. I’m much more productive doing stuff over ssh and using the newly learned shortcuts in other places (e.g. navigating man pages, which are viewed with less, which shares a lot of commands with vim) is a big bonus.
I’m still tempted to have another try at emacs, which I last used in earnest during Networking class at college, if only because there are similar command overlaps with the rest of Unix & Os X ctrl-w (delete previous word) ctrl-y(yank a.k.a. paste)
Verdict? Stop pondering the perfect editor and get some work done :) Oh, and try Vim for a while - even if you don’t stick with it, the things you pick up will make you more proficient working over ssh or browsing a man page.