Skills you need to get product/market fit, all in a line

When delivering a new product or service under conditions of extreme uncertainty, you need a range of skills.

To help understand what skills are needed in a startup team, I’ve found it useful to think of people’s skills as being spread out along this line.

Line of startup skillsConsider people you know, and place them on the line. e.g. A UX designer who can also code Javascript is maybe somewhere towards the technical end of product.

1. Technical

This is someone who understands the substance the product is made of in great detail, and can work it to do what is needed. So for software, a computer geek.

2. Product

Deciding what the product should do, by both understanding what is possible with the technology, and what is needed by users. A product manager.

3. Market

Classifying who customers are, what inspires them, how to find them. Using whatever methods to help bring them to the product they want. A marketeer.

4. Sales

Filling that last gap between a product and its users. Cold calls, hustles, pesters. Whatever it takes to bridge two organizations. A salesperson.

Product/market fit boundary

Some lucky (skilful!) people sit right in the middle. They have a balance of product-side and market-side skills, and as a result often seem preternaturally good at crafting organizations.

You can train yourself to get nearer to that place – sales people can learn more product design, geeks can learn about marketing. And of course, you can join forces with people with complementary skills.

Why put all this on a line?

Two main reasons.

1. People’s skills are more likely to be near some point on the line. It’s common to find technical people with some product skills, rare for them to have full on sales skills. It’s helpful in terms of spotting balance – if your technical person is very extreme, it might help to have a product person who is over towards the market side.

2. There are analogies (homomorphisms, if you know your maths) between the roles, as if the product/market fit boundary were an Alice in Wonderland mirror.

Alice's mirror

  • Hacker (doing all to make tech work) is the mirror of Hustler (doing all to make a deal work)
  • Developers claim they have time to code everything, Salesmen claim they have time to sell to everyone
  • Geeks tell you too much about particular tech, Salesmen tell you too much about particular deals
  • Making (what product people do) in the mirror is Meaning (what marketing people do)

(I suspect these homomorphisms are quite deep, see my post on product and market being the same thing for a taste of why that might be)

I’ve found such analogies help me understand both the vital importance, and the weaknesses, of those different from me. It emphasises that to create a viable new product or service, you need all four skills working in unison.

In a world where a key limiting factor in the creation of new businesses is a lack of social ties between product-side and market-side people, it’s a start.

How we used email as a customer support system at mySociety


You’ve seen it. The red eyes… An ennui for life…

The drained sadness of someone who has been lost for weeks in a customer support ticket tracking system.

At mySociety (the awesome Internet democracy charity I was on the founding team of) we tried using Request Tracker for a while, and quickly fled.

We could flee, because we had the comfort of a simple email based system to return to.

It worked like this:

a) All support or feedback email comes in to a particular address (we used team@ – for example for the site TheyWorkForYou)

b) That address is set up as an alias (like a group in Google Apps) to transparently forward mail to everyone working on that product.

c) Everyone filters their email, so those support emails all go into a special support folder.

d) When replying to customers, always use reply to all. This is so replies go into everyone else’s support folder, both so they have a record, and so they know the customer has been replied to.

e) When either you or someone else have fully dealt with a mail or a thread, archive it. Otherwise, leave it in the support folder.

f) Be really disciplined about this. Anything in the support folder represents a customer who isn’t satisified.

g) Make sure at least one person on the team goes and looks at slightly older, harder messages, and bullies appropriate people into resolving them one way or the other.

This particularly works well early on in a product, when there is relatively little support. It’s particularly important then that everyone working on the product lives and breathes the customers. Even just seeing the emails go past with other people answering them can help with that.

I’ve used it to manage support for probably a dozen web products in total. It’s surprisingly robust…

It worked well (and still does as far as I know!) with half a dozen volunteers on WhatDoTheyKnow. It worked fine even when we were launching the Downing Street petitions system, with millions of users and front page newspaper stories (Matthew had many long sessions of email answering – and that’s a good thing!). We’ve just been looking at customer support systems for ScraperWiki, the startup that I run.

The main products (like ZenDesk) seem to be aimed, both in price and functionality, at larger, more corporate organisations than we are. They look overly complicated, we really only need something as featured as the Github Issues tracker.

I don’t know what we’ll move to using yet – that’s partly why I’m writing up a description of mySociety’s email based system.

It could perhaps be simplified by using a shared GMail account. Careful use of labels and folders would also make it more powerful.

It would need some training and discipline. Everyone handles their personal email differently. When it is customer support requests, it needs more discipline than just chilling out in the tao of a flow of passing messages.

