If you are receiving 300 email messages every day (and some people get a lot more than that), you are averaging a new message every 2 minutes over a 10 hour day. That's a completely unsustainable. No inbox-management or priority-inbox strategy is going to help.

Email is busted for a few reasons:

• Asymmetry of importance / urgency between the producer and consumer
• It is a single channel for everything

Any workable solution has to address these. For most people, they can only control what happens in their own organization, and so solutions should start there, and then (hopefully) move outside.

For background, check out this post and comments on Scott Porad's blog

To me the interesting discussion is about moving things out of email to channels that reflect their urgency and importance. This reduces email clutter, and allows people to engage with message streams in the way that makes sense for them.

Importance and Urgency: Four Quadrants

Link: Stephen Covey, The 7 Habits of Highly Effective People

The shape of a solution starts with this chart, and respects the fact that a message may lie in one quadrant for the sender, and a different quadrant for the receiver. For broadcast messages different receivers may assign the message to different quadrants. Almost by definition, the same "subscription" process for everyone is a fail.

Separate Publishing Channels

A solution should allow for different types of channels depending on which quadrant the sender believes that a message falls into. Those channels might be an internal blog post, status update, chat-room message, or private chat / phone call.

Asking message creators to use separate channels has an advantage - it creates social pressure to avoid mixed quadrant messages like this one:

FYI ... so no action on X, but separately, I need immediate action on Y, oh yeah, how was poker night?

When you dig this up from your inbox after 3 weeks, it can be hard to remember which item was the action that caused you to save it.

Separate Subscription Channels

A solution should allow the receiver of the message to choose how they are going to receive it based on the importance and urgency they assign to the message.

This can't always work, especially when there is a mismatch between how the sender and receiver classify a message, but if that mismatch can be resolved quickly, and the message placed in the right channel, it seems like everyone benefits.

Ideas

I'm still searching for the right answer, but here are a few things that I think do have great potential.

• A company-wide (or team wide) continuous chat session. This isolates the not-urgent and not-important, typically social communication. (Skype)
• Private chat or phone calls for urgent and important items. This creates a social pressure for the sender to decide if something really qualifies. (Skype)
• Internal tumblogs / activity streams for status updates. (SocialCast)
• Searchable shared document spaces for institutional knowledge. We used a private wiki, and I'm still not sure if that was effective, but it had the elements of the right solution. (PBWorks)

It's unclear to me if there is a single product to solve this, or if each company will choose a set of products to help them, but there is a real problem, and priority-inbox solutions are just band-aids, and activity streams can help, but don't actually create isolated channels.

What are other people using? If you have a tool you are using, I'm interested to hear which class of messages you have given over to that channel, and how effective it's been for you.

Someone is going to make a lot of money in this space, and it feels like there are breakthroughs waiting to happen.

I meet lots of people who want to start a social web or mobile service. Heck, I want to start a social web or mobile service. I keep coming back to the same sort of conversation, and it revolves around the painful intersection of a bunch of Venn diagrams.

The painfully small intersection

The audience for most social services is represented by the intersection of some of these sets of people:

• Interested in what your service offers
• Actually using your service
• In a location
• At a particular time
• With friends / family

Not all services have all of these components, but most social services have some of them. If the users experience depends on the intersection of all of them, well, that's where things get deeply painful.

Ugly Powerpoint Art R Us

The one circle you can't shed

Link → Creating a Data-Driven Startup by David Cancel

I find myself quoting this presentation all the time.

I see lots of people focusing on strategies for monetizing a social product, or ways to increase distribution, and they skip right past the issue of whether people will care. I wrote another blog post on this topic.

I bet most people read this and think "not me."

Strategies for Making the Pie Higher

Here are a few ways to increase the universe of people who will get value out of your service when you are new.

Personal before Community

All of the presentations from Josh Porter are worth reading.

Link → Psychology of Social Design by Josh Porter

If you can build your community incrementally by having a compelling non-social aspect to your service, then you can avoid a painful jumpstarting process.

ShowYou is a service for discovering, sharing, and commenting on videos. They use your existing social network connections to create service that has value for you the moment you sign up for it, but which has incrementally larger value as more of your friends use it.

Time Displacement

