8 Simple Rules to Avoid Email Hell

I just listened to an episode of Rocketship.fm in which Thomas Knoll describes why he decided to ban internal email at his company. It’s a great episode, go give it a listen.

I dislike email as much as the next guy, and I totally agree with Thomas on keeping institutional knowledge and TODOs out of email, but I’m going to take a somewhat contrarian view on this. I think banishing internal email entirely can have negative side effects. Email is very good for asynchronous communication when used appropriately.

It’s not email (the tool) that’s the problem, it’s the people who abuse it.

I don’t like chat as a substitute for email, either. I’ll quote my previous boss, Michael Pryor (Trello, Fog Creek):

So rather than taking a shotgun approach, try implementing a simple rules to keep email sane.

Here are the guidelines we use:

  1. Think hard before you hit send on an email. Can you do it yourself with just a little more time and effort?

  2. Email is not a world-writeable TODO list. Just because someone emailed you and asked you to do something doesn’t mean you should do it. We want to be helpful and courteous, but we are accountable to our team goals first and foremost.

  3. Don’t email a group and expect an action to occur. This diffuses responsibility. Email one person and cc others if absolutely necessary.

  4. Think before you cc someone. Do they really need to know about it?

  5. Don’t expect people you cc to read your email.

  6. Keep your emails short (3 to 5 sentences) and always highlight what needs to by done, by whom, and when.

  7. Don’t send “thank you” emails. It’s implied and they waste time.

  8. Keep institutional knowledge and TODOs out of email (and in Basecamp, Trello, etc.).

Paul Graham

Paul Graham on Growth Hacking

The auspicious Paul Graham, in his How to Start a Startup course lecture #3, said:

“Whenever you hear anyone talk about ‘growth hacks,’ just mentally translate it in your mind into ‘bullshit’.”

This remark harried a few growth hackers, but I think for the most part, he’s right. Lots of people who talk about growth hacking have no idea what they’re talking about. Or they’re trying to sell you on a get-rich-quick scheme.

But notice how Paul said “growth hacks” not “growth hacking.” I think PG is simply trying to dispel the idea of silver bullet tactics, not insulting what we do as marketers.

I’m sure if someone interviewed Paul and asked him, “Do you tell your companies to do split testing, test different traffic channels, and experiment with their on-boarding and referral flows?” He’d say, “Hell yes.”

It’s just semantics. This is no different than saying Agile is bullshit. Or Lean is bullshit.

For those of you that do believe that growth hacking is completely useless, I’d encourage you to read my essay Growth Hacking = People + Process. Hopefully it’ll renew your perspective on this overhyped concept, because there is tremendous value in hiring the right people to do systematic marketing experiments aimed at increasing your company’s growth.

Growth hacking works. And if you’re too cynical to look past the hype and see the value in the underlying process, then you’re just shooting in the dark.

Designer stuff

5 Design Resources for Non-Designers

A friend sent me an email today:

Do you have a reading list for techies to start down a design path?

I’m a self-taught designer, but whenever I come across a good design resource for beginners, I bookmark it.

Here are 5 excellent resources for those who want to learn about software and web design, but don’t fancy themselves designers.

  1. This talk by Kyle Neath at Github is excellent for engineers who want to get started with design.

  2. Designing for Emotion. A great book by the lead designer at MailChimp, Aarron Walter.

  3. Goodui.org. Simple, concise UI design lessons.

  4. Ryan Singer’s talks on design. Scroll to the bottom for his videos.

  5. Nathan Barry’s ebooks on design. He’s written a book on web design and a book on app design.

Growth Hacking Trello Template

If you read my last post, Growth Hacking = People + Process, then you know I’m a huge fan of Brian Balfour’s process for creating, running, and analyzing marketing experiments.

There are a few documents that are central to Brian’s system:

  • Backlog
  • Pipeline
  • Experiment doc
  • Playbooks

To make it easy for you to get started with The Balfour Method (I just made that up), I created a public Trello board template and accompanying Google docs which you can copy and use with your team.

Grab the templates:


They should be fairly self-explanatory if you’ve seen Brian’s talk, but keep reading for an in-depth explanation of how I use this system.