This is natural to people who have the horrible habit of using email as a todo list, less so to anyone else.

Comments please! What questions do you have about the above system?

And can you recommend a lightweight customer support tracker?

How to use time-travelling anthropologist pollsters to tell good from evil marketing

SplinterMany British geeks (including me, once) have an instinctive distaste for marketing.

This is wrong – it lets the evil people get all the advantages of marketing. It hides really good and useful products and services from people.

Instead we need a morality to distinguish the good from the bad. The only definition that I’ve come across – and it’s custom designed for geeks – is as follows (this is courtesy of Julian Todd):

Imagine the universe splinters into two at the point you decide whether to carry out a (what will be successful in some way) marketing (or sales!) action. For simplicity, assume the marketing here targets a particular person to change their behaviour in some way.

A) You take the action, and somebody decides to buy your product (vote for your party, whatever)

B) You don’t take the action, and the person doesn’t buy your product (they buy another, they don’t vote, or whatever)

Then imagine you had a team of time travelling anthropologist pollsters. They would hop to universe A and to universe B. They go to the point where the target is on their death bed and do a sophisticated happiness survey of them.

Whichever universe they’re happiest in, indicates whether the marketing action was good or evil.

Do every marketing hack you can. As ruthlessly as you can. With that moral criteria.

Tudor time travel – Episode 1 of Crazy theories.txt

Kentwell Potter

Because I work in technology, people are often surprised that I spend 2 weeks a year living in the 16th Century.

The first episode of a new Podcast by Jonathan Deamer and I explains why.

What is Kentwell Hall? Were the Tudors a high technology society? What does it mean to be human? Why do both Jonathan and I have a long file of interesting subjects we never get round to blogging about?

All this and more in Episode 1 of Crazy theories.txt.

Crazy theories.txt – Episode 1 – MP3 (click on this one to listen!)
Crazy theories.txt – Feed to add to your podcatcher

BTW, it being Easter weekend, you can visit Festive Easter at Kentwell as a tourist, and see what all the fuss is about. It’s in easy day trip train range of London if you get up early, otherwise you’ll probably need to drive to Suffolk – there’s lots of other tourist things nearby too, if you want to make more than one day of it. It was a major centre of the wool trade, back in the day.

Kentwell Barn School

Links for this episode:

Awesome Foundation – Liverpool Chapter

There’s not enough awesomeness in the universe.

Don’t get me wrong, there’s quite a lot. But we could do with a bit more.

That’s why we’re lucky that Tim Hwang set up the Awesome Foundation a few years ago. It began in Boston, and has spread to dozens of cities.

How’s it work? 10 trustees pay $100 a month each to fund a $1000 prize. The prizes are awarded to things that 1) Have a purpose, 2) Are on a budget, 3) Create joy. Things like phones that can make calls without a base station, flooding a whole city with swings, or a stunning weather balloon to monitor the gulf oil spill. Things like that.

Watch Christina Xu explain…

A bunch of us are setting up a Liverpool chapter of this craziness.

Three things you can do to help…

1) Become a trustee. Email me if you’re interested. You need to have £50 a month (or so) disposable income, and be prepared to spend a fun evening helping pick which project gets the award. We’ve got four people so far, and I’ve just agreed to be one.

2) Have an idea! We’re not open for our first applications yet, but that shouldn’t stop you thinking. Again, get in touch with us if you have questions about whether an idea is suitable (hint: they all are! we’re very open to what kinds of projects Liverpool will create).

3) Tell your friends about us! Join Awesome Liverpool on Facebook, or follow Awesome Liverpool on Twitter and share the joy.

Awesome Liverpool


Four ways we’ll help WhipCar if they tell us what went wrong

Love they neighbour - drive their car
It’s as if your best friend had suddenly died and nobody would tell you how.

Heart attack? Car crash? Murder?

This time the afflicted isn’t a person, but a startup called WhipCar.

The idea of WhipCar… Rent your car out for the odd day or weekend to your neighbour to cover its vast cost. Or, if you don’t own a car, rent your neighbour’s car more cheaply and easily than a hire car.

It’s a genius idea, the Internet enabling us all to share our capital resources. The Economist had a whole piece just last week about that, including WhipCar.

There’s a meaningless statistic used a lot in Silicon Valley – 9 out of 10 startups fail. That said, for startups that haven’t reached product/market fit, it’s a statistic that often feels true. My world is littered with the corpses, or more often comatose bodies, of competitors/partners (it’s hard to tell the difference) that I once let myself get emotionally excited about.