Color is a photo-sharing service (ok, maybe a lot more than that, but this is how I think of them). Color allows you to view and share pictures taken in the same location. Those pictures do not have to be taken at the same time though.

Color expands their market by removing the "same time" and "friends / family use it" circles.

Twitter also benefits by removing the "same time" circle. For some of us, Twitter feels real-time, but it's not a requirement for getting value from the service.

Finding or Faking "Friends and Family"

If you are trying to prove out a social service, you may need a critical mass of users who are loosely connected, at least by interest, if not in real life.

The Bay Area tech scene is perfect for this. A small group of early adopters who are connected by interest, and in real life. Finding (and then leveraging) this sort of group is huge. It dramatically expands the overlap of every single circle in that diagram. I think this is key to understanding how Twitter and Instagram (among others) got started.

Etsy is another example of a company that successfully used strong early adoption by a relatively small (in internet terms) community to gain traction.

If you can't manage this, another approach is to pay to seed a community. Hiring people to be active in the community can create enough of a sense that something is happening to encourage the social engagement of others. Yelp started this way.

The Time and Place Problem

Of all of these, the intersection of time, place and service use seems the most difficult to solve. By "place" I don't mean just physical place. If you are working on a social service that requires people to just happen to be in the same place on the internet, you have the same sort of issue.

Yobongo is attacking this in a really interesting way. They allow people to chat with other people who are in the same location at the same time. They have removed the need for an explicit social circle by making that circle "everyone". They also seem to be making the very smart move of focusing on the Bay Area tech community as early adopters as well.

The Toughest Service Ever

Someone may succeed dramatically in this space, but I think that a mobile service which serves a niche need or interest, requires people to be actively using the application at the same time, in the same location, and requires that they build a new social graph to do it. That's the toughest. Oddly enough, I have heard some ideas that fall perilously close to this location.

I think to pull this off, you need some outside driver for adoption, for instance an app specific to a large event. It might be super compelling, but it just seems really difficult to launch.

The Conundrum

The more of those intersecting circles you apply to your service, the more personal and interesting your service can get, but the more you add, the harder it gets to launch. It's good to know ahead of time what you're dealing with.

I saw Eric Ries speak at the Google Kirkland office last week. Most of his talk was on Lean Startups, but he touched on the process of continuous deployment. I'm a huge fan of continuous deployment, but when I hear people talk about it, including Eric, the process they describe feels unapproachable for most startups, and I think that's a huge shame.

Lean Startup OODA Loop

If you are developing a web service, you should be working toward continuous deployment right now. It can drastically increase your speed through this loop, and alter your idea of how quickly you can deliver changes to a live production site.

http://www.slideshare.net/venturehacks/lean-startups-at-web-20-expo

Getting Started

If you are an early stage web-based startup, and especially if you are pre-launch, you do not need an IMVU-like setup to succeed at this. Even trying to do what they do will just get in your way. What you need is an MVP for continuous deployment. Over time you can grow a system that is appropriate to your technology, service and customers.

Here are the steps I recommend:

• Add basic error notifications and monitoring
• Get to zero downtime deployments
• Create an automated test (continuous integration) server
• Add code to deploy when your tests run green
• Develop a culture around automated tests

Basic error notifications and monitoring

You can use existing tools like Hoptoad for error notifications and PingDom for knowing that your site is alive and running. I'm also a huge fan of New Relic RPM for performance analysis. Their free pricing tier makes this an absolute no brainer.

If you can't find existing tools that will work for you, then write your own. I've been in companies that did this, and it wasn't that hard. Start simple (error notification, for instance) and work up from there.

Zero downtime deployments

The ability to deploy code changes without taking your site down will completely transform your relationship to deployments.

For low to medium traffic rails sites, this is unbelievably easy. We discovered that we could just do a "cap deploy" and nobody noticed the restart.

If you have database changes, make them backwards compatible (add columns, deploy code, and then a week later remove the unused columns ... never rename columns, etc).

If all you did was stop here, with basic error notifications, monitoring, and zero downtime deployments, you will still reap huge benefits.

Get an automated test server

Assuming your automated tests can be run via a script at the command line, then your basic automated test server has only a few simple responsibilities:

• Check your source code control system to see if there is new code
• Pull that code into a folder
• Run your command line script to run your tests
• Notify your team if the tests fail

I used CruiseControl.rb but there is also Cerberus and a few others.

