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–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) 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=" 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.

Building Traffic From Scratch

This post is part of a series which chronicles my attempt to bootstrap two products: a SaaS called Munchkin Report and a book called Mastering HubSpot. 

Last week’s post titled Building Software in Public yielded a great response from the startup/bootstrapper community. The post briefly made it to the front page of Hacker News.

The result:

  • 2,450 new visitors to
  • 87 new RSS subscribers to
  • 594 new visitors to
  • 8 new members on the Munchkin Report early access list

While Hacker News readers clearly aren’t the target audience for my products, this is still a positive thing.  I hope some of these visitors follow along and learn something; plus, the more people that know about my products, the better.

A number of people emailed me or posted comments cheering me on and offering feedback and advice.  A few people even said they can’t wait to start using Munchkin Report with their families!  Thanks to everyone who chimed in.

OK, now back to business.

What I did for Munchkin Report this week

  • Published a new blog post and promoted to Twitter, FB, Pinterest (8 pageviews)
  • Retweeted some parenting articles from @munchkinreport
  • Followed some more relevant accounts on Twitter and Pinterest
  • Sent a guest post to
  • Drafted 4 new blog posts
  • Launched a $10 paid discovery campaign on StumbleUpon (cost so far $5.60, visits 25, conversions 0)

Publishing quality content that nobody reads sucks, but you have to do it.

Building an audience from scratch is, in my estimation, one of the hardest things about bootstrapping.  As you can see, it’s slow going right now, almost depressingly so.

But we’re going to keep plugging away, posting and promoting the best blog content we can possibly muster up, even though it appears futile right now.  This will pay off, hopefully, in a few ways:

  • In the long run, if we keep publishing content strategically (i.e., paying attention to keyword difficulty), we’ll eventually start getting that steady trickle of reliable organic search traffic to each post
  • If we do have a hit post, people will be able to work backwards and read the stuff that was written when no one was watching, which will increase the likelihood of making them a fan
  • Having quality content published will increase our chance of scoring guest blog posts

Some resources I’ve used

StumbleUpon Paid Discovery

I launched the paid StumbleUpon campaign on a whim.  There’s no good reason for choosing this over AdWords or Facebook other than how fast it was to setup.

Like Facebook, SU lets you target a demographic.  SU’s dashboard tells me I got 40 paid visits, but Google Analytics only shows me 25.  Not sure why this is, but it’s probably worth an email to SU to find out.


I’ve only spent $5.60 so far and my cap is $10.  I realize this is probably not a large enough spend to get a significant reading on whether or not this could be a viable acquisition channel, and for that reason, is probably a waste of money.

I’m also debating whether I should send people to the blog or a landing page with a specific incentive (e.g., potty training guide) in order to capture their email address.

At the current cost-per-visit, I can spend $140 with SU and get 1,000 visits in the parenting/babies demographic.  At some point, I’ll do a Facebook vs. SU vs. AdWords challenge and allocate $100 to each and see what happens.

Next week for Munchkin Report

  • Create and publish a free printable daily activity sheet PDF with Munchkin Report branding (holdover from last week)
  • Edit and post 3 of the 4 blog posts in the queue
  • Follow-up with on guest blog post
  • Begin work on “X Most Influential Parenting Blogs”-type blog post
  • Send a nice email (asking for nothing) to 10 semi-popular, non-A list, parenting bloggers

What I did for Mastering HubSpot this week

  • Made 2 new connections that can help me with promotion
  • Did some research for my analytics chapter
  • Finished creating a tool that’ll be packaged with the book

Next week for Mastering HubSpot

  • Attend HubSpot’s Inbound conference (just for a day) and get feedback on the book

Helping others

The highlight of my week was actually the 3 phone meetings (4 if you count my Mastermind meeting) I did with fellow product people to impart some advice and feedback on their current projects.  This reminded me of a great blog post by Joel Gascoigne of Buffer:

When we were making just $20 per month with Buffer, I had the feeling that I couldn’t help people: I wasn’t successful yet! What I’ve found, however, is that I could help far more people when I was at that stage. I believe you can too, whatever stage you’re at.