How to use it

The Brainstorm list serves as a pinboard for your team’s ideas and links to case studies and articles that you can reference during your brainstorm meetings.

The Backlog list has a single card which links to a Google Spreadsheet with all of the experiments that you actually want to run.

Wait. Why not just make a card for every experiment and put the details (status, category, resources) on the back? As your backlog grows to 20+ experiments, it’s really nice to be able to sort by resources required or filter by category.


The Pipeline list contains experiments that you’ve pulled out of your Backlog spreadsheet and are going to run soon. You can move cards up and down to indicate priority. The cards are color-coded with labels to indicate which category they fall under (AARRR).

I also like to add a size code to the title of the card: (S), (M), or (L) to indicate relative effort. It makes it easier to see how much work is on the table and prioritize.

Cards are moved into the Design list when you’re ready to start working on it. At this point, you’ll start crafting an Experiment doc that describes your hypothesis, metrics, and all the nitty gritty implementation details. I prefer to link the card to a Google doc (which you can clone), but you could also put your experiment information right on the back of the card.


The remaining lists are simply for visualizing the remaining phases. Simply drag your cards into the appropriate list according to where you are in the process. New members of your team should be able to dig through the History and Playbooks lists to quickly get up to speed on past experiments and best practices.


Growth Hacking = People + Process

There was a recent discussion on GrowthHackers.com about whether Amazon advertising the Fire Phone on their shipping tape should be considered a “growth hack” or not.

Was it a growth hack, in 1987, when the car dealership put their name and number on the plastic license plate holders on my grandpa’s Buick Regal? Or was it just a clever marketing idea?

There is a tendency to talk about growth hacking in terms of tricks and techniques. I don’t like it. It contributes to the myth that there are silver bullets in marketing.

Growth hacking is not about tactics–it’s about people and process.

Sean Ellis, the man who coined the term, says:

Growth hacking is experiment-driven marketing.

I’d take it one step further:

Growth hacking is experiment-driven marketing executed by people who don’t need permission or help to get things done.

Tactics always evolve. To me, the real sea change has been in who is responsible for growing a company and how they go about it.


Traditional marketing teams are comprised of non-technical people that often rely on developers, designers, and data scientists to implement their ideas. Growth teams, on the other hand, are made up of autonomous hackers that generate ideas and execute them from start to finish.

When hiring for your growth team, a good question to ask is: “After you come up with an idea for an experiment, what part are you going to play to make it happen?”

How far can someone navigate around this wheel without putting items on someone else’s TODO list?

Balfour's Growth Hacking Process

Prior to the mid-2000s, I’d never seen a marketing department with technical talent. Now, every marketer should be technical.

Designer-developer hybrids (what I call ogre-mages) are every bit as powerful on growth teams as they are on product teams. If you can find people that can ship code and make things look pretty, snatch them up immediately! Not only are these people highly in-demand, they’re just rare to begin with.


While traditional marketing teams might appear to operate like growth teams in terms of the channels they use (SEM, content marketing, email, etc.), many are run purely on intuition and conjecture, which can be poisonous. Decisions about what actions to take, when to take them, and how much money to spend are made in the blind or based on what may have worked historically.

Growth hacking is about running experiments, analyzing results, and iterating quickly. And for this, you really need two things:

  1. A method for running experiments
  2. A system for tracking and reporting

Running a single A/B test every third Wednesday doesn’t count! You need a process that enforces rhythm, assimilates learnings, and keeps the people accountable. (I love Brian Balfour’s system.)

So, the next time you come across one of those posts entitled 176 Top Secret Growth Hacks (My Cat Loves #8) remember–these are not growth hacks. At most they are marketing tactics that might be worthy inputs to your growth hacking machine.

Still Kicking

Wow, it’s been forever since I’ve posted a status update! Fear not: I haven’t given up! That’d be silly, right David Cancel?


Back when I was posting here regularly I was focused on building a launch list and testing Munchkin Report’s value prop. I did that fairly quickly and since then I’ve been heads down on product development. When I’m coding and designing, I never want to break, even to write these short updates.

Some stats:

1.) Launch list sign-ups: 103
2.) Leads from resource downloads: 34
3.) Blog posts written: 9
4.) Monthly uniques: ~125