(I’m not linking to them, because it isn’t always clear. My one consolatory love about how WhipCar is shutting down, is how clear they’re being about it)

So why are they in their death throws? This is what they say.

We have discovered there are still barriers to widespread adoption of peer-to-peer car rental in the UK

Meh! Barriers! I’ll see your barrier, and raise it one community desperate for new ideas like WhipCar to succeed.

There are four things that could have happened.

In each case, I’d love a little bit more from Vinay Gupta, the charismatic, amiable, tenacious founder of  WhipCar (don’t confuse him with the other Vinay Gupta, inventor of the Hexayurt).

Here’s how it would work:

1. Not enough customers, well tell us then! There’s no reason not to if you’re about to shut down the company. Open up your marketing figures for us all to see. Does one side of the market need a cultural change? Write it up! At the very least, anyone else planning a similar startup will have much better information to come up with a way through it. At best, somebody right now will work out how to help WhipCar get an initial viable market – with a Spread Firefox-like crowd marketing campaign, or a new demographic you never dreamed of.

2. Fundamentally not enough revenue for the business model to be viable… Again, open up your books! Why not, you’re about to destroy the company! Explain to your customers why there isn’t enough revenue. Perhaps you can increase prices with their support, or they can help with cost savings in a way you haven’t imagined. If not, at least it’s documented for business schools and future entrepreneurs what doesn’t work.

3. Lack of capital. Here I mean fundamentally lack of capital – growth and revenue figures which if you plot on a graph, end up with a viable business. It just has negative cash for a while. This is the most unbelievably easy one – open up all your books, and do a crowd funding round. If you don’t think one is legal in the UK, I know a lawyer who can help, or you can go to the US where crowdfunding is now legal.

4. Destroyed by other forces. Failure of execution, tell us so you can get the missing skills. Failure because competitors beat you, tell us so we know what future initiatives are up against. Failure by corruption, oh please please tell us please. Failure because of the law – we’ll run a campaign to fix the law.

All the above might sound a bit mad. Is it really the job of the customers of a company to help it exist?

Oh yes, oh yes it is. Bringing a new product to a new market is an incredibly difficult thing to do. WhipCar got really far – it managed to largely fix the insurance difficulty in its model, and had at least a reasonable number of paying customers.

There are lots of people who want WhipCar, or something like it, to succeed. It’s ideological. We want it to be easier to not have to own a car, and easier to share use of that carbon-intensive to make capital resource that is a car.

There are literally a zillion geeks who would help. We’re pretty worried about climate change. Why? I’m not sure, but I think it is because nerds are particularly able to read the reports with sufficient technical knowledge, combined with dispassion.

Please, a well written blog post from Vinay… Barely all I’d need to do would be to retweet it. Or if that didn’t work, go and tell the awesome community at Cleanweb UK what help was needed.

Let’s sort it out. Or if not, at least learn.

Why did we love the giants coming to town?

Taller than houses, the uncle passes the top of a street in Anfield, Liverpool

Earlier this year, giants came to Liverpool.

I was rapt. Addicted.

Each day I woke my girlfriend early. A morning taxi to see a giant diver wake up near two football stadiums. Forced rushing after a night’s drinking to see what a little giant girl would do next.

If you just saw the pictures, the videos, or caught a glimpse in the street passing you by… Then you’ll get part of the spectacle.

But what you won’t have sensed is the emotion.

For that it required obsession.

A man I met in the crowd had taken the day off on Friday, went to watch the uncle climb out the sea in the morning. He thought after following it past Moorfields he was going to take the train home. Instead he stayed, following the puppets solidly until I met him on Sunday.

Why? Why did we love it so much?

1. The spectacle. Played out on the stage of the city. Giants – sleeping in a dell on Everton brow, striding taller than terraced houses, sailing down destitute roads on a land boat, morning exercises in a shopping centre.

Caught in the sun, her serenity brings me to tears

2. The machinery. Men abseiling down to attach ropes to the head of a giant. Paired royal servants, queueing to jump off a ledge to get the force to lift a massive leg. Twenty earnest technicians manipulating controls and pulleys to play a vast puppet dog. Cleverly, the machinery was part of the play. A giant turns to look at a worker standing on his shoulder. The hoards of puppeteers were the real attendants to the giants, not hidden stage hands.

3. The characters. There’s a strange psychological trick about large people. Large with delicate features and a calm demeanour. They dominate and emotionally rend. I was surprised how much this mattered, and how well it worked.

