Silicon Valley’s Secret Sauce: It’s Made out of People

September 3, 2012

Silicon Valley People Ecosystem

  1. Stanford University and local high-paying employers attract the best ambitious technical talent, and facilitate immigration through visa programs. The rigorous interview process for these institutions acts as a first-round filter for investors.
  2. Entrepreneurs form startups during their academic studies or use savings/equity from their well-paid jobs.
  3. Initial seed funding is readily available from a large network of angel investors. As we’ll see, these angels are likely to already have a shared connection with the entrepreneur.
  4. Later rounds of funding are enabled by one or more local Venture Capital funds, who are also socially connected.
  5. The startup is acquired by, or grows into a larger corporation.
  6. The entrepreneur vests or otherwise significantly cashes-out of their company, with enough wealth to provide angel investment for smaller startups. As the entrepreneur originally came through the Stanford or Facebook/Google/etc route, they likely already have shared connections with many of the younger entrepreneurs.
  7. The angel becomes a partner at a larger VC fund; now the fund also has a connection to the new startups.
  8. The VC teaches a class or becomes a professor at Stanford, forming closer connections with / earlier access to future entrepreneurs.

I don’t want to imply that this is the only way that people and funds flow in Silicon Valley (SV), nor is it even the most common. But it does demonstrate one of the many people-oriented ecosystems that make the area unique. Other entrepreneur networks include those established by funds or accelerators. For example, I like to play my own version of The Kevin Bacon Game, called The Dave McClure Game, in which I connect any person in the Bay Area to Dave McClure (of 500 startups) within two steps.

I’ve lived in three different countries and travelled around the world, and a recurring theme in the web communities of large cities is a desire to replicate the successes and benefits of the SV tech scene. But these tend to focus on the wrong things, like shared office space or high-speed internet infrastructure. While these are certainly useful elements to have, they’re not the source of SV’s success – in fact, anyone who lives in SV will tell you that the internet infrastructure is surprisingly primitive.

It’s the feedback loop of people that makes SV what it is, from the constant influx of young global talent, through the huge experienced mentoring network, to the established investors and thought leaders. It’s a catch-22 born of previous successes.

Polish that Turd: Web Design Rules-of-Thumb for Developers

June 12, 2012

1. Grid

Align all elements to a grid. Use a framework like if you want, but you may find that the gutters between columns are too narrow or your page elements don’t fit neatly into the pre-defined grid. It doesn’t take much effort to set up your own self-consistent set of widths in CSS. You may find it easier if you:

  • Use a CSS Reset declaration to more easily set up predictable spacing, especially if forms or lists are involved.
  • Use a Clearfix hack on rows to avoid weird floating anomalies.
  • Use box-sizing: border-box on your columns and display: inline-block on horizontal list items (e.g. menus) to make padding and margin adjustments easier. Remove any whitespace between inline-block elements to get the best results.

We created our own grid for Subpug


2. Color Palette

Choose a color palette and stick to it. You probably don’t need more than three colors, along with black and white.

  • Don’t be afraid to use shades of your main palette colors. Once you have your main palette in RGB format, it’s easy to create shades with different opacities in rgba() CSS declarations.
  • Limit the amount of gaudy fully-saturated colors in your palette. Even black and white should be a little desaturated; think #111 or #222 instead of #000, and #FDFDFD rather than #FFF.

3. Typography Hierarchy

Create a typography hierarchy and stick to it. Font size is the most obvious way to visualize the different priorities of text, but you can also use font weight, color and family.

  • One font family is the easiest to get right; use two if you need the additional flexibility in your hierarchy. In general, combinations of font families should be dissimilar, such as a serif and a sans-serif, though of similar proportions.
  • If you’re going to stick with a single font-family, you’ll get the most flexibility from a family with lots of weights to choose from. Helvetica Neue is great on a Mac; for consistency across all platforms, try Proxima Nova from Typekit or Open Sans from Google web fonts.

 4. Line Height

