My Cognitive Circus

I’ve just finished reading Clay Shirky’s excellent book Cognitive Surplus. It took me a while, not because Clay is a difficult writer to read (he’s not), but because I’ve found myself reading books less and less. In my mind, I haven’t had time to read but the truth is probably more that I’ve been distracted from reading by many of the technologies that Clay writes about in the book.

In the end I finished the book on a plane to Barcelona with enforced new media silence and since I didn’t want to rack up an extortionate roaming bill on my iphone while I was away, I also found myself sitting in a lovely outdoor cafe reading Steven Johnson’s wonderful new book Where Good Ideas Come From.

This set me thinking about my daily relationship with the cognitive circus of twitter, email, foursquare and facebook. I realised that I have become addicted to the tiny dopamine hits of seeing something new on my iphone or computer in the office or at home. There’s something in my character that likes to know what’s going on which all these things tap into and which I really don’t like.

I sometimes catch myself browsing through twitter and thinking I really should be doing something more productive and close the application, only to find myself absent mindedly opening it again a few minutes later wondering what new messages have appeared.

The editor of Miller McCune John Mecklin puts it well in this piece with the lovely title of The Gadget in the Gray Flannel Suit:

“The gadget-driven opportunity to interact, from almost anywhere, with an ever-expanding universe of people seemed entrancing initially… After a time, though, the gadget’s call — check your e-mail; someone just commented on your Facebook post! — became less a joy and more an irritant that I sometimes purposely avoided.”

I’m certainly at that stage now although it’s actually something I’ve battled with for many years on and off. One of our investors Tim Jackson gave me a copy of Never Check Email in the Morning — I think as a subtle hint about my slightly erratic productivity — and although the book is terrible there is something in the idea of not letting yourself settle into a responsive mode straight away each day.

None of this is a criticism of the platforms themselves. Although they are designed to suck you in and hold your attention, I think it’s the responsibility of the people who use them to find ways of making them manageable. Jamais Cascio is right when he says:

“the technology-induced ADD that’s associated with this new world may be a short-term problem. The trouble isn’t that we have too much information at our fingertips, but that our tools for managing it are still in their infancy.”

I’m really going to focus on getting the right balance over the next few months. If I find ways to get it right I’ll share them around.
Related articles

How to start a social startup: prototyping

When you’ve defined your problem, have a short description of your solution and you’ve started getting positive feedback from real people, it can be helpful to build a prototype of how your solution might work.

The key thing here is that you’re not yet building the technology you will finally use. You’re using things that are cheaper and quicker so that you can get feedback. As with the initial interviews and questionnaires, you’re looking for patterns but also aware of anything that sounds strange when you first hear it — sometimes those things can tell you a lot.

These are the tools I’ve tried and would recommend:

Draw it on paper

One of the best ways to show the service to people is to have cards with the stages they would go through to use the service and then see how they react. It really doesn’t need to be complex at all — just sheets of normal paper or card that you can show them in order.

Get people together

We did two things to test the original idea for School of Everything by getting the people who we thought would use the website in a room together, although I don’t think we realised we were prototyping at the time. It helps get over all the asynchronous and distance stuff that your service will help people get over eventually.

The first was what we called Free Schools, not the Michael Gove ones, but evening events where we’d get a bunch of people (usually about 20) together and put up a board with ‘What would you like to teach’ on one side and ‘What would you like to learn’ on the other. Basically they would get conversations going and quite often people would meet up afterwards to learn from one another.

The other was prompted by Russell Davies who asked us to do ‘something fun’ in the lobby at Interesting in 2008. We built an Interesting Machine which was really just a postbox that people could put what they wanted to learn or teach into. We got several hundred cards and sorting through them showed us a lot. We didn’t know quite what to do with them though. Thinking back, what we should have done is then set up groups for all the people who were interested in similar topics.


We’re really lucky at School of Everything because we have Sangeet who can mock things up in photoshop very quickly. We often turn them into click through presentations and then show them to people to get immediate feedback. It very quickly shows you if there is any confusion about what the service does. Wireframes have a similar effect and there are lots of tools out there for putting them together pretty quickly, even if you’re completely non-technical. Mockingbird is a very good one.

