Have many ideas. Pick the right ones. Ditch the wrong ones. Succeed. Sounds simple! That’s the theory, anyway. In practice it’s somewhat harder than that. How do you know which of your ideas is a “good” idea, and which is a “bad”? How can you dispassionately give up on ideas that you think are brilliant, yet show little sign of success?
I think of my process of idea development as something like a funnel — many ideas go into the funnel, and steadily I whittle them away based on evaluating them, doing tiny prototypes and hopefully, at the other end is a set of validated projects/products that are valuable and proven. I’ve been applying this process at Makeshift, the startup studio I co-founded.
The “If you want to have good ideas you must have many ideas” quote above are the words of accomplished chemist Linus Pauling, paraphrased by his contemporary Francis Crick in a talk he gave about Pauling’s life and work. It’s commonly quoted, yet the second part, about the importance of pruning your ideas, is often overlooked. It’s really worth reading the full text of his talk on this subject to understand the nuance:
…Linus Pauling was enormously fertile in the way he developed his ideas. He was asked a few years ago, “How do you get ideas?” And he gave I think what is the correct reply. He said, “If you want to have good ideas you must have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away.”
Having the ideas is the easy part; he did not say this — I am simply interpreting here what he probably thought of as the easy part. The difficult and rather intuitive part is to know which ones to hang on to and which ones to throw away.
It is clear from what I have said that Linus Pauling was not always right in his ideas. But my belief is that, in most cases, if somebody is always right in his ideas you find that he does not have much to say. It is an expression of somebody’s fertility that he does produce quite a number of ideas, and I think Linus Pauling’s score is pretty high. I do not know what Linus would have said about it, but I certainly find in myself that, as you get older, this intuitive knowledge of which ones to discard perhaps weakens a little.
Maybe with some of his later ideas, although they were on the right lines, he perhaps might have clung to them a little too strongly. I find myself doing just the same.
This “have many ideas” approach is something I’ve been working on for some time now. It’s lead to starting several companies, doing lots of projects, and I’ve been giving a lot of thought to both the idea-having and the idea-following-through processes along the way.
This last eighteen months, I’ve deliberately tried to go for a strong idea, loosely held approach — to allow myself to be open to lots of things, and to not be too convinced that they will definitely be right. The strategy was to try out many tiny ideas at an early stage, do a series of quick prototypes, play with them, often in public, and then invest in the ones that looked the most promising as the beginnings of digital businesses.
We’re at something of an inflection point in the process now, where three “winners” have emerged from the cohort and have the potential to turn into fully-fledged “startups” in their own right. That’s Attending, Wrangler and Hire My Friend. We also have made a few lovely little things that have a fair degree of usage but aren’t clearly startup material — Linkydink, for example.
But that’s the thin end of the funnel. At the other end are all of the ideas that either didn’t make it, were discarded or I put off for another day. In this period of work I’ve started around 50 code-bases!
What does an idea funnel look like though? At its simplest, it’s a list of potential ideas. In eighteen months I started, or help start about fifty ideas. Have a scan, and below I talk about some of the things I’ve learnt.
- Honey — an elegant publishing platform for the rest of us. All of the Makeshift articles are written using this.
- Flounder — a way to build your startup or project’s Twitter audience
- Help Me Write — exposing your drafts to your audience to get their input on what you should write
- Hear There — a headphones-on listening experience about memory
- Lando — landing page management for your site
- Teh Guardian — find the mistakes inserted into Guardian articles
- Story Jar — inspiration for a story to make up with your kids
- Selfie — aggregated images tagged #selfie
- Stef — my personal site that aggregates lots of things via APIs
- Deck Roulette — random talk generator I used for my Do Lectures talk
- Linkydink — link sharing and daily email digests for small teams
- Do a course — distance learning with a cohort of people
- East Dulwich Forum ++ — a proxy that improves UI for a legacy forum
- Conversatives — swaps words around on conservatives.com (!)
- Sketching with Code — my writing about my hacky process
- DM a URL — a way to share links now that Twitter bans them in DMs
- Educe — a plug-in for Segment.io that captures events in a Postgres
- Emily Quinton — an elegant little site for Emily with full screen video
- Heber Parents — a one-day site for the parents and friends of a school
- Follolo — analysing networks of followers on Twitter
- Periscope — a tiny sinatra app for running SQL that became Wrangler
- Makeshift website — the site itself is an interesting project
- Rumbleroll —Jase Coop’s idea for quiet RSS aggregation
- Buildgrabber — take and store screengrabs of websites over time
- Shhare.io — credential-sharing for small teams
- Cryptographics — a visual language for hiding information in a graphic
- Savemates — rotating savings and credit associations for small groups
- Tickle — a proxy for the Twitter API that uses all of your users’ credentials to maximise your API calls per hour
- Sunday Post — a collaborative writing project, spawned Attending
- Screenlight — instagrams of people lit only by their devices
- Nub — an attempt to create a good Rails starting point for hacks
- Pogoid — datamapper for Active Record. Didn’t work!
- Floral Friday — an Instagram competition site with a gallery
- Rolo — making lists of people more useful
- Link Scientists — trying to get reporters to link to research
- Dealhacker — something about dealflow for seed investors
- Hugbase — a mashup of Datahug and Crunchbase
- Bitsy — paid pages for things you can download
- Tentoring — ten minute mentoring
- Gothub — find a github username based on an email address
- Richerlist — enrich a list of email addresses with other metadata
- Makelight — a brand and blog for Emily on Squarespace
- Silicon Throwabout — frisbee in the park using Attending
- Work in Progress — an event series about work-in-progress projects
Phew! That’s certainly quite a lot of “new”, and as far as Linus Pauling’s suggestion about having lots of of ideas goes, I think I took it to heart!
It feels true that without having gone so wide with a set of potential ideas we wouldn’t have arrived at three good ideas in the end. But I’ve observed a few things that I think will influence me in the future with this process:
Most of the ideas related to my own particular, personal observations on what I needed or what I saw was missing in the world. I can’t really see any other way to “have lots of ideas”. You can’t imagine what other people will want as well as you can imagine what you might want.
Similarly with the team — the ideas that each of us brought into the studio were often “scraching your own itch”, and as such, the things that seemed to work were scratchy products. When we weren’t scratching an itch, the idea didn’t seem to stick.
Passion is a filter
It’s fine to scratch your own itch, but are you really passionate about an idea? Because it strikes me that if you’re really trying to start something that turns into a business, when you’ve got opportunity to the left and right in a stack of other competing ideas, you’re going to have to be able to summon a serious level of passion for an idea to follow it through. Many of the ideas at the fat end of the funnel didn’t get much further because that passion wasn’t there — either for me or for others in the room.
It’s good to play with lots of ideas, and not everything that goes into the wide end of your idea funnel should be utterly change-the-world-I-have-to-make-this-happen-at-all-costs, yet at some point in that funnel from idea to product someone will have to be personally convicted of the idea and want to fight for it. The percentage of ideas that got picked off because of lack of passion is probably quite high.
Many people looking at the Makeshift model have asked me “how long do you give an idea before you know it’s working?”
I wish I had a good answer. At one of our “work in progress” events we were demoing one of our ideas we were working on, and Blaine from Poetica was in the room. He made a strong point about the project — it needed more breathing room before we could decide to kill it or keep it.
If you don’t give an idea long enough to gain traction, to work out what it is, to really go deep on it, you’re limiting yourself to working on very much surface-level problems, to finding solutions that are at best local minima.
Yet, the pressure of having too many simultaneous ideas going through our “idea funnel” meant that we had to kill ideas quickly to give ourselves resources to work on the right problem. I guess this is why we have ended up with quite sensible products coming out of the process — there wasn’t any way that we could have produced very out-there ideas because those kinds of things tend to take a long time to go from experimental project to wide adoption.
This breathing room problem in the funnel is an area that I’ve not solved. Certainly looking at other studios that work similarly, I see that they often go for a serial process rather than doing multiple things in parallel. I think both approaches have advantages and disadvantages.
Hacks on hacks
Something that I was keen on in all of this was to share code between many of the ideas. Again, this is good and bad. It means that the class of problem that you can solve in your funnel has to fit into a certain mould — in our case websites / web-apps. It was helpful to have that constraint to allow for code re-use and for hacks to build on the work of other hacks. Yet also it narrowed our problem space to not include various areas that I’m passionate about.
It’s worth ensuring that you have some diversity in your funnel — trying out different technology could give you something surprising like what happened with Flipboard. They were working on their product just before the iPad arrived, and decided to jump on a new technology to take advantage of it. If they’d made the same decision as we did, that everything had to be web-first they wouldn’t have had the amazing success that they achieved after the iPad launch.
Finding the right numbers
For each of our hacks that got through to “let’s make it” stage, we established a few key numbers that we could monitor weekly. It wasn’t very vigorous, but by paying attention to what the key measure you’re going for on an idea is, you can really come to a conclusion as to whether it’s a good or a bad idea.
If you don’t decide what you’re looking for as your “keep or kill” signal up front, you’re probably going to waste some time and resources building the wrong thing. For example, I made a little thing called Flounder in my spare time. It’s a way to build an audience for your startup or project.
The key number I was looking for there is “is the follow-back rate better than what I get from Twitter ads?” I wrote a little SQL report that ran every week and I got a number back. Somewhere between 9 and 15 percent for Flounder versus the 1 percent I was getting with Twitter ads. So my answer was “yes” and I could quantify it. Having that number to hand really helps you decide if you should follow through on an idea or not.
Killing your darlings
The hardest part of the funnel approach to developing products though, is the meeting where you sit down with all of this information — your scratchy product idea, the hack you’ve made to validate it, your numbers, the fact you’re passionate about it, and you have to battle it out with the other equally validated, interesting, passion-backed projects from your team.
The skill I had to really develop, and I’m still not there, is to accept that sometimes what you may think is a great idea just has to be killed or “put on the back-burner” because as a team you only have so much time, money and energy at your disposal.
It’s the ability to kill your darlings that will enable you and your team to make something significant. Otherwise everyone would end up on their own working on their own passion project. Something has to give, and getting comfortable with killing or shelving good ideas is the hardest part of moving from the wide end of the funnel to the other.
It can be painful to swallow your pride and kill something you think is a sure-fire winner. That pain doesn’t go away, but hopefully, if you’re lucky, you’ll look back and say “gosh — if I’d not killed that I’d never have this”.
Which ones to throw away?
I’ll return to the quote that was the starting point to this piece: “If you want to have good ideas you must have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away.”
So many people seem to focus on that early part and stop before “Most of them…” when they mention these words— just have lots of ideas! It will all work out fine! Clearly that’s missing the nuance, and the process of stopping working on the things that might be bad ideas to focus effort on the good ones, is why Linus Pauling was such a good scientist and was able to make such significant progress in his field.
It’s this funnel concept that I think has been so helpful to me over the last few years. When you start thinking of your experiments, sketches, conversations, suggestions as items that are going into a funnel of your own making, it becomes much less stressful when someone says “oh not another idea! We haven’t got time to do the last bunch!” It’s not the point — the funnel should always be filling up, and if you’re lucky enough to find a way to develop one or two of your ideas into fully-fledged projects, features or work-streams you’re winning.
If you’re like me, and have lots of ideas on the go, perhaps it’s time to start thinking about your funnel, how you allow yourself to have hard limits around assessing the viability of your ideas, and developing a way to talk about how “that idea didn’t work out”, without worrying that people will think less of you as a result.
As is the way with my hack, play, learn approach, I’m going to take what I’ve learnt from this period of making and put it back into how I do my hacks. I think the main thing is that you can’t entirely flip from “come up with loads of ideas” to “no more new ideas, we just build on what we’ve got”. That’s not how I work, and the funnel should always be filling up — possibly with ideas that build on what you have, but also possibly not. Having now got to the point where we have a few successes coming out of the thin end of the funnel, my focus is back on the wide end — what am I passionate about, what itches do I want to scratch, which ideas that I’ve got on the shelf do I want to push forward?
I’ll leave you with the hardest learning from this period for me, and it’s something that I’m struggling with but that I continue to aim for:
Get comfortable with killing the bad ideas and you’ll free yourself to focus on the good ones more quickly.