Dan Hill

From a few conversations recently with fellow startups and with people thinking of becoming founders and starting their own company, I occasionally get the feeling people see the whole lean (Lean) movement in different ways. They get that the ways of yore - months planning, months building, big budgets, no real data - lead to products no-one wants, huge amounts of waste and all-round frustration.

But the interesting part is the different things people see as the antidote. For me, and most of my contemporaries, Eric Ries’s articulation of the Lean Startup is currently the most resonant. It makes sense, it works: we’re both more productive and more usefully productive.

That said, the Lean Startup is only an intellectual framework, much like a theory in physics or a historical narrative. In time people will come to disprove it, adapt it, disgard it, improve it, and so on. We look back on generations that thought the world was flat and laugh, but it worked for them. It’s up to us to use the tools in the most effective way.

The misconception I want to talk about here is this: I meet people who seem to think that being lean means only thinking as far ahead as the next release/iteration/pivot. After all, once you’ve got the next release and hypothesis test out today/tomorrow/next week, you’ll know what to do next. No point second guessing, we might be proved wrong and have to change everything anyway. (Oh, and there’s the vison way over there)

This feels a little intellectually lazy. As long as we keep shipping, keep testing, we’ll work it out.

Sure. But at some point you have to actually work it out.

I prefer to think of it like a game of chess:

• The billion dollar exit/fame and glory/world changed is checkmate. Everyone knows how that works.
• The opponent is real life. The markets, your customers, your competitors, opportunities, tech, hiring, firing, funding, boards, screw ups, etc.
• Each takes a turn to move. You either win, or you fail.

The basic similarities are obvious: you’ve got to understand how the different pieces move before you can play; almost no-one wins their first game of chess; there are set openings, tactics, moves that can increase your chances of winning; sometimes you’ve got to do something unpredictable.

In the old school startup we’d try and plan the whole game out all the way to checkmate along one execution, then play it regardless of what the opposition (life) did. This rarely worked (though there are exceptions of course), as life could quite easily play round that. Very quickly every move you make is nonsense.

The answer isn’t to play one move at a time. 

A grandmaster wins because she can see the next 20 moves that could happen, the most likely responses from the opponent, the particular line of attack.

A chess computer wins because it can predict every possible combination of moves all the way to checkmate, the probability of success or failure of every one, and after every move it can recalculate the whole thing.

It’s impossible to be the computer, but it’s possible to be the grandmaster. You’ve always got to make a move, and for me being lean (Lean) is about always being able to make a move, and respond (with understanding) to what your opponent (life) plays next.

But you’re still thinking about the 7 moves ahead, the 20 moves ahead, the direction towards checkmate. When the opponent next plays, you’re not surprised and thinking again from zero - it’s just one of the many plays you’ve gamed out. Of course, in any good game of chess there will be those moves that force you to throw everything out the window, but they shouldn’t be every move your opponent plays.

Getting traction is a successful opening, getting some control over the board. Particularly in the early game you’ve got to respond, often drastically, to a change in play by your opponent. Customers don’t want it, they like some things but not others, they don’t understand it etc.  But you know you’re playing a thought out opening, you can see the bigger picture - the aim is to get to control of the board as quickly as possible, testing the opponent, pushing them, thinking further ahead than they are. You’ve got to be willing to throw away a few pawns if needed, to move a knight or a rook boldly. But no move is random, it’s all part of the longer opening - you’re always thinking 10 moves ahead, even if moves 3-10 of those keep changing.

Getting funding is sacrificing a bishop. If you’re already losing it’s not a sacrifice, it’s being beaten. But if you have control over the board, and you’re thinking twenty moves ahead, you can game it out. Maybe your opponent (life) will take it with this piece, maybe that one, but once they do you’re in a stronger position as you swoop in with your queen onto their back rank. Once you sacrifice your bishop though, you can’t ask for it back - that’s why you’ve got to be thinking many moves ahead.