Set your line heights. It’s surprising how a small change to line height can make a block of text feel more professionally designed.

  • Make sure that you know the difference between a line height of 1.2 and 1.2em.
  • Try a line-height of around 1.4 to 1.5 for nicely readable paragraphs of text, and 1.1 to 1.2 for tighter headlines.
  • If possible, keep a common multiple between your line heights to set a vertical rhythm. For example, a paragraph of 12px with 1.5 / 18px line height could be paired with a heading of 24px and 1.125 / 27px line height, both of which fit onto a base vertical grid of 9px.

5. Light Source

Define an invisible light source and apply its effects consistently. Most designs assume a dim ambient light source at some distance beyond the top of the page, but you could try different directions or even a brighter point of light directly “over” the page (i.e. from the user’s direction). The effects of the light source are:

  • Solid blocks of color should be replaced with subtle gradients. If the light source is at a large enough distance from the top, a linear gradient should run vertically with a lighter top. Unless your virtual bulb is extremely bright, keep the gradients subdued, though big blocks of color will need a large enough gradient to prevent banding. If the light source is hovering over the page or is close to an edge, it should produce a radial gradient.
  • Interface objects that have depth, such as buttons and hovering elements, will cast a shadow. For most subtle light sources, keep the shadows no more than a few pixels in offset and blur distance, e.g. box-shadow: 0px 2px 2px rgba(0,0,0,0.1), and don’t use pure black for the shadow color.
  • Text that appears on a button or other interface element surface should be given depth, with a 1 pixel drop shadow. A dark text-shadow will make the text appear above the button, a light shadow gives the appearance of inset text.

We use a consistent top-down light source in Subpug


6. Realism