Email me or post a comment if you have any questions or feedback.

Also: should I split Mastering HubSpot and Munchkin Report into their own posts?  Let me know.

Building Software in Public

I’ve been relatively silent about my SaaS side product, Munchkin Report. Well, that’s about to change: I’ve decided to post everything I do—marketing, sales, customer development, engineering, etc.—publicly here on my blog. Let’s see what happens!

This is a big step outside my comfort zone.

Then why do it? Well, because every time I see someone open up their books (Patrick McKenzie, Pat Flynn, Nathan Barry), their candor only accelerates growth.

So, here goes nothing…

Munchkin Mascot

Current status

I launched the sales site a couple of weeks ago and I’m trying to build an early access list and generate traffic and buzz while continuing to work on the application (which is about 60% code complete).

I’m building an audience from scratch with the help of my wife, Melissa, who’s my co-founder and an extremely talented writer with lots of great things share with our target audience of busy parents. She’s our secret inbound marketing weapon.

I will not write any more application code until I have at least 50 people on the early access list.

My biggest obstacles

I have a fairly demanding day job, which I really enjoy. I’m a marketing director for a fast growing software company and I manage a team of people, and I refuse to let my side projects interfere with my full-time gig. I also have a fairly busy family life, so I’m lucky if I can eek out 6-8 hours of work per week on Munchkin Report.

Despite being stretched dangerously thin, I’m simulateously writing a marketing ebook called Mastering HubSpot. I know this is a bad idea, guys.

All of the smart people I talk to say to go all-in on one thing at a time. Focus, Rob! But I’m hoping I can juggle for just a couple of months until the book is done and hopefully yields me a quick win. Famous last words.

What I’ve done already

  1. Coded and designed about 60% of the web application (Ruby on Rails)
  2. Wrote copy for, designed, and launched the sales site
  3. Published 2 blog posts and shared them on social media (to essentially no one)
  4. Created a Twitter account, Facebook page, and Pinterest page
  5. Followed a bunch of relevant people (mostly mommy/parenting bloggers) on Twitter
  6. Began compiling a list of influencers in my niche (with name, email, date of last contact)
  7. Commented on a few relevant blog posts and forum threads to build my reputation/become

Next week

  1. Post and promote 3 more blog posts
  2. Pitch a guest blog post to a couple of target blogs
  3. Create and publish a free printable daily activity sheet PDF with Munchkin Report branding

Stay tuned for more updates, which I hope to publish weekly.  I’ll probably do the same for my ebook.

I hope this keeps me accountable and also inspires other bootstrappers that are following along to forge ahead.

Status Boards and Company Culture

One the most fun and useful things I’ve ever built is the Fog Creek Big Board.

Will Thompson, one of Fog Creek’s talented summer interns, cleaned up my hideous code and open sourced one of the board’s neatest components: the Solari board.

Solari Board

Status boards are pretty common fixtures at software companies these days, but, let’s face it, many of them are nothing more than eye candy.  Of course you want your status board to look pretty, but building one that’s indispensable is the real challenge.

Man, the Big Board was soooo useful.

The Big Board quickly became the centerpiece of our customer support workflow. In a way, it was a graphical representation of the Fog Creek customer service philosophy.

I can’t take credit for the board’s success, though. I did much of the design, but the Big Board was the brain child of Rich Armstrong, who is not only a master of process improvement, but has a keen ability (super power, even?) to cut straight to the core of the thorniest technical–and sociological–problems.

I remember the discussion between Rich and I about what we should put on the board. I thought, “What would look cool?” Then Rich said, “So, what behaviors do we want to reinforce?” Ah, yes, of course.

We wanted to:

  1. Respond to customer phone calls according to schedule
  2. Respond to support cases within 1 business day
  3. Reduce our Fix It Twice backlog

And so we added our call schedule to the Solari board, front and center. As soon as a support call was scheduled and assigned, the train board clattered subtly and everyone on the team knew about it.   Calls wouldn’t be missed.