4. The ritual. By the last day I was making flasks of tea, wearing water proofs, packing snacks. Ready to wait for an hour or two in the right place before the crowds, to get the best view. If it had carried on for a week I’d have probably had a rucksack, a tent, a small stove to cook appropriate meals. The event itself free – it was set on the public landscape of the whole city, so it had to be. Consumerism dissolved.

She falls asleep in his arms

5. The story. It was the simplest of stories, also ropey around the edges in its telling. Yet it caught me up, I cared. I was utterly convinced that as they left on the boat, he was going to look after her forever. My disbelief fully suspended.

Now it is all over. Months have passed. Life isn’t exactly ordinary, yet nor is it magical.

I’m left with the commemorative photo book In the Footsteps of Giants. I’m left with some albums by the “ambient post-rock” band Balayeurs du désert who accompanied the puppets.

And I know I’m lucky to have even them, in this world where all decays to death.

Mapping the product/market space – an hallucination

Imagine a vast multi-dimensional space.

Each point of it represents a specific need that a specific person has, an iota of utility.

The dimensions represent crazy things… Is the need in Africa or in Europe? Is the need on a LAN or on the web? Can travel to satisfaction of the need be done by public transport? How much does the need meet each of the basic needs? Is the need for shelter from the weather? Does satisfaction of the need require the skill of programming?

One night, someone persuades cartoonist Randall Monroe to take LSD so that he can draw a map – it’s a bit like this, only even for a rough map he has to paint it on the 26 dimensions of a bosonic string [1].

Bright spheres of product/markets swarm over the phase space.

Chain supermarkets hang in an oppressive morass, dominating one corner. The part of this representing best-selling novels scantily overlaps the impenetrable fortress to the north that is Internet book stores.

Extending from there to the south-by-south-west is where I’ve spent my working life hanging out. A bursting region, tearing the fabric of the space, loosely encompassing all those needs met by computers, by the Internet.

Little of it is very direct – it fires off in tendrils in the spin direction, which represents meta-needs, such as of a car factory needing a toolmaker needing a CAD software company to write some software to exactly position a metal drill [2].

Zooming in, zooming in, you find the dimension for needs met by the web, spanning the part for people who have credit cards (and are prepared to use them) and the part for people who want to share complex (yet free to reproduce) goods for free. It’s where ScraperWiki lurks. It looks a bit like this.

If you draw the boundary of a specific product, you’ll find it mainly covers a coherent lump of the space. It’ll have zaggy edges, wild spikes where someone uses it for something not quite intended – a tool intended to be used to track faults in software, instead used to track repairs needed to a house[3].

Consultants and salesmen work busily all over the map, stretching tendrils out from multiple products by hand, extending filaments from the bright areas into the dark.

By Jonathan Kos-ReadYou can see all three stages of innovation [4] bubble in the raw structure.

1) A bad idea for a product business pops into quantum reality and immediately gets sucked into the huge black hole of a nearby product that is very flexible. Elsewhere, someone spots a dimension nobody had considered clearly before, and finds a medium-sized dark spot nestling there. They have an idea that would fill it, but it’s too early, or they don’t have the time, passion or money in this life to light it.

2) Much later, a second person (maybe after talking in the pub to the sister of somebody who years previously read a tweet by the first person) has almost exactly but not quite the same idea. They make a prototype, and a brief glimmering star lights up in the darkness. For a few weeks it’s kindled, a concierge service lighting it by hand as a few of their friends try it out and find it useful. Or maybe they launch a product, but it doesn’t have the success they wanted. Too early, lack of time, of money, of passion, distraction by hedonism – whatever reason, not enough people buy it to make a viable enough business, and the fire is soon enough blown out.

3) Finally, a third person realises something important about the market of the new product idea and pushes it along the space to a fatter area. Anyway, time has passed and all the dimensions have reconfigured somewhat. Finally, a new glowing inferno burns in the gap.

A startup is by definition a hunt for one of those spaces, or a subspace within one, just the right size and place for the team, and the time.

[1] I can’t show it you – your browser doesn’t have the plugin.

[2] Randall briefly tries to sketch the supply chain lines on his map. The design of the original map was so tight, the reoriented mess now so incomprehensible, that he has to tear the whole thing up and start again.

[3] Someone else is keeping their DNA there.

[4] See the Myths of Innovation by Scott Berkun.

Heroku’s early history: 4 home pages that made $212 million

I decided to investigate Heroku’s early years.

