British founder/developer, located alternately in San Francisco and London. Former CEO and founder of Clickpass. Currently working on Pingpanel
Very proud. A wonderful story, beautifully told by my sister, Catherine.
Unfortunately I can’t repost either the audio or the article here but it is in the Times today. if you have a subscription, you can find the article here.
A little while back I was project-managing a team of seven developers building some new social software. As the team’s product manager there was always pressure on me to make sure that “engineering was kept busy”. “Make sure you’ve got enough stuff in the backlog for them, it doesn’t look good if the engineers aren’t coding”.
“Keeping engineering busy” is, for many reasons, a terrifically dangerous business, however even that aside there was something else about this that bothered me.
Each new story added to the backlog caused the entire team to die a little. I could see it, everyone else could see it but I didn’t have any logic substantial enough to halt the trucking and dumping. And engineering needed to be kept busy.
Months later, having left, I realised the problem was the implicit assumption that specs are inert and can be accumulated like like gold or LinkedIn Recommendations. The reality is different. Specs are alive and like all-male safari parks, you shouldn’t cultivate them casually.
The job of the Product Team is to nurture ideas from seed to sapling. We cultivate rows of beautiful greenery, swaying gently in in the nursery. Vital and fresh, full of potential and promise. Once a fortnight the dev team wanders through, grabs an armful of specs and heads out to the fields to farm new features for ravenous users to devour and drop back out onto Twitter.
I prefer to think of specs less as baby flowers and more as adolescent Triffids. Farm them carefully, keep your wits about you and you’ll get a nice ongoing supply of oil-cake to keep your project fed. Lose attention even for a minute and the fuckers will set off a blinding firework display of discussion while they eat you alive at the whiteboard.
Designs and stories are alive. They set down roots and grow. They soak up discussion time in meetings and they seduce and manipulate team members to love and protect them. Try and get rid of a fully specced piece of software that’s been sitting in the backlog for six weeks and you’ll find yourself pulling up roots that run down through your design and UX team and finish up gut-deep in the CEO or worse, the board.
Even if you can control the numbers, you’ll need more bonsai artists than Kyoto to deal with volume. What started out as a seed is now a yearling with the entire biz-dev team picnicking underneath. How the hell did that happen? Who knows but you’re sure as hell not building that API anytime soon.
Nurturing ideas isn’t bad in itself. The problem is the logic behind which ones get nurtured. The ideas that matter are the ones your users want. The ones that get picked are the ones that look pretty, “this one’s wonderful - we shall care for and encourage her and we shall call her Medusa”.
Treat your specs like fresh, possibly sapient, vegetables. Cook them fresh for tasty software or chuck ‘em out before they infect the entire project.
« Previous post Cook something or get out of the kitchen
I seem to have a lot of conversations recently with people who find themselves in the kitchen but without the means to cook anything.
As a cook myself they often ask me how to go about finding themselves a chef who can cook something for them. I ask them why they want to do that and they tell me they’ve got a great idea for a cuisine only they don’t usually have a recipe and, as mentioned, they never have a chef.
This is all happening more frequently since Google built a beautiful new kitchen in East London and it’s driving me a little nuts.
Cook something, learn how to cook something or get out of the kitchen. Standing around for six months trying to recruit a chef to cook a meal you don’t have a recipe for is barmy. Hoping that you’re going to outsell Jamie Oliver on the basis of your recipe-in-a-head is crazier still.
That doesn’t mean you can’t do something else - front of house, marketing, renting restaurants, anything except the job you’re not qualified to do which is to cook. I appreciate that you want to be a wealthy, celebrity chef but you know what the celebrity chefs all have in common? They know how to cook!
You may also be wondering whether you can convince a chef to bring his own ingredients and pans, cook the food and serve it all up on the basis that it’s going to be so brilliant he can take his pay once the customers have paid double the going rate for your nouveau cuisine. Ideally he’d even do it out of his own kitchen, that way you could keep the overheads down and then convince someone to lend you a restaurant once the food’s cooked.
Kind of makes you wonder why he wouldn’t do that himself though doesn’t it? Perhaps it’s that recipe in your head that you’ve not written down or trialled with anyone yet? Must be pretty tasty.
Trial your crazy recipe; throw it together as best you can and show that all-dough pizzas are the new black and you’ve got a different story. Use Twitter to line a queue of customers up outside that beat-up old caravan you borrowed to hack the meal together in and you might find someone ready to cook for you. Hell they’ll probably ask if they can do it for a cut of ownership.
Otherwise, get a job. You numpty.
« Previous post: A simple way to use Mixpanel with Rails
It’s been too long coming but I’ve finally had an excuse to start using Mixpanel. It’s excellent. Really sweet and their event streams are *exactly* what you need in the early stages of a product.
Avoiding the normal integration - javascript listeners and callbacks
Most people probably do mixpanel their event logging (Mixpanel, GA, Kissmetrics) in the view layer and add callbacks to their forms etc. to fire a “signup” event or such. It’s a Javascript API so why not do it all in JS right?
Well maybe but I’ve seen some people have problems with that approach and waste lots of time fiddling around to ensure that it played well with a Javascript-submitted from and didn’t block anything.
I also felt that it didn’t quite feel right to have the “signup” event fire on form submission since the submission of the form is no guarantee that it validated or that the user completed the signup process.
My preferred approach - server-triggered, client-logged
The logic for whether the signup event happened really exists in the controller (possibly even in the model but that proved to be too much hassle). I therefore wanted to fire my Mixpanel event after the controller signed someone up i.e.
class UsersController < ApplicationController
…
def create
@user = User.new(params[:user])
if @user.save
flash[:notice] = ‘User was successfully created.’
mixpanel_track( ‘Signup’, {mp_note: ‘signed up’} )
end
respond_with @user
end
end
The beauty of this approach is that regardless of how you implement your forms, you know (as you’ll see in a minute) that the event is going to be tracked. You can also track it whether you’re responding_with JSON or HTML.
However, although I wanted to trigger events serverside I didn’t want it to be fired serverside. Serverside calls would have involved setting up messaging queues and a load of unnecessary server-load. What I wanted to do was stage the event logging on the server but then let the client deal with firing it off to Mixpanel.
Log the event on the server but then write it back into the page
Summary:
Code
In order to do this I created a few methods in my application controller that mirrored the mixpanel javascript methods. These methods take the event, translate it into javascript and then queue it to be written back into the page:
class ApplicationController < ActionController::Base
…
private
def mixpanel_track(*args)
json_array = args.to_json.strip
json_args = json_array.slice(1, json_array.length-2)
(session[:mixpanel_events] ||= “”) « “mixpanel.track( #{json_args} );”
end
end
I can call this method using regular ruby arguments:
mixpanel_track( ‘Signup’, {mp_note: ‘signed up’} )
The method then just splats the arguments and translate them to a json array which looks something like this:
”["Signup",{"mp_note":"signed up"}]”
It strips the array braces off either end (the slice line) and sticks the arguments into the appropriate mixpanel event:
“mixpanel.track( #{json_args} );”
(which expanded looks like:)
“mixpanel.track( "Signup",{"mp_note":"signed up"} );”
This whole string is then stored in the session ready for the view to pull it out.
Application.html.erb
All the application view then has to do is pull the events into the next page load and clear the session variable:
<html>
<head>
…
<script>
<%= session.delete :mixpanel_events %>
</script>
</head>
</html>
Et voila. Nice reliable events that fire regardless of how you setup your forms.You can easily pull these events off the session and stick just them into a JSON response too.
It goes without saying that this approach isn’t limited to Mixpanel - it’s a nice way to log events for whatever your system is, GA, Kissmetrics or anything else. You’ve got fewer points to debug and less code for your event.
I wrote article yesterday explaining the technique that Homakov used to Hack GitHub this weekend.
Unfortunately (especially given its subsequent traffic) I couldn’t write it here as I haven’t yet figured out how to get Tumblr to format code so it’s a Gist instead:
Enjoy.
Being as I am in the business of social software I find myself increasingly in the position of having to pitch it.
I quite like pitching things, I’m used to it and I can now avoid most of the mistakes. I especially like it when someone gets it and starts to riff with me about it. Most people are just interested to hear about something new and if they find it compelling they usually end up infected by my enthusiasm and leave the birds singing a little louder and the sun glowing a little warmer.
There are some people though for whom a business pitch has the same effect as a burp in the face.
Very occasionally I will answer someone’s question as to what my startup is and the dinner party immediately becomes what negotiators might refer to as a hostile situation.
You can usually tell when things are going critical as, instead of smiling inquisitively as you they listen to you, your acquaintance instead cocks their head. Often they’ll put their fork down. Were in film you would probably find your words soundtracked by the mournful, song of a distant arab minstrel.
About a minute after I realise I’ve left the green zone and the questions started thudding into me things slow down and a little voice in my head and a voice asks:
- Peter, what did you just say to that guy. Why’s he pointing at you like so closely?
- I gave him the pitch
- So why’s he so cross? Are your sure you didn’t accidentally pee on his shoes?
- Nope - just told him the story
- Did you park on his kid?
- Dude I honestly don’t know - it has this effect on some people.
There is apparently nothing you could say to them, no way you could slander their sister that would make them more angry or intent on convincing you that your hubristic optimism can only result in a particularly hot and impoverished corner of deadpool hell.
Just as you think you’re getting a handle on the situation though you inadvertently mention the “S” word. Now it really kicks off. News of an Israeli IVF programme could outrage Hitler only marginally more than than the discovery of a new social startup does your dinner companion.
I’m basically on board with the cynicism. Social software is a dangerous space with its soft and fickle ad revenues. In my old age I’ve moved resolutely on to the hard stuff - whisky and recurring revenues. A man’s diet. That said, like two victimised cross dressing cage fighters out on the sauce in Swansea it’s fun to let them do their thing for a bit before you pull the ripcord.
The problem is that although conversations about early-stage product are basically unsubstantiated hypothesis, some people insist on taking a hard line. You might as well be discussing whether Jason Bourne or James Bond would win in a fight. A good conversation piece but a bit irritating if you happen to be Damon or Craig (unless of course you win in which case it’s a great conversation).
So here’s my advice for whiling away the grilling. As you start to mentally run your fingers through the corn wondering what this guy did to your wife and children back home, try and distract yourself with by thinking about how you’d pitch the websites you use instead.
Here are mine:
LinkedIn - I wanted the 500-connections badge.
Facebook - when I have nothing better to do I go on there to see whether I have a notification and try to avoid stories about people’s children. Occasionally I upload a picture to give people a break from stories of people’s children
Pinterest - Anybody here?
News.YC - enlightened procrastination
Reddit - funny procrastination
Twitter - More procrastination per 160 characters than other sources of procrastination
Buoyed by this self-analysis I’ve now honed my startup pitch to a pithy three words that gets way out ahead of my angry dinner companion leaving them wondering who to shout at:
Pingpanel: Q&A based procrastination. Now for your questions.
Four years ago I upped sticks and left London to join YCombinator. My goals were clear - build a company, get to San Francisco (Summer YC was in Boston back then) and build big.
(originally published in yourhiddenpotential.co.uk/magazine/)
If the plan sounds little hazy, it’s lost nothing in the retelling. While it was clear I was going to build something big, what big entailed was less clear and things got hazier still when it came to stacking up the ol’ revenues.
Pfft. Back then Eric Reis was but a twinkle in Steve Blank’s eye and planning was as popular as ham at Hanukkah. Revenue was filed under nice-to-have and the big story was everything so I kept my eyes firmly on the one ball I could play with, San Francisco.
Two years later and I’d sold my company, was spending winters skiing in Tahoe, summers weekending in Mexico, and the rest of the time hanging out with some of the smartest people I’ve ever met. It was a small sale and I made it by the skin of my teeth but I survived and tumbled out the end a little older and a lot wiser.
So, in retrospect, is San Francisco all it’s cracked up to be? Well, unsurprisingly I vote yes. But the reasons are a bit more subtle than you’d probably guess and you don’t need to stay there forever to see the majority of the value.
At its core, what’s special about San Francisco and YC in particular are the people. San Francisco is an academy, a place where you learn the tools of your trade; where you observe and internalise mental models of how our industry works. Most importantly it’s are place where you meet your peers. If we were actors that place would be drama school, if we were doctors it would be hospital, as web entrepreneurs it’s San Francisco and for young startups, YC is ground zero.
We assume that the San Francisco effect comes from how it makes us better. I think the truth is that it’s less about how it makes us brilliant and more about how it erodes that which makes us bad.
Most of what you learn in San Francisco is common sense and patterns that worked for others; survival traits. It may sharpen the tools but like the proverbial bad workman they’re not the real problem. The real problem in this industry (probably in most industries) is that we start out as numpties and need a few old hands to show us the ropes.
Being an entrepreneur means a lot of decision making. What features should you put into your product, what languages should you build it in, how will you test it, when will you release it, how will you measure its impact, who should you recruit to build it, when should you recruit them, how much should you pay them, how much should you raise, when should you raise, who should you raise from?
That is a lot of decisions. It’s a lot of decisions you’ve never made before and probably no-one you know has made before. I’ve met a few people with an ability to make these decisions calmly and effectively but for the rest of us they are kind of frightening. Frightening and in the extreme, petrifying. That’s bad. If your job is making decisions the last thing you need is to turn to stone.
San Francisco is filled with people who’ve made these decisions before and YC is increasingly filled with many of the best of them. SF is a town where you can discuss these decisions in bars, in restaurants, at parties. It lets you model process at a higher and more manageable level; not in terms of solutions but in terms of people. Who’s been through this before, which one of those people do I most closely identify with and what would they do if they were me.
I’ve been back in London for the last year now and it’s changed a lot since I’ve been away. It’s a very different place to be and a much, much better place to be. There are more people in startups and there are good people in startups. Most importantly there are more engineers in startups. It’s a pleasure to be around those people.
I will go back to San Francisco but this time it’s a choice not a need. I’ll be going back because I love the town and while it’ll undoubtedly accelerate my new company, Pingpanel it won’t be the same make or break it was last time. San Francisco is a blast and YC is better still. Go there if you can. Stay there if you will and either way make the most of it it’s great.
This article was originally published in Your Hidden Potential Magazine: yourhiddenpotential.co.uk/magazine/. Go there to read some other great interviews with British entrepreneurs.
A friend was telling me yesterday how she’d been slogging through a book she hated for months because even more than hating the book she hated giving up on books. I used to hate giving up on books too. Right up until I read Atlas Shrugged.
Atlas Shrugged is not a bad book. It’s a brilliant book. But it’s also a very, very long book. I enjoyed the first 800 pages and even Galt’s 70 page long monologue introducing his capitalist utopia. Three years in the States also taught me that it’s the one piece of American Literature you become most self conscious of not having read (or even heard about) so it’s a good one to get under the belt.
It requires a big belt though and it’s not too long before the repeating themes of communism and Rand’s predilection for rough sex with heartthrob, headstrong, heartless industrialists starts rattling as monotonously as the tracks underneath the Taggard Transcontinental.
Two or three months in it occurred to me that I was missing other books as a result of reading this one. That in turn made me wonder how significant that was - how many books one can read in a lifetime?
I’m 32 now so I’ve optimistically got another 50 years left. I read about a book a month so that’s 600 books. I’ve got 600 books I can read in my life. That’s not a theoretical BBC top-list that’s fact.
That’s not many and fewer still when you consider that the physics of books is basically the same as the physics of rockets - you want to burn as many as possible as early as possible since their effect on you is an integral over time. Read a book in your dying year and you only get 6 months of effective wisdom. Read it in your 21st and you get 720.
So next time you’re shrugging off Shantaram or flitting past the Fountainhead don’t feel too bad and remember that by putting one slow book to bed you’re granting life to another three great ones.
I had a little surprise this month when my Heroku bill came and was $26 more than expected. No big deal and I don’t begrudge Heroku any of the relatively small amount I pay them. That said I still wanted to know where the extras were going.
On inspection it turned out that the rails console has been soaking up hours and hours of time and that it runs on a separate billable process.
After enquiring I had an email back from Heroku support saying that this is something they’ve been actively working to sort out but in the meantime there are two things to make sure you don’t pay for more than expected:
There’s been a recent spate of people asking me how they can learn to program. Most are potential founders who understand that attracting a technical mate means making themselves technically shaggable. Most are just folks people realising there’s a huge technical aspect to the world around them and that knowing how to code will better equip them to interact with that.
Whatever prompts them, the thing that unites them is that they all want to build stuff.
When guys say they want to learn how to dance they mean they want to meet girls.* When people say they want to learn to code, they mean they want to build stuff. They might possibly want to know about object inheritance, data typing and polymorphism just as boys might want to learn the footwork for a featherstep. They probably don’t though.
Which is why right after I tell them to go to codeacademy I pause and wonder, what will they do next? What can I tell them to use to get up and running with something that won’t need more than one of git, databases, ftp or html?
The problem is that that even with codeacademy, the step from “I know how to code” to “I have something real” is still huge. I can’t think of any deployment stack that doesn’t demand a load of domain specific knowledge.** Simply displaying a form submission back to the same user takes some understanding of how a web session works, HTML and some server scripting. And the hell wants to display a form back to a user anyway?
Google App Engine and Heroku are great but while they accelerate development they’re not designed for learning.
Terminal > cd app_directory > git init > rails generate > git add . > git commit -am “first commit” > heroku create “myapp” > git push heroku. It’s amazing but it’s still a lot of places for a newbie to go wrong.
I don’t think Hello World is enough either. “Hello World” might be the first line but “Hello Facebook” should be the second.
Part of the challenge for newbies is, ironically, that they have to build first. Much more gratifying then building is breaking. The challenge when you build first is that you usually get it wrong which is frustrating.
Much better to start with something that works then tweak it. See where the parts hinge, whether it survives a long drop and how to strip it down and boost the power. People dream of building their own house but they kick off by cocking up a bit of DIY.
The stack should also have simple, powerful bolt-ons. People want to publish to Facebook, they want a component to send an SMS, one to add a mobile interface to the app, one to send emails, to take payments through Stripe. Each of these should be simple to add but also allow the technically astute to unscrew the covers and customise.
I think it’s important that whole thing is built off a real-world production architecture. It should be layered over Rails, Django or iOS. As you unscrew the last safety cover you should be hit by the smell of hot oil and gaze upon shiny, racing-grade engine parts. You need to know you’re committing to the real deal.
Codeacademy and Treehouse are both great but they don’t leave you with a humming machine.
Ideas are easy but execution is hard. AppJet tried something similar to this and found it very tough going. Was theirs a product failure or a market failure? It’s hard to tell but the success of Treehouse and CodeAcademy suggests it was product. While the technological innovations in Appjet were deep and brilliant, it still didn’t make it easy enough to make a sexy web app come to life.
GoDaddy makes hundreds of millions of dollars a year from online dreamers, it’s not hard to imagine that 5% of those might convert into hobbyist builders.
Rails is big and popular however when Heroku was acquired for a quarter of a billion dollars they were only publicising 100,000 apps built on Heroku. With a platform that’s as easy to setup on as theirs, I would guess they had about 1,500 paying apps and about $190k/month in revenue (I have no inside information but this seems sensible).
$2M/year is nothing to sneeze at but as valuable an acquisition as it was, Heroku was probably not acquired for its revenues.
Heroku made money through people graduating to professional levels. The challenge with a project like this (and possibly Heroku during its early days) is that it’s a hobbyist platform.
Almost nobody on the platform will build something that they can justify purchasing on a business basis. However just like people pay money to gear-up in CityVille so, if done right, people will buy pay money to gear-up in CoderVille.
With an element of competition, glossy, premium priced bolt-ons and a feeling of community the app needs to kindle desire. People are prepared to pay for hobbies and games, this should become the grown man’s train set or Tamagotchi. The second the app invites someone to rationalise their expenditure in terms of hosting it’s screwed.
The app could in fact modelled as “CoderVille” or “SimWebsite” - a game revolving around a set of websites each interacting and each of which you have to tweak to up their visitors and revenues. Generate really high scores by building your own site from scratch with help from game hints. Make the game social by allowing your traffic to be influenced by the sites designed by your competitors.
It’s easy to get carried away thinking through details but what’s hard to avoid is that we’re definitely missing something. All of us have friends who are hungry to create something, bored in their jobs and who keep sniffing at the edges of ours. Give them the right platform and they’ll eat it up.
I hope whomever builds it does focus on revenue . It’s going to take a good team and some real investment and if it’s not done right we probably won’t see much more investment in the space. If it does though we’ll get lots more programmers and I for one welcome our new amateur overlords.
* This is not always true. Sometimes they want to meet boys
** App Script in Google spreadsheets gets pretty close to this but doesn’t address the issue that people want a website not a spreadsheet