I’m about a week or two away from letting early access customers run amok! I’ve had people on the list email me itching to see the product (one of them is a preschool), so I’m super motivated.

Clearly I have a lot of marketing work to do–125 uniques per month will not cut it–but I felt I was in a decent enough spot to make a push to get the product ready. Marketing is going to be much more fun with a product to point to, for sure. I’ve got some really cool stuff planned.

Lesson learned:

Despite all the awesomeness of Rails and AWS and JavaScript frameworks, there’s still a ton of grunt work you need to do with a SaaS: authentication, authorization, multi-tenancy, transaction email hookup (and templates), timezone stuff, etc. Plan for this!

I suspect this stuff is much quicker for someone who is a full-time dev in their day job and has done these things 100 times, but for someone who doesn’t code everyday anymore, it’s been slow.

What I want to do this week:

1.) Send out a pre-launch email to my launch list with a product update
2.) Send a non-pitch email to my resource list
3.) Keep working on the dev tasks required for early access to begin
4.) Hopefully get some responses from 1.) and setup calls with people who want in
5.) Purchase a PO box (I don’t want my home address in CAN-SPAM email footer)


Accelerating Boostrappers

I believe that the bootstrapper community would greatly benefit if individual founders joined forces, Voltron-style.

Let me explain.

If you hang out in bootstrapper circles–places like MicroConf, BaconBiz Conf, or discuss.bootstrapped.fm–you’ll find plenty of smart, talented, and highly-motivated entrepreneurs trying to build SaaS businesses on their own, in their spare time, without much cash.

Inspiration comes from likes of Patrick McKenzie (Appointment Reminder), Ruben Gamez (Bidsketch), Rob Walling (Drip, HitTail), and Garrett Dimon (Sifter), each of whom has reached escape velocity with their startup. But for every Ruben Gamez you’ll meet 100 skilled bootstrappers who are scratching and clawing just to ship something, anything.

Unfortunately, the likely outcome for a bootstrapper is burn-out, dwindling interest, or perpetual “side-projects.” In other words, failure. (Other times we fail for the same reason funded startups fail: nobody wants what we made.)

What is success to a bootstrapper?

It is not building the next Facebook or Twitter. We don’t raise venture capital because we don’t want lots of employees, a board, and pressure to exit. We’re not aiming for the fences. We’re looking for what the Valley often calls singles and doubles.

Bootstrappers usually want the following two things:

1.) To earn a fantastic living 2.) To build and sell software products with people we love and respect

The accelerator approach

I’m not suggesting, as some people have, that solo-founders team up from the start as co-founders. Instead, I propose that we turn mastermind groups into mini-accelerators using the Idealab model (as opposed to the YC or TechStars model).

Companies within Idealab are malleable. The founder, Bill Gross creates, modifies, and kills companies as he gains information about which ones are likely to succeed. More importantly, it’s not a winner-take-all system. Rather, the whole of Idealab is enriched when they produce a successful company.

Translating this to bootstrappers: in a mastermind, when one of the members starts getting serious traction with their product, 1 or 2 of the other members can elect to sideline their own products and join the promising one in hopes of making it a winner (where winner == a small, highly profitable software business).

Check my hypothetical math, but $60,000 in monthly recurring revenue (MRR) with 3 highly-talented entrepreneurs seems much easier to achieve than 3 highly-talented entrepreneurs trying to achieve $20,000 MRR on their own.

But how in the world is this a good idea for the original founder? Because growth and success for a bootstrapper can be excruciating at times–specifically the times at which you would typically raise and deploy venture capital.

This slide from Garrett Dimon’s amazing talk Bootstrapping a Software Product sums it up nicely:


If the founder can short-circuit the “most challenging time of my life” leg of the journey and share his/her success with 1-2 like-minded bootstrappers, that’d be awesome!