You can learn a lot from even quite recent tech history (see my previous article on version control).

My tool? The Internet Archive. It’s an elephant that never forgets your pivots.

1. November 2007 – code in the cloud

Ruby on Rails is riding high. But impossibly hard to deploy.

Y Combinator startup Heroku’s first home page (see right – apologies for the lack of images, which has not recorded) screams onto the web.

It’s remarkable just how much it did from the get-go.

Not only did it solve the Rails deployment problem (“Instantly live!”), but you could also write the code in your browser for the first time (well, since Zope!) (“Create and Edit Online”), and share it with others (“Share and Collaborate”).

Really, hand on heart, until you read that last paragraph, did you remember that Heroku had an online code editor? And that was a major part of their initial value proposition? And what’s this about sharing?

Cleverly, they’d realised people will probably be worried about lock in (“Import & Export”). It’s not clear from later home pages that they really were.

No mention of scaling. No origami.

2. February 2008 – it’s a Rails platform

By February, Heroku had its debut on TechCrunch (including screenshot of their online IDE).

The home page (see later version of the same with images) talks more about deployment and scaling and git, with still a frisson of “coding in the browser”. Nothing about “sharing” any more.

It’s illuminating to read the comments on the TechCrunch post. As ever, full of nay sayers, from the ignorant …

Anyone who thinks Rails is difficult to configure doesn’t know what they are talking about. “Heroku = Fail”

(Rails was at the time very hard to configure on the server, I spent days struggling with hacks to cope with dieing and leaking Mongrel instances, at a time when mod_php just worked.)

… to the preternaturally informed, as you shall see:

Hosting isn’t trivial, but any solution that starts out “OK, give up your editor and terminal and version control and offline editing” seems pretty fishy for anything beyond the 15-minute blog demo.

3. February 2009 – fixed width becomes hip

A whole year passes until Heroku change their home page (see later version of the same with styling) again.

Several radical changes. For the first time ever (well, maybe since the early days of the web), actual code appears on the front page of a fashionable website. And not just Ruby or Python code, shell code.

My explanation for this suddenly being hip again, is the resurgence of the Mac around this time. OSX makes accessible to people who five years earlier would have used Windows and thought the command line was for dumb retrobates (sic).

What a home page! All shiny and black with a fixed width font, and $ signs. Wow.

Secondly the value proposition has simplified to three points. 1. Instant ruby deployment. 2. Git. 3. API. The latter two were merely mentioned in passing a year before, now they’re a key part of the value.

Github launched the previous April and at this point has 45,000 registered users and is on an exponential growth curve. Not too surprising that Heroku give git higher billing this year.

The most radical change is what is missing. Have you spotted it?

Tucked away at the bottom of the page is a tantalising link. “Heroku Garden Transition info“. WTF? A blog post “What’s up at Heroku” explains. They’ve completely rewritten it.

We also learned what our users want from a commercial version of the platform, and surprisingly to us, we discovered that there aren’t just a bunch of features we need to add, but some we need to remove as well (platform features often involve trade-offs).

Having made that discovery, we knew we needed to create a second version of the platform, to pursue exactly those requirements, designed from the ground up (with our hard earned knowledge) for commercial production use.

Features removed?

Indeed. No more online code editor. No more sharing. That’s all hived off to “Learn Rails, Work from Anywhere, Move to Heroku Later” is the value proposition of that new (erm, old) app nursery.

4. October 2009 – doubling down, adding on

In the autumn, it changes again (see later version, much the same with styling). Even more code, more clearly showing you that the commands are everything you need to get started. It’s the geekiest home page ever.

That said, there’s a much better split of the page; the value proposition for people who don’t speak /bin/sh is now laid out clearly on the right.

Again, the most important thing about this new home page is hidden away at the bottom (at least in the later 2010 version, it’s commented out in the HTML of the original 2009 version).

“Add-ons”. Despite throwing away features with their rewrite, an absolute corker of a big new feature appears. It’s how Heroku becomes effectively “an app store for systems administration”. But that’s another story.

This final home page holds them out well, lasting beyond the next December when Salesforce buys Heroku for $212 million. Cash.


If you love the origami, and are wondering when it appears, that is as late as June 2011.

And Heroku Garden?

In January 2010, just three months after its debut in October 2009, it’s axed. Poor thing.

I like to think that one of the founders of Heroku shed a tear. That they’d spent at least a year arguing until they were fit to explode just how important the online code editor was, how a “YouTube for web app sharing”, a “Google Docs for coding” was the next big thing.