Be the machine

The next technique is possibly the closest you can get to building something that might work. If you’ve started to realise what the different bits of your service are you can generally mimic them yourself using Google Docs, email and a mobile phone. This is what we’ve been doing over the summer with School of Everything Groups as members of Bethnal Green Cookery Club will testify. Of course you can only do it for a small number of people but it’s amazing what you learn.

So that’s it. A few techniques for non-coders to get a better idea about whether the problem you’re trying to solve is real and whether the solution you’re proposing is something people might use. At this stage, you still don’t have a website or a business plan but you have a lot more information about whether your idea is a goer.

How to start a social startup: Understanding the problem

We’ve just started helping the first cohort of Bethnal Green Ventures projects and I’m using it as an excuse to write down some of the things I’ve learned about social startups over the past couple of years.

It starts with a hunch

You start the process of developing a startup with hunches about both the problem you’re trying to solve and the solution you’re going to build. In my experience these are always sparked by a story, which for School of Everything Mark I came from John Markoff’s book What the Dormouse Said,  but for other people it’s something that a friend says or something they go through themselves. The story of the Free U gave me the idea for a solution and I could quickly see the problem that it solved — or at least I thought I could.

My mistake was that this wasn’t a problem that individual people had — it was systemic. I thought the problem we were trying to fix was how rigid and out-of-date the organisation of the education system is and that is a problem, it’s just not one that a website can solve on its own. A website solves the problems of an individual person, but it then takes lots of people using the website to change the way something is organised systemically. And generally people won’t do that unless you build something that solves their individual problem.

So I think if you’re building a social start-up, the problem you’re trying to solve has two parts:

  1. an individual person’s problem that you can build some technology to help solve.
  2. a social problem that will be solved if lots of people use your solution to 1.

You can think of either one first — the important thing is that you need both.

Get out of the office

When you have these written down and your hunch about a solution, you need to get out and test them. We’ve been doing this incessantly over the summer for School of Everything Mark II. What’s important is to get accurate information. I like the analogy of this being like the scientific method: you have a hypothesis that you then test by collecting real data.

You need to think who might have the problem that you’re trying to solve. Over the summer we recruited people by asking for volunteers through Facebook and Twitter and just following our own social networks two or three degrees to get to different groups. These were as diverse as over 55s in Manchester through to young mums in London.

We found the two best tools for gathering information are Surveymonkey and shoeleather. Surveymonkey gives you some numbers but you do have to be careful in the way you design questions and interpret responses. We set the goal of getting over a hundred responses and looked for answers to be chosen by over 80% of respondents for us to think it was strong enough finding.

We also did lots of face to face interviews by getting out of the office. These give you the insights you need to know how what you’re proposing will fit into people’s lives. You also get more accurately from these what people might be willing to pay. It’s much easier to tell whether people are serious face-to-face.

Minimum Viable Product

We also showed people what the Lean Startup crowd call a Minimum Viable Product spec. This is important because you need to be confident that you can build it. As Steve Blank says, “Any idiot can get outside the building and ask customers what they want, compile a feature list and hand it to engineering.” So as we went around asking people if anything we were reducing the number of features rather than getting more ideas about what it should include.

Once you’ve done this for a while, the answers become quite clear as to whether what you think you’re solving is a real problem and whether there are people out there who’d be willing to pay for what you’re proposing.

By the end of this process you should have:

  • A couple of sentences that explain the individual person’s problem you’re going to solve and a list of the people who you’ve met who have that problem.
  • A couple of sentences explaining your solution and a slighty longer minimum viable product specification (probably no more than ten features).
  • A couple of paragraphs showing that you understand the broader social problem it will solve if it all goes to plan.

Note you don’t have any technology yet, or a business plan or a company or full team or bank account. You can do all the above and have a pretty good idea about whether something is worth building or not but only have spent a very small amount of money.