The cap table shouldn’t really matter because of the no-exit premise, but you could do a 50/25/25 split. Again, the goal isn’t to build the next Oracle (God help us), but building the next 37Signals or Balsamiq or Panic would, in my mind, be a net-benefit for the world and help more micropreneurs reach the ultimate goal of earning a fantastic living building software on their own terms.

This is merely a thought experiment, but I would absolutely love to hear your thoughts in the comments below!

Sidebar 1: The podcast Our Own Little Accelerator sparked the idea for this post. It’s essentially a recorded, published mastermind session. It’s awesome! A few episodes in, it had me thinking, “Wow, if a few of these guys just joined forces and worked on one good idea, they’d be wildly successful.”

Sidebar 2: For more on Bill Gross and Idealab, check out this fantastic interview on This Week in Venture Capital.

My Struggle with Ruby Blocks

My name is Rob and I had trouble understanding Ruby blocks.

This is my story.


Oh, hey, here’s a simple example of a block in Ruby:

display_name do
  puts "Rob"

Wait, why not just do this:


Oh, I see, because display_name doesn’t want to decide how to display my name. Instead, it wants me to supply the line of code that does the displaying. Three cheers for flexibility!

Let’s add some comments to illustrate this difference:

# I'm passing a block of code for display_name to run
display_name do
  puts "Rob"
# > Rob

# I'm passing a value for display_name to use with its own printing code
# > Rob

But I don’t really understand how display_name runs my block of code. Maybe it’ll make more sense when I look at the method definition:

def display_name

Hmm. That method definition doesn’t exactly scream, “Yo, I take block of code and run it!” There’s no argument in the method signature that accepts my block, and I don’t see anything that actually calls my code either.

Hidden in plain view

After some digging, it turns out ANY Ruby method can invisibly accept a block and the yield statement illustrates the calling of the given block (at runtime my code goes right where that yield statement is).

Wow, that’s TOTALLY not obvious.

There’s an alternate–and more explicit–way of defining such a method:

def display_name(&block)
  block.call if block

Above, there’s an argument in the method signature that indicates that there’s a block of coding being passed in and explicitly called. There’s even a check to make sure a block was provided!

Despite its clarity, nobody uses this pattern because it’s slow and Rubyist tend to favor brevity.

OK, achievement unlocked, but the example above is too trivial. It doesn’t illustrate what blocks are good for. Let’s modify it slightly:

def display_name
  puts "I'm about to run your code..."
  puts "That felt good."

The method isn’t much more useful, but I kinda-sorta see where we’re going with this. The method can do all sorts of things before and after it runs my block. I’m starting to see blocks as a form of code injection.

Putting on my big boy pants

I’ve got this now. Let’s do some Rails!

@product = Product.find(params[:id])
respond_to do |format|
  format.json { render json: @product.to_json }

OK. Based on what I know, I’m calling respond_to and passing it 2 lines of code to run, which are:

format.json { render json: @product.to_json }

But what is format? Where does its value come from and why am I calling methods on it?

Is format an argument to respond_to?

<< scratches head >>

No, that would look like this:

respond_to(arg) do |format|

Or as we Rubyist are accustomed to:

respond_to arg do |format|

Turns out that format is an argument to my block. Its value is passed (or yielded) to me by the method I’m calling.

Let me phrase that differently: I’m calling respond_to which does some stuff and then passes my block a value held in the variable format.

Right, but what is format? What can I do with it?

respond_to do |format|
  # Umm...

A minor epiphany

Here was the major realization I had about blocks: without understanding the inner-workings of the method I’m passing a block to, I can’t really write my block.

I couldn’t treat it as a black box, as badly as I wanted to. With many methods (or APIs), I can simply pass in arguments and get a return value without ever having to understand what actually goes on inside. And that encapsulation is a beautiful thing.

But with blocks, I am actively participating in writing the method I’m calling, so I have to understand the context in which my code is called. I also have to understand the objects that are yielded to my block via its arguments.

Let’s play detective:

respond_to do |format|
  # What is format, really?
  logger.debug format.class
# > ActionController::MimeResponds::Collector

I’m calling respond_to and passing it some lines of code to run. My block is given a Collector object to work with via the variable named format.