By the time you’re in the end game - are we being acquired, are we IPOing, are we merging, or any of the other wins - you know your opponent, how they play, how they think. You’ve got to be thinking 50 moves ahead. Once you pick a strategy they’ll know what you’re doing and be able to guess how you’re going to do it; it’s harder to pull back from.

So, it’s not a case of planning and executing 20 moves ahead. In the early game you’ll constantly be rethinking the potential later moves, potential responses by your opponent, and in the middle game maybe you’ll be playing 5 moves straight and thinking 50 ahead. 

But as a friend recently said, thinking costs nothing in comparison to doing.

So in summary, I don’t believe being lean is the same as playing everything one move at a time and waiting to see what happens. As Ries says, if you want something to happen you’ll be proved right, it always will. Instead, it’s like chess, you play efficiently by making small (or big) moves that react to your opponent, understanding them, finding their weaknesses, and you win by playing 20 moves ahead. 

At Crashpadder, we’ve been working on a marketplace for accommodation for a few years now, and I recently shared some of the little nuances at #foundersexchange that I’d come across during that time. Some seem obvious with hindsight but took a while for me to really understand, and some took us by surprise. Hopefully they’ll be useful thoughts for anyone thinking of, or already working in, a marketplace business.

Some basics.

Whilst others may have articulated this elsewhere, I’ve found there are essentially two distinct types of marketplace: ‘local’ and ‘non-local’. In a local marketplace, the supply and demand are necessarily both consumed within the same geography (city, town, neighbourhood); examples include TaskRabbit - the people doing the tasks live near those needing tasks done, Ecomodo - people borrow tools etc. off people near them; Kinderfee - people book a sitter who lives near them. Non-local marketplaces are the opposite; examples include Crashpadder/Airbnb - people use the service because they need accommodation elsewhere; Gidsy - people book because they don’t know the area. Some marketplaces operate irrespective of course: eBay - people either post or collect; MinuteBox - the value transfer takes place entirely online.

The distinction is important. The ways you seed, grow and expand each is different. At Crashpadder we must seed a new geography in a highly localised way (London, say), and then get demand from everywhere/anywhere BUT London. Conversely, TaskRabbit would want to target both sides of the marketplace in a highly dense geography. 

Next, you need availability & liquidity in your marketplace. This is the hard bit, especially early on in a market. We need available hosts that can be booked, and guests that are making bookings. The experience of a user, be they supply or demand, is only partly a function of your service; most of the experience is determined by the right volume of their opposite.

The key therefore to understand in your business is that your job is only to facilitate value transfer, not create the value. You charge money for this service. The more value you transfer, the more money you make.

So, understand the product you sell. eBay doesn’t sell second-hand goods, TaskRabbit doesn’t sell tasks and we don’t sell rooms. We sell trust. Our hosts sell rooms.

Chickens and eggs.

Do I need a chicken or an egg? Should we get supply first, or demand. The answer is both. Success is being able to ramp up both sides proportionally. We’ve found it best to start in one geography and achieve scalable liquidity then rinse and repeat. Two techniques we’ve found powerful:

A time critical event - find a reason why both sides of your marketplace are going to have to come together at the same point, giving you that initial liquidity. For example, the Olympics or Edinburgh Festival are great for us, as both sides concentrate their expectations and usage around the same window.

An existing strong network, a niche - the trick here is to find a group of users on both sides who are willing to put the extra effort and time into waiting for full liquidity. For eBay, this might be stamp collectors - they’re willing to come back and try again until they get that one perfect stamp. Someone buying a HiFi would simply go somewhere else that does have liquidity (a high-street store).

Types of value

Another important distinction between types of marketplace is between the types of value being sold: lasting vs one-time inventory. Lasting inventory you can reuse multiple times per listing, for example our rooms can be booked multiple times ad infinitum, baring unavailable periods. One-time inventory, for example goods on eBay, and only be consumed once, then you need to go back to square one and get more inventory. I think a large part of the success of the P2P accommodation model is due to the high value-to-supplier ratio compared with one-time inventory models.

Marketplace Half-life

This is something we began modelling a while ago, and has proved very powerful in predicting future behaviour. 