In the upper right-hand corner of the Solari board there was a small digital clock displaying the time our next support case was due for a response, in accordance with our 1 business day SLA.

The color of the clock was highly relevant, too:

  • If there were cases in the queue that were overdue, the clock turned red.
  • If cases were due within our business day window, the clock turned yellow.
  • If we managed to close all the near-term cases, the clock turned green. We called this “greening the board.”

Around 4pm every day, we’d jokingly rib the person that was preventing the board from turning green. Then we’d all pitch in to help, like we were on a World of Warcraft raid, until our mission was accomplished and we could reward ourselves with a beer and random discussion about web frameworks or classic movie references I didn’t understand.

Some days we’d green the board super early, which meant we could take the rest of the day to work heads down on our side projects, only stopping with the clattering of the Solari board.

Lastly, we displayed a raw count of Fix It Twice cases in the backlog. If this number exceeded a threshold we set, it signified that, once our calls and near-term cases were in order, we should trim the backlog before digging into project work.

Incentives: aligned.

These 3 simple indicators, all provided by the Solari board, kept our processes running smoothly and made our customers, and our team, happy.

Ask yourself: What metrics underly my team’s culture?  And how can I make them public, actionable, and fun to affect?

Other posts on the Big Board:

HubSpot Gotcha #1: Identity De-duplication

This post is an excerpt from my upcoming book — Mastering HubSpot. Sign-up for the pre-launch list to receive an exclusive discount.

This gotcha is one that most HubSpot users have no awareness of, but are affected by. Even if you take no action after reading this, it’s very important to know how identity de-duplication works.

Envision the following scenario, if you will.

You e-mail a list of prospects to promote an exclusive webinar. One of your prospects, Dwight Schrute, opens the email and thinks, “Wow! This is the most amazing webinar topic I’ve ever seen!” He clicks the link, fills out the web form, and registers for the event.

Then, it occurs to Dwight that his collegues Jim and Pam would also love this webinar, so he reloads the landing page and registers them, too.

Not only did your champion Dwight reconvert, but now we have 2 new leads from Dunder Mifflin to nurture. Awesome, right?

Not so fast.

What actually happens

Behind the scenes, all 3 form submissions are merged into the original Dwight Schrute contact record! Because each of the form submissions happened within the same browser session, with the same cookies, we don’t get new contact records for Jim and Pam.

In fact, the very last form submission steals Dwight’s identity. Now Pam is the only Dunder Mifflin lead we have in HubSpot and all of Dwight’s prior activity is attributed to her.

Perhaps the worst of it is that you have no way of knowing when this happens. Brand new leads can evaporate and you wouldn’t even know it.


5 minutes ago this was Dwight’s profile. Now it belongs to Pam:

Pam steals Dwight's identity

Common causes

There are other common scenarios that trigger this problem, as you can imagine. The two that I find most commonly are:

  • People sharing computers
  • A salesperson or VAR registering on behalf of a customer/prospect (this is a big one)

The logic

HubSpot’s identity de-duplication logic works like this:

  • If the user token stored in the browser’s cookie matches an existing contact record, form submissions from that browser session will be merged into the existing contact record regardless of the data being submitted
  • If there’s no cookie match, form submissions will de-duplicate based on email address
  • If the email address being submitted doesn’t match an existing contact record, a new contact will be created

The rationale

The rationale behind the way HubSpot de-duplicates is based on a concept called sandbagging.

The idea is this: Dwight browses your website a few times. You’re tracking his movement with a cookie. Eventually, he downloads an ebook with his address because he doesn’t trust you yet.

At that moment, all of Dwight’s previously anonymous activity is associated with his new identity

The ebook is legit and two weeks later Schrute requests a live demo of your product from the sales teams. This time, he uses

Now, HubSpot doesn’t want to create a new contact record just because Dwight’s email address changed. Doing so would mean that we wouldn’t associate any of the activity (visits, submissions, etc.) that occurred prior to requesting the demo.

Alternatively, by using the cookie to de-duplicate the identities, HubSpot can group all of Dwight’s historical activity under one record.

In the example above, and in many cases, this behavior is exactly what we’d want.