Now I can look at the Collector class and see what methods I can call (such as html and json). Ah-ha!


I’d be remiss if I didn’t touch on iterators. See, in Ruby, blocks are also used quite frequently to iterate over collections:

food = %w{apple orange grape coconut}
food.each do |f|
  puts "I like to eat #{f}"

Armed with my knowledge about blocks, this code is super-easy to understand!

I’m calling food.each once and it does all the legwork required to loop through the array which called it (i.e., food). Every iteration within each executes my puts block, passing it one of them items from the array via the variable f.

And that’s all there is to it! :-)

Comments? Questions?

Did I miss anything? Veteran Rubyists dying to tear me to shreds? Leave a comment below.

Entrepreneurial ADD

What I did this week

  • Published blog post 3 Sleep Training Books You Can’t Live Without and promoted to FB, Twitter, Pinterest
  • Commented on 2 parenting blog posts and linked to the above (and I’m actually getting some traffic as a result)
  • Edited 2 blog posts in the queue (with M for final review)
  • Designed a printable child activity sheet with Munchkin branding which I’m going to give away for free
  • Created a resource center and added the daily activity sheet to it
  • Created a MailChimp workflow for delivering resource downloads in exchange for email addresses (this was harder than it should be)
  • Attended the HubSpot Inbound conference in Boston

Traffic to the Munchkin Report sales page and blog is still pretty much non-existent. I wish I could move faster, but I’m somewhat pleased with the above.

On the Mastering HubSpot book front, I did a lot of word-of-mouth promotion at Inbound.  I’m feeling good about the ability to promote the book through an existing channel, but splitting time between writing chapters and moving the Munchkin marketing needle is horrible.

I titled this post Entrepreneurial ADD, which is a term I think I got from Mark Suster. Many entrepreneurs can’t focus on one thing because they get bored too quickly.  I don’t believe that I’m afflicted with E-ADD, though my symptoms are the same. I just think I’m suffering from severe time constraints and I’m spreading my available time across too many disjointed activities–writing, marketing, coding, researching, editing, etc.

I’m quite used to Extreme Context Switching™ from my day job, but doing it after-hours is really hampering the progress of both Munchkin Report and Mastering HubSpot.

I’m seriously considering shooting the book in the head, despite how much I believe in it.

I’m going to run this by my mastermind group this week, but I’d love to hear what you think, so please post a comment!

Next week

  • Link to my daily activity sheet PDF in various forum threads I found where people are asking for one
  • Brainstorm a list of content ideas specifically aimed at daycare directors (as opposed to parents)
  • Begin work on “X Most Influential Parenting Blogs”-type blog post (holdover from last week)
  • Send a nice email (asking for nothing) to 10 semi-popular, non-A list, parenting bloggers (holdover from last week)

Segmenting a MailChimp List by Signup Source

I love Nathan Barry’s post on how he does email marketing. One small, but important, detail that I picked up the second time through the post is that Nathan keeps all of his subscribers in a single MailChimp list and then segments them down by signup source in order to deliver the most relevant content.

This is an excellent way to structure your list. You could achieve the same result with separate lists for each signup source, but that will become unwieldy when you want to send a single campaign to multiple lists, or to your entire subscriber base.

So, how do you capture signup source?

It’s really easy! Login to MailChimp and click on Lists in the left nav and then click on your list name. Click Signup Forms and then General Forms.

Add a hidden text field called SOURCE with a label “Signup Source” and a reasonable default value (in case you forget to pass one). Save your form.


Notice how I put the merge code *|SOURCE|* in the header of the signup form as well — this essentially lets you call your list something different to people signing up for different reasons versus settling on a generic name and potentially confusing people.

Now, wherever you embed your form, simply add the following line of HTML right above the <div> that encloses your submit button:

<input type="hidden" name="SOURCE" id="SOURCE" value="RobSobers.com Newsletter">

Obviously you should change the value parameter to whatever you want that signup source for that form to be.

That’s it — now you’ll have an extra property on every subscriber record that indicates which form they came in on. If you’re capturing email addresses with multiple different incentives, this extra bit of data is vital.