Add subtle realism to the interface details.

  • Square pointy corners are sharp and painful, so most real objects tend to have slightly rounded corners – take the same approach to your UI elements with border-radius.
  • Real-world objects tend not to instantaneously disappear, but instead fold, fade or slide away. Add transitions like –webkit-transition: all 0.4s (and other browser equivalent properties) to elements that move, resize or disappear.
  • Materials are rarely perfectly smooth, so add a subtle amount of noise to your interface. You’ll have to apply noise with an image, but you can create a single tile-able noise PNG with alpha transparency and apply it to elements of different colors via multiple backgrounds, e.g. background: url('noise.png'), -webkit-gradient(linear, left top, left bottom, #E7ECF1, #D1D9E0)


In this upcoming app, we use a non-standard, subtle border-radius (border-radius: 2px 2px 20% 2px / 60px 2px 2px 60px) combined with an inset shadow for an asymmetrical paper effect.


7. Whitespace

Follow Dan’s maxim, “If it still looks bad, add more whitespace.”


The correlation between seriousness and ability

November 17, 2011

Don Draper, the role model for serious businesspeople and sepia-lovers everywhere.

I’ve attended hundreds of sales pitches and client meetings, nearly always as a supplier to a larger organisation. On a few occasions in my early career I recall being faintly berated by colleagues for my behaviour. Not for doing anything aggressive, derogatory or suggestive, but for humorous remarks that were deemed inappropriate – just by the nature of them being a light-hearted quip said in an otherwise serious situation.

With relatively few exceptions, big businesses lack humour. Even smaller web startups tend to take themselves very seriously, and some of the most prominent technology journalists dedicate far too much of their time to personal vendettas and angry rants.

Why is it that our culture somehow associates fun and humour with a lack of professionalism, whereas if you’re solemn, loud and angry you’re taken seriously?

Many of my heroes are known for their wit: Stephen Fry, Al Franken, Jon Stewart, Chris Morris, Richard Feynman, Richard Curtis and Mark Thomas. Though, to be fair, they do all dodge the difficult issues of making profits and running businesses, and instead tackle easy targets like government corruption, the destruction of our ecosystem, corporate murder, third world poverty and the mechanics of our universe, to name but a few trivial matters.

These intellectual professionals demonstrate how humour can be used not to belittle an issue, but to clarify and amplify arguments, and increase the impact of their case. Research confirms [e.g. 1, 2] that humour helps people to remember things.

When I first started to learn the Ruby programming language, I stumbled upon Why’s (Poignant) Guide to Ruby. What a breath of fresh air it is, in the otherwise stodgy environment of technical programming guides, full of irreverence and whimsical cartoons. The author, why the lucky stiff, has/had a rare knack for mixing instruction and art to produce charming, memorable material. If you don’t already know about __why, you can read about his legacy at Smashing Magazine, John Resig and Wikipedia.

There is a time and place for humour, of course.

Most web app interfaces are purely functional and should be as transparent as possible, not interrupting a user’s flow with jokes and confusing pun-laden labels. But when we get a chance to communicate through other channels, whether in-person, through emails and blogs or instructional guides, humour should be considered a useful and professional tool that can be judiciously applied to relevant situations, not avoided at all costs.

And on that note, I’ll leave you with an always-excellent XKCD cartoon:

It’s wrong to stare at someone else’s MVP and compare sizes

November 16, 2011

Whenever a new term enters the Internet lexicon, arguments inevitably follow about it’s meaning and scope. Engineers argued about what was or wasn’t technically ‘Ajax’ technology or ‘Web 2.0’ design, and content strategists are facing a similar problem pinning down the scope of their relatively new industry.

Most recently, the concept of a Minimum Viable Product (MVP) has been debated – does it mean a small first release, a barely-usable prototype, or even just a Google AdWord?

An MVP may or may not be any of those things – depending on how you’re using them – but it doesn’t really matter what the definition is. Like many good ideas, the concept of the MVP is more important than a rigid definition. Rather than trying to replicate other people’s tactical implementations of the concept, it’s better to focus on the beautiful strategy of the MVP approach: what it is trying to achieve.

Validated learning lies at the heart of MVP. This means that you should create something that enhances your knowledge (of the market or the problem space) using real data from customers or potential customers. Moreover, you must endeavour to extract the maximum amount of learning from the least amount of effort (money and time).

This is why the Google AdWord is a compelling implementation of the MVP: spend a few hours and a few dollars creating adverts, and you can learn about the market reaction to individual features, price demand curves, and even – if you’ve configured decent analytics on your landing page – the demographics and trends in daily usage patterns of your potential customers.

However, AdWords aren’t suitable for all cases. If your app is in a highly competitive market, you’ll either need to spend a lot more money to test it (and therefore an alternative MVP implementation may require less effort), or else it will languish on the second or third page of results, where it doesn’t receive enough attention for you to learn anything with confidence.

Similarly, if your app is in a new market, you may need more than the limited space of an AdWord to persuade early adopters to try it. If Twitter had tested an MVP AdWord, they would have received relatively few clickthroughs and may have decided to abandon the idea. Even a sophisticated mock-up or internal prototype may not have been a suitable MVP for Twitter, who would have needed a basic functioning system with the ability to post and read messages before they could discover anything about how early adopters used the product.

Don’t limit yourself to one specific MVP implementation if you can quickly and easily learn more through multiple sources; the MVP is an ongoing, iterative process, not a single definitive test of an idea. Depending on your market, you may decide to create an advert, send out a survey email and also present an annotated wireframe to the board of an interested corporation. When we first started to think about Clickdensity, we published early data on an O’Reilly blog to get feedback from alpha geeks, prototyped with a client to see how they used the results, and emailed our customers to assess their reaction to the proposition.

Which leads me to my final point: you need to carefully consider and perfect your app proposition before you test an MVP. It’s all too easy to get caught up in the idea of an app and assume that people will know what it does and why they should use it. For many forms of MVP, it is the text of the proposition rather than the interactive functionality of an app that’s being tested, so be sure to run your text past a couple of relevant people before testing it with a larger audience.

Web app ideas: Where to find inspiration

November 15, 2011

One of the early chapters in my book (A Practical Guide to Web App Success) discusses the factors that influence the success of an app, such as the idea, the quality and speed of execution, and the wider context in which it’s situated: the competitive landscape, the levels of technology adoption, the financial climate and so on.

While the book includes some quick and easy ways to validate a concept, I don’t really talk a great deal about the initial genesis of ideas, as I assume that most people who buy the book already know what they want to build.

This post fills that gap. It is written for those of you who have the enthusiasm to build an app, but first need a good problem to sink your teeth into.


Most of us spend at least eight hours of every weekday at work, solving problems, transferring knowledge and managing processes. Our wages are usually based on how quickly and effectively we can do these things, as quantity and quality are two key variables that affect business profits. If you can think of a way make a business process more efficient or generate more value in the same amount of time, you’ve got a fundamentally sound app idea.

Unfortunately there is little tangible diversity in the daily experiences of most web app developers. This is one reason why you see a steady stream of new MVC frameworks on Hacker News – we have similar jobs in similar environments, and therefore create similar solutions to similar problems.

Less than 1% of workers in the US are software engineers [data 1 and 2], yet we initiate at least 90% of web app products (a conservative guess). This is the equivalent of most magazines being written by printing press operators – though come to think of it, that would produce more interesting results than the current stable of celebrity cellulite shitfests.

It doesn’t necessarily matter if you pursue an unoriginal idea, but in some ways it makes it more difficult to have a real impact: you’ll face apathy from the market and a prohibitive amount of competition that includes free and open source options. Unless you’ve secured the funding necessary to force your way into a crowded market, it’s better to seek opportunities that at least have a smidgen of something new and that customers have a pressing need for.

If you work in a small company or startup, you’ll naturally wear many hats and will face a variety of non-technical problems. Keep your eyes peeled for tasks that can be automated or improved with web technology.

If you work in a large company you should seek out similar opportunities, but you’ll need to proactively find a way to work with other teams (sales, design, marketing, finance, human resources) to step out of the programming sphere and find fresh problems to solve.

As director of a growing web company for eleven years, I got to discover many problems that are still in need of solid solutions. Here are two examples to get you started.

Example: Responding to tendering opportunities is costly. Large contracts from the public and private sectors are often put out to tender. If a company wants to win one of these valuable contracts, they must respond with a high-quality documented response, which will run to hundreds of pages, though much of it can be boilerplate or customised boilerplate text and diagrams. The value of a contract is often hundreds of thousands of dollars, so it’s worthwhile for the company to spend days or even weeks preparing the tender response, which is incredibly costly, but a necessary risk of winning work.

Over time, a company will create dozens of boilerplate/template documents/answers/snippets that they can re-use in tender responses, but these are often stored in myriad Word documents that need to be manually managed, collated and customised.

There is an opportunity for an app that stores various reusable document components that can be easily discovered, selected, customised and aggregated to produce a tailored, professional tender response. If a company tenders for two projects a month and you can reduce the average tender response time from five days to three days, you’ll save them thousands of dollars a month, at minimum. What might a company pay for that kind of saving?

Example: Assessing good job candidates is difficult. There’s no obvious solution to this, which is why it’s still a problem. Every company knows that their hiring process isn’t perfect. They’ll take on employees who won’t pass a probationary period (costing the company thousands of dollars in wasted training) and will pass on candidates who should have been accepted (costing the company potentially tens of thousands of dollars in opportunity costs).

There are a few partial solutions to this problem (such as LinkedIn and Stack Overflow) but these are industry-specific and not applicable to all candidates. If you could develop an app that helps employers (perhaps in a specific industry) to improve their hit/miss recruitment rate by even 10 or 20%, you’ll save them thousands of dollars a year, and probably a lot more.


When you’re not in work you’re cooking meals, paying utility bills, socializing, pursuing hobbies and fitness, seeking entertainment, traveling, and so on. Adopt a critical mindset for a couple of days to identify areas that could be improved, bearing in mind the types of task that web apps are useful for, such as automating recurring processes, detecting patterns in data and bringing together supply and demand.

Think creatively, and question anything that doesn’t seem quite right from the second you wake up. Feel tired after a restless night? Maybe there’s a way to detect a pattern in your habits and environment to improve your sleep. Throwing away junk electronic equipment because it’s not worth your time putting it on eBay, Craigslist or Freecycle? Perhaps there needs to be an exceptionally low-friction app that can list it for local pick-up within seconds. Annoyed at the garbage that people leave on your street? There may not be a web app answer to that, but maybe there is if you give it some thought. It sometimes helps if you first consider what the perfect “magical” solution would be, ignoring technical limitations. From there, work back to the closest you can get with current technology.

Here’s a more concrete example.

Example: The system for buying gig tickets is broken. We all know it. Many popular venues only list tickets through large corporate ticket vendors, and the final price always seems to end up costing 50% more than the “face value”. There are some complexities at work here (it is often the venues that impose the ridiculous additional fees, not the middle-men), but that doesn’t make the system any less broken to the customer. In addition there are people who buy multiple tickets for no other purpose than to restrict supply and inflate the re-sale value of their own tickets.

So, while there are a number of upcoming gigs at The Fillmore that I would like to attend, I’m not willing to pay the absurd extra fees for bands that I’m only partly interested in seeing. What some of my friends and I do is wait until a day before each gig and then scan Craigslist and eBay for spare tickets. For most gigs, we’ll find tickets at face value or sometimes less. However, we still have to manually set a reminder for upcoming gigs and then scan the websites for tickets a day or two before (or sometimes on the day of the gig itself). An app could make this more efficient, by helping to match supply and demand.


If your primary purpose of building an app is to make money, it sometimes makes sense to copy an idea that’s already proven rather than strive for originality. As Zynga’s CEO Mark Pincus is alleged to have said, “I don’t fucking want innovation. You’re not smarter than your competitor. Just copy what they do and do it until you get their numbers.

You could investigate small (easy to replicate) profitable web apps and copy them feature-for-feature, but for reasons I’ve already stated, I’m not a fan of blatant facsimiles. If you can add a slightly new take on a tired concept you stand a better chance of success.

A simple way to do this is to find a large piece of software and think about how it might be adapted to better suit specific industries; Eric Reis and Steve Blank would refer to this as re-segmenting a market by niche.

Think of how Kyle Bragger’s Forrst took the idea of a generic social network and re-segmented it for graphic designers and programmers. How would you do something similar for your occupation or interests, such as a social network for musicians to share riffs and ideas?

Example: Basecamp for authors/publishers. 37 Signals’ Basecamp is the leading project management and online collaboration tool, partly because it’s well-designed generic features make it useful for a wide range of industries. But this also means that it isn’t tailored to any particular type of business.

My publisher, editor and I used Basecamp to communicate throughout the book authoring process. While it certainly helped, it could have been improved for our particular use-case. Small publishers and distributed authoring teams need a system that better handles revisions between files, and in general something more suited to iterative tasks rather than linear discussions. It would also be useful to have a file repository that treats various assets – documents, diagrams, screen captures, raw data, sources – differently, and one with greater control over the structure and relationships of discussions, files, milestones and to-dos. But it also needs to be extremely simple and tailored for the publishing process, not just a shoe-horned version of GitHub or Redmine.

Even Magma, which handles “print publication management” and according to Techcrunch is a “Basecamp-like platform oriented towards magazines and print publications”, is aimed at a slightly different segment of the market. There are abundant niches to fill in almost every market.

Technology R&D

Sometimes an idea will present itself when you’re playing with technology. In the winter of 2005 I was tinkering with some simple Javascript that displayed the X and Y coordinates of the mouse position, and started to think how interesting it would be to record the coordinates of a user’s mouse on a website. We quickly created some prototype code, and found that the results were actually useful. That code went on to become what was probably the first heat map app, before Crazy Egg, Clicktale and the others that followed.

This isn’t my preferred approach to idea development because it’s technology-led rather than originating from a real market need. Still, it might help to get your creative juices flowing. A quick way to start thinking about the application of technology is to write a list of recent web technologies that interest you on a piece of paper – web P2P video, canvas/WebGL, geolocation, data mining algorithms, and so on – randomly choose two (close your eyes and place your finger on the list), and think about how they could be usefully combined.

Market R&D

What do people say that they want? Social media and web apps like The Internet Wishlist make it easy to find out. Check out Google search suggestions to discover what software people are looking for (e.g. 1, 2), and try creating some convoluted Twitter search queries to find tweets with app ideas. Most will be in jest, but you’ll sometimes find some genuine needs hidden in the noise, and even the humorous suggestions can inspire a practical related app idea.

Researching web app ideas on Twitter


This post outlines different sources of inspiration for web apps. Once you’ve chosen an idea, give it a few days to mull-over and slowly iterate the concept. Rather than gradually expanding on the initial idea, try to stick to the essence of it while you remove imaginary features and scope. Most of all, try to choose an idea that excites you – it makes the development so much easier.