The half-life of your (lasting) inventory is the time it takes for it to half in value. 

In our case, this is the time it takes for the likelihood of a new booking request to be accepted. If a host gets a booking every week (say), then they’re engaged, their availability is up-to-date, and we know we have a reliable method of contacting them. After a period of time, that same probability drops as they’ve not been engaged so not updated their availability, may have changed email address, may have gone elsewhere for bookings, and so on.

Understanding your half-life allows you to balance the distribution of new bookings/guests effectively between first time users and repeat users. Each host has their own sweet-spot for bookings (every week, two weekends a month, every two months etc.), but when you hit it they’re yours.

Competition and Virality

There’s an inherent competition on either side of a marketplace. Either hosts are competing to get the (best) guests, or guests are competing to book the (best) hosts. If you can manage the level of competition on either side, you can cause both side to up their game. If our hosts see they’re moving down search results (but are still roughly within 1/2 half-life cycles) they’ll look at the new features and options to get them back up: maybe more photos, better descriptions or tagging, updating their calendar etc. Guests to likewise - they’ll provide more useful information about themselves, respond to messages quickly etc.

But. The side that’s competing generally won’t go viral or want to share your product or platform. A host that’s feeling a bit of competition to get bookings won’t want to tell their friends (who live in the same area, right?) about your service because that will only increase the competition they’re already facing. If they’re making more money that they know what to do with, they will. (Or if they’re essentially happily saturated). 

You also don’t want competition on price. If you push competition on the supply side to far, you might end up with people cutting prices. At that point they’re probably done with your service anyway and your marketplace is essentially broken (there’s NO demand), but you also earn less money. If the supply side starts lowering prices, look hard at what’s going on.

Marketplaces are cool

We’ve been running a marketplace for 3 years now. We were one of the first into the P2P accommodation space, and it’s a brilliant model. The high network effect (Metcalfe’s law) makes switching expensive and thus your supply defensible. The more reviews a host has, the more reviews they get, and the bigger the drop from starting again elsewhere. And what’s really nice is building a business on existing, underused, value. We’re not building hotels, but selling shovels. We allow others to get more value from the world.

Any questions or comments do get involved below, or tweet me @serenestudios.

Take 5 minutes out of starting, pivoting, emailing, selling, analysing and see what also matters. This is stunning perfection.

At a recent Seedcamp day I was talking with a few teams about how to do a cohort analysis quickly and easily. We all know the value of actionable metrics above vanity metrics (thanks in part to Eric Ries’s new book), but getting them out is often a surprisingly difficult task, especially for a small team. At Crashpadder we do two kinds of cohort analysis - one is a custom built tool that runs off our database, and the other is a google analytics hack that I’ll show below.

The advantage of the database report is it’s accurate, it uses our more complex business logic and KPIs, and as we built it, it does exactly what we need. The downside is it’s not realtime/slowish (obvious N+1 issues with grouping data over and over), and needs to be run on our server (i.e. by me) - our new datalytics team member can’t just get stuck in. It’s not the kind of thing you do in a web request/live page, but we can run it once a day/week/month in a few minutes.

Google Analytics is great as everyone can access it from anywhere, we already use it for loads of tracking, and it has a relatively simple web interface. Downsides include accuracy and customisation. And did I mention accuracy?

So we use the database report for detailed analysis, and the Google Analytics hack to quickly spot trends, compare with other data, have data available on request, and so on. 

So if you want to get started with some cohort analysis at your cool new startup, but don’t want to slow down your lighting fast build-test-learn loop and MVP building in the early days, try this.

The hack

The essence of this is to push custom variables to GA, along with your normal page data, that describes the current user, and then create advanced segments in GA to limit what you’re seeing to these users. We push 5 bits of data to GA at crashapdder; these will obviously be different for every startup:

• Is the visitor currently logged in
• Are they a member of Crashpadder
• Are they a host or a guest
• The year they joined (for this cohort analysis)
• The month they joined (for this cohort analysis)

So here’s your normal GA code:

<script type="text/javascript" defer="defer">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXXX-1']);
  
  _gaq.push(['_setDomainName', 'www.mydomain.com']);
  _gaq.push(['_trackPageview']);
  _gaq.push(['_trackPageLoadTime']);
  
    
  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

We add to this our custom variables as below. You should be able to pull this out of your current user variable/model/object (we’re using Ruby/Rails); simplified a bit, our code looks like this:

<script type="text/javascript" defer="defer">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXXX-1']);
  
  _gaq.push(['_setDomainName', 'www.mydomain.com']);
  _gaq.push(['_trackPageview']);
  _gaq.push(['_trackPageLoadTime']);
  
  _gaq.push(['_setCustomVar', 1, 'Logged in', <%= current_user.blank? ? "'no'" : "'yes'" %>, 2]);
  _gaq.push(['_setCustomVar', 2, 'Member', <%= current_user.blank? ? "'no'" : "'yes'" %>, 1]);
  _gaq.push(['_setCustomVar', 3, 'Host/guest', <%= (current_user.blank? || current_user.is_a_host?) ? "'host'" : "'guest'" %>, 1]);
  _gaq.push(['_setCustomVar', 4, 'Join month', <%= current_user.blank? ? "'0'" : "'#{current_user.created_at.month}'" %>, 1]);
  _gaq.push(['_setCustomVar', 5, 'Join year', <%= current_user.blank? ? "'0'" : "'#{current_user.created_at.year}'" %>, 1]);
  
  
  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

This then renders in your browser something like this:

<script type="text/javascript" defer="defer">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXXX-1']);
  
  _gaq.push(['_setDomainName', 'www.mydomain.com']);
  _gaq.push(['_trackPageview']);
  _gaq.push(['_trackPageLoadTime']);
  
  _gaq.push(['_setCustomVar', 1, 'Logged in', 'yes', 2]);
  _gaq.push(['_setCustomVar', 2, 'Member', 'yes', 1]);
  _gaq.push(['_setCustomVar', 3, 'Host/guest', 'guest', 1]);
  _gaq.push(['_setCustomVar', 4, 'Join month', '8', 1]);
  _gaq.push(['_setCustomVar', 5, 'Join year', '2009', 1]);
  
  
  
  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

(A keen observer will notice that the first two seem to do the same thing - whether they’re a member or logged in. The number on the end of each line specifies the lifetime of the cookie GA uses to track the user. We set whether they’re logged in to that session only, and whether they’re a member to lifetime. So after the first login, we know if you’re a member again, even if you don’t login the second time.)

Google Analytics

Now head over to your GA account, and click ‘Advanced Segments’. Under ‘custom segments’, click ‘New Custom Segment’.

Give this segment a title, say ‘November 2011 signups’

Drop down the variable type (default is usually ‘Ad Content’), and select the corresponding ‘Custom Variable (Value XX)’ for the join year. So in this case, Value 04 is our join month, and Value 05 is our join year.

Note: you need to choose the value rather than the key - in the above example, the key is ‘join month’ or ‘join year’, and the value is 2008/2009, 1-12 etc.

In the ‘containing’ box, enter the year you’re grouping by (here 2011). Click the ‘Add AND statement’ link, and repeat with the month, this time choosing the Value 04 and the month number, here 11. This is creating a segment that isolates everyone who joined in year=2011 and month=11.

Save the segment, and you’re now looking at your data only for people who joined in November 2011.

We create a new one every month for the incoming users, and can quickly filter all data by a particular cohort, or compare two cohorts with one another.

If you jump over to your goal tracking, you can start to see which cohort is converting better, what their profile looks like in the months after they joined, estimate their lifetime value, value half-life and so on.

Feel free to leave comments below!

alexanderljung:

Agree! (Taken with Instagram at Readmill HQ)

kcmr:

(via xkcd: Sandwich)

A quick guide to installing Ruby Enterprise Edition, Rails, etc. on Mac OS X Lion. The main problem is that the latest XCode (4.2) ships with a messed up version of gcc. So:

1. Install XCode 4.2 from the App Store.

2. That actually places an App in Applications called ‘Install XCode’. Run that.

3. Install OSX GCC from here: https://github.com/kennethreitz/osx-gcc-installer This is a much better version of gcc, plus associated libs.

4. Install RVM:

bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

5. Install REE:

sudo CC=/usr/bin/gcc-4.2 rvm install ree

6. Use REE:

rvmsudo rvm use ree --default

7. (Optional) Install brew:

ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

8. Rails, etc.

rvmsudo gem install rails

That’s it! Leave a comment if you have any better advice, or questions.

A very good analogy of what a startup often feels like…

alexanderljung:

2 thoughts on our partnership with Facebook announced today

nateberkopec:

NASA problems require many years and massive teams to solve. It took us over 10 years and 109 manned missions to gain enough knowledge and experience to send a man to the moon. That’s a lot of work.

Making a rocket of out LEGOs, comparatively, is trivial. Even if it’s a really big one - like 5…

crashpadderhq:

Who are your favourite travel buddies? Post a photo on our Facebook wall with your favourite travel buddy/buddies tagged for a chance to win a free weekend with any Crashpadder host around the world! (£100 max)

After you post your photo, you will have until Friday to beg, steal, or borrow (just kidding, begging is the only option!) the most ‘likes’ on your photo. The earlier you post, the more time you’ll have to collect ‘likes’. The photo with the most ‘likes’ will be the winner!

Competition begins: NOW! (01/08/11)

Competition ends: This Friday at noon (05/08/11)

Post your Photo Now 

Rules:

• One photo per person
• The count ends 05/08/11 at noon - any ‘likes’ after that will not be counted.
• £100 must go to accommodation with a Crashpadder pad of choice by (01/08/12) 
• The £100 is allowed to go towards the accommodation for you and a friend.

elezea:

There’s a good article on Design Mind in response to a recent Seth Godin post about technology and magic. Here’s the part that stood out for me:

To me that’s all we’re really talking about, and core to Godin’s point (whether it was intended or not) is that stuff doesn’t wow us anymore,…

nickclegglookingsad:

Nick Clegg wishes you wouldn’t keep taking his stuff, and then when he comes to get it back, throwing it to someone else so he can’t have it back.

@aws fail. @bt fail. @nakedwines win. At least something is working today.

An excellent list of things to do when it all goes wrong. This morning Amazon EC2/RDS in the US-EAST area went to crap. Crashpadder is down (bummer), and so is Quora, Reddit and Foursquare. I’d add a few to the list:

• Your users don’t know what any of it means. Get your comms team with a simple clear message of what’s going on, and how it affects the most important things for your users. (In our case, their pending bookings and response-rates).

• Get in your helicopter. From up in the air, it’s rarely as bad as it seems. It’ll be over in a few hours (touch wood), and you’ll learn the lessons needed.

• Record what you do. You’ll be hacking a few things, trying to get things back and working. When you come to the blissful nirvana of the coffee-fuelled system restore, you need to know exactly what you’ve changed, and think about what else is affected.

Any one else got any tips to share?

bcardarella:

Rails 3.1 will have password encryption baked in via ActiveModel::SecurePassword. Any ActiveModel based model will get this functionality. (ActiveRecord, Mongoid)

Your model will need a field called password_digest and then you’ll need to activate secure password:

class User <...

Had an exceptional dinner last night at Marcus Wareing’s new restaurant, The Gilbert Scott. It doesn’t open till the 5th May, but the Crashpadder team managed to get a sneak preview (and all food for £10 - absolute steal). The menu was excellent, with a good number of more unusual and interesting choices (pigeon, earl-grey ice cream, etc), and a great looking wine list.

Oh, and I also bumped into Fabio Capello…

And the food to go with it. After a tremendous @seedcamp, good to be home. Even if 5am flight to Crashpadder in Edinburgh tomorrow…

Surprisingly good from sainsburys. Not quite the quality of wine from @thewinetastingshop,but very drinkable.