How KISSmetrics does de-duplication

As an aside, KISSmetrics, an analytics app that focuses on tracking people, runs into the same exact problem, but they handle it differently. As soon as a form submission (or some other identifying event) occurs, KISSmetrics creates a new identity and begins attributing activity in the browser session to that new identity.

Best practices for preventing lead merging

First, tell salespeople and VARs to always use an incognito browser window or clear their cookies when submitting forms on behalf of prospects and customers. If they’ll listen, great! Unfortunately, this won’t work for people outside of your organization (e.g., the Dwight, Jim, Pam scenario), but I’ve found the biggest offenders are inhouse.

Another option–which I would only advocate if this problem is killing you–would be to use your own forms (not HubSpot’s) and send the form submission data to HubSpot via the Forms API without passing the user token. There are major drawbacks to this workaround, mainly with respect to activity tracking, so I won’t detail exactly how to implement it. Visit the HubSpot API Google Group if you have questions about this.

The way forward

HubSpot opted to solve for the sandbagger problem over the lead merging problem. Personally, if I had to choose between the two evils, I’d have done the reverse (a la KISSmetrics).

The reality is, however, that in the vast majority of cases, all form submissions are done by a single person under a single email address and you don’t have to worry about lead evaporation or sandbagging.

My proposed solution, which I’ve discussed with the product manager at HubSpot, is to give portals a checkbox that forces de-duplicate based on email address instead of cookie.

From this HubSpot Ideas thread, it looks like they might implement this suggestion at the form level, which I’m also cool with!

Another terrific option would be to provide a way to quickly produce a report that shows you all contact records that have been aliased/de-duplicated with a side-by-side diff of the former and current data and a big button labeled SPLIT that let you untangle the contact records if it makes sense to do so.

Be the first to hear when Mastering HubSpot is released!

Signup for exclusive content, a discount, and progress reports.

We will never spam you. Unsubscribe at any time.

Rob Walling

The Dangers of Projection
(Or Never Bet Against Rob Walling)

projection pro·jec·tion (prə-jěk’shən) n. – the attribution of one’s own attitudes, feelings, or suppositions to others.

Projection is a dangerous thing in business, especially when it comes to marketing.

Marketing is all about conducting experiments. The only way you can truly know whether a tactic will work is to test it and measure the results. In my experience, if you try 10 things, 2 will work.

My brain knows this is the best way to do marketing, but I still have to fight my emotional instinct to kill ideas before trying them. This instinct, more often than not, is due to projection.

Some classic examples of projection in marketing:

  • We shouldn’t bother with ads—I never click on ads.
  • We shouldn’t build a product for developers—I’m a developer and I never buy things.

Now, about Rob Walling.

I was a marketing n00b sitting in the Boston Seaport amphitheater at Business of Software 2010, having just listened to Dharmesh Shah and Jason Cohen drop enough startup wisdom to pay for the entire conference, when a speaker I didn’t recognize took to the podium.

Rob Walling’s claim to fame, as far as I could tell, was selling beach towels online. Umm, okay.

The thesis of Rob’s talk was that you shouldn’t ask for a sale as the primary call-to-action on your website. Instead, ask for an email address and sell to them over time.

Rob argued that people rarely make a purchase decision on their very first visit to your site and, worse yet, the vast majority of people will bounce and never come back. To combat this, you should offer something of value (e.g., an ebook or email course) in exchange for their email address.

That sounds…scammy.

Maybe this works for beach towels, but any SaaS business that tries this tactic is surely going to repel their prospects. They’d repel me.

Boy was I wrong.

My projection was so strong that I discredited Rob’s years of experience and overlooked the abundance of empirical evidence he had to support his claim.

I’m glad I took notes during Rob’s talk, despite being incredulous at the time, because his advice on capturing email addresses is integral to every marketing plan I build. It has never failed me.

Unsurprisingly, Rob now has a SaaS product that makes it dead simple for companies to collect email addresses and nurture leads through drip marketing. Will it succeed? I can’t say—but I’m never betting against Rob Walling.