And then watched the relentless figures, as everyone just used the deployment system, ignoring the editor, ignoring the sharing. Silly, it was the “app store for sysadmin” that won it.

For the record, I’ll wager that in 10 years time loads of people will be coding in the cloud. In their web browser, and using apps on their tablets. It seems crazy right now, but you’ll see. It seemed crazy 10 years ago that we’d all be using an online office suite.

Meanwhile, remember the lesson. Even the best don’t get everything right straight away.

Do several things well. Double down on the ones people like.


Products and markets are the same thing

At mySociety‘s annual retreat I gave a lightning talk about how I’ve come to realise that products and markets are the same thing. I’d originally intended it to be a blog post, so here you are.

It’s a story of geeks learning.

What is a product?

It really is magic.

Before the invention of products (whatever that means!) you had to make bespoke things. You want a tool, you have to bash the rocks together to make your own custom tool.

What’s magic about industrialisation, or copying computer software, is that you can design something once and lots of people benefit from it. The design, which is to say the finding of that commonality of use, becomes much more expensive.

Fred Brooks in the Mythical Man Month describes this for computer software.

A Program is the object an individual uses in estimating productivity, it is ready to run in the programmer’s environment.

The Product can be tested, repaired and extended by anybody, is usable in many environments for many sets of data. It is generalized and documented, and costs at least 3 times more than a Program for the same functionality.

Making good products

I wrote earlier in the year about how “geeks are now good at usability”. What I really mean is that there is now a reasonably strong culture of making quality products. Ones that are designed for purpose of the user rather than the creator. Ones that are cohesive and well made.

We’re in an exciting place right now – new IT products are changing the world in fundamental ways. It’s like the turbulent century after the invention of the printing press, the new rules aren’t clear yet.


What’s a market?

A market is the people who use a product. Or, to put it only slightly more indirectly, it is the route by which people come to know about and use a product. This is where the meaning of product and market blur.

Look at the Google search screen shot to the right (click to make it larger), for “complain about late train”. As you can see there is an advert “Bad train journey?” for the website FixMyTransport.

My question – is that Google search result part of the product or the market?

To a nerd who has just built FixMyTransport, it is clearly advertising. Part of the sales and marketing process, surely! In contrast, a general user on the Internet is barely aware that Google and FixMyTransport are separate things. They just know you type stuff into a box, it takes you to something that does what you need. For them, the Google search result is a vital part of the product – the first menu in the user interface for it.

So, for a specific product, a market is a specific set of people who use it. In its most extreme form it isn’t the list of people who could use it, but the list of people who do use it.

Are products and markets the same thing?

Like a hand and a glove, product and market mesh together. If you alter the product, its market automatically changes. You can design a product without thinking about its market, but to do so is merely ignorance. There is a market that you are making, you are just not thinking about what it is.

The marketing of a product is part of it. A Google search result is part of a user’s experience of FixMyStreet. The feel-good brand advertising of Coca Cola is vital to people enjoying its taste. Ubiquitous Apple stores both sell Macs and make it obvious where to get them fixed (“whole product”). The more you look at it, the harder it is to tell which is product and which is market.

It seems there is a line, just as there is a line between our brains and our skull. But it is a tightly fractal line, they fit together perfectly.

My analogies of gloves and skulls are a bit too glib. If you know about biology, a stronger analogy is perhaps one to genotypes and phenotypes. Our genes are analogous to the product. They express themselves, creating an organism. The product comes into existence, and naturally creates a market. Just as it is hard to predict what organism will come from the genes without running an experiment, it is hard to predict exactly what market a given product will create. You can research it a bit, and try and guess, but ultimately you have to do a minimal test to see.

That’s what all the lean startup stuff is about.

Geeks used to just be getting their technology to work at all. The usability revolution of the 1990s, which has now to a large extent played out, made them start to think about what they make as a product for ordinary people. Now, there is a marketing revolution of the 2000s. Geeks are starting to think about marketing as a vital part of what they make.

The obvious expression of that is the way the hackers at Facebook use the same skills that used to be used to write compilers, to instead optimise the growth of their market, and the fit of their product to it. Put like that it is slightly creepy… And yet, it is making stuff you like to use, right?

Products and markets, they’re the same thing. They’re MC Escher’s intertwined beasts. They’re a child whispering to his friend about the latest toy fad. They’re Tesco’s loyalty card optimising store locations.

They’re figure and ground. They’re musician and music.

Products. Markets. You’ll go better if you think of them as one.