You don't have to use an existing tool. You can write your own script to poll your git repo (or whatever you use) for changes, and then pull them, run your tests, and send email on failure. It is just not that hard.

Shoot for the simplest possible tool. It helps a lot if you can really understand everything that is happening in your automated test environment.

Automate your deployments

This really means just having your test server do a deployment when your tests run green. You can either hack something, or if you are using CruiseControl.rb you can use the cap_deployer plugin.

Culture

If you don't already have a testing culture, the key areas that I think will help the most are these:

• Measure test coverage, and make sure it trends up

  Run test coverage weekly, add the new number to the bottom of a historical list, and email that to your team. In general, you get what you measure, and this by itself is probably enough to move the needle the right direction.

• Write tests for any bug that is made live

  A bug goes live, you find it, you write a test. If you have the time to do it, you should write the test first, verify that you can reproduce the bug, then fix and deploy. If you don't have time, then fix, deploy, write tests, and go from there.

• Write tests for code that matters most to your business

  If you aren't going to have a testing culture and a big body of tests, then at least write tests for the stuff that would be outright embarrassing if it was screwed up.

Yep, there are risks

There are lots of ways this can go wrong. But when you are small, and particularly when you are pre-launch, those issues matter less than being able to move fast. You have to decide what tradeoffs make sense for you, but my experience has been that most pre-launch web services are way too worried abouy deploying a bug, when they should be worried about speed through the loop.

Background Reading

You should read these two great articles:

• Why Continuous Deployment
• Continuous Deployment at IMVU: Doing the impossible fifty times a day

 

Paul Graham has a great essay "What Startups are Really Like" in which he writes:

Optimizing in solution-space is familiar and straightforward, but you can make enormous gains playing around in problem-space.

That term "problem space" really resonates with me, and I was reminded of it recently while talking with another founder about startup ideas.

Your Elevator Pitch

Startup founders need to be able to communicate their business in a concise and compelling way. An elevator pitch is not just about pitching VCs. It's about having a deep understanding of your customer and the problem you are solving for them. In my experience this type of effective communication is a lot harder than it seems.

I have heard a lot of elevator pitches, including some of my own, that barely touch on problem space. They pay it lip service before moving quickly to solution space (how the customer uses the service) or even worse, they move to that strange location I can only describe as implementation space (the clever technology that is invisible to the customer). Us programmers tend to be the ones who jump most quickly to that last one...

Problem → Solution → Implementation

Each step in this progression is generally a step away from the actual customer and the thing that matters most to them. When you describe your business, stay to the left. If you have any doubts at all, read Dave McClure's most excellent rant — Your Solution is Not My Problem

If Dave can't change your mind, then you might as well stop reading.

For Example: Milo

Milo was recently acquired by eBay for a bunch of money. (Go Milo!) Check out how they describe what they do on their about page:

Milo is local shopping made easy. We search your local store shelves in real-time to find the best prices and availability for the products you want to have—right now.

That is a great description. It captures the customer (shoppers who want to buy from a store near them right now) and the problem (finding who has a product, knowing if it is in stock, and comparing prices).

There are so many ways they could have screwed it up, and as a marketplace, connecting buyers and sellers, they had one extra way to screw it up that a lot of services don't have - they could have focused on the wrong customer.

Here are some business descriptions that they could have chosen, and which would have sucked by comparison.

We make it easy to get products from local retailers in front of online customers.

This focuses on the wrong customer. The retailers care only if the service can actually generate traffic from people who will eventually buy their products. You have to get buyer traffic, and to do that you have to solve a buyer problem. If you can solve a buyer problem and get buyer traffic, the sellers will usually line up out the door to have access to it.

Our network of computers crawls the web and applies Super Smart Filtering ™ to bring local products to your browser.

This is solution focused (bringing you local products) and implementation focused (crawling the web). The actual problem is really not ever stated. Weak.

Do What Dave Said

Pitch the problem. If you have a real problem, and if the opportunity created by solving it is large enough, then there is a business there. Maybe your team and your product will have huge success.

If you aren't communicating your business in terms of a customer problem, then figure out why. Sometimes the uncomfortable truth is that you don't have a real customer problem. You have a solution you really like, or an implementation you are really excited about, but you don't have an actual business.