Fake It

We’ve all heard the adages.

“Fake it ‘til you make it.”

“If you’re not cheating, you’re not trying.”

“Appear weak when you are strong, and strong when you are weak.”

Fake it Til You Make It

These sayings are motivating, but they advocate too heavily in favor of deceit. Should you really spend years as a fraud, hoping you’ll “make it”? Is being honest with yourself and others really so bad?

This is my first time at the helm of a business and as a member of a team that depends on me so much. Lately, I’ve been thinking about these questions a lot and how they shape the decisions we make as a team.

Appcues started as a really scrappy venture, and that’s something I’m really proud of. However, I’ve realized when you’re fighting like a rabid animal every day, you forget how to behave among humans.

For startups, that problem manifests as:

  1. Over-selling products or services you don’t yet have.
  2. Saying everything is great when it’s not.
  3. Avoiding asking for help from people you admire.

Some things are (arguably) necessary, like validating demand for your product/service through pre-sales. That’s something I’m a huge believer in and practice avidly. But there’s a line, and the more it’s crossed, the fainter the line becomes.

Going Too Far

The tough reality is that this isn’t a binary choice. A leader’s job is to sell the vision of a better future, and the most farfetched visions are galvanized through positivity. Practicality is not what inspires people to achieve great things. That subtle conflict is where we are at risk, and it’s worth our conscious thought.

These days, I try to reflect on things I’ve said or done. How accurate was the impression I just gave? Was there another way to achieve the same goal?

I count myself lucky to have a team who values transparency and doesn’t shy away from hard truths. As a result, honesty is an even more powerful motivator than false optimism. It makes the highs higher because the success is genuine, and the lows are short-lived, entrusted to responsible adults.

How to Design an Embed Script

Start writing For the past year, I’ve been researching third-party client libraries. Like Google Analytics or Optimizely, Appcues gives its customers a snippet of Javascript for them to embed on their site. I’ve studied dozens of embed scripts and have learned a ton through our own customer implementation.

If you’re building a third-party client library, this article is for you.


There are a handful of things you’ll need to decide before you dive in:

  • Synchronous or asynchronous?
  • Do you offer an API?
  • How frequently will your script or API change?
  • Are you rendering content (js, css, html)?

These decisions may seem easy to make, but they’re far more complicated to execute properly.

They myth of synchronous javascript

The choice between sync vs async has actually been made for you. The short answer: always assume you’ll be loaded asynchronously.

Until just a few years ago, blocking js patterns were the norm. Some scripts started loading themselves asynchronously (think Mixpanel or KISSmetrics), but in either case, those script tags were added to the HTML just as Mixpanel or KISSmetrics provided them.

With new loading conventions like AMD and CommonJS, embed scripts have little say over how they’re loaded. Because of that, you should always assume your script will be loaded asynchronously, so it should be designed accordingly.

How to expose an API

If you believe in the above, there’s only one right way to expose your API, and that’s as a queue. There are a couple of patterns you can use to do that:

1. Expose an Array

This is how Google used to do it, and how most libraries still do it. Basically, you expose an array and fill it with calls, like this:

window._gaq = window._gaq || [];
_gaq.push(['track', 'pageview', {some: 'data'}]);

This method is well known, easy to design, and it exposes a consistent API. The main disadvantage is that the consumer has no idea what API methods are available.

2. Expose a Function

A similar alternative is to expose a function which essentially does the same thing. This is how Google now does it with their Universal Analytics script.

window['GoogleAnalyticsObject'] = 'ga';
window['ga'] = window['ga'] || function() {
    (window['ga'].q = window['ga'].q || []).push(arguments);
window['ga'].l = 1 * new Date();

var scriptEl = document.createElement('script'),
    firstScript = document.getElementsByTagName('script')[0];

scriptEl.async = 1;
scriptEl.src = '//www.google-analytics.com/analytics.js';
firstScript.parentNode.insertBefore(scriptEl, firstScript);

It’s almost identical to the array method, but calling methods now feel more natural and less error prone. When the real js script finally does load, you also have just one stub function to override, and it’s not the native Array.push.

3. Expose Stubs

Mixpanel and Segment.io use this method. This technique initializes an array with stub methods, each with their own queue.

window.analytics = window.analytics || [];

// A list of the methods in Analytics.js to stub.
window.analytics.methods = ['identify', 'group', 'track',
  'page', 'pageview', 'alias', 'ready', 'on', 'once', 'off',
  'trackLink', 'trackForm', 'trackClick', 'trackSubmit'];

// Define a factory to create stubs. These are placeholders
// for methods in Analytics.js so that you never have to wait
// for it to load to actually record data. The `method` is
// stored as the first argument, so we can replay the data.
window.analytics.factory = function(method){
  return function(){
    var args = Array.prototype.slice.call(arguments);
    return window.analytics;

// For each of our methods, generate a queueing stub.
for (var i = 0; i < window.analytics.methods.length; i++) {
  var key = window.analytics.methods[i];
  window.analytics[key] = window.analytics.factory(key);
// ...

Unlike the basic array method, this technique lets the consumer see what methods are available, but with one major tradeoff: your API can’t be updated without asking consumers to update their embed scripts.

Safely adding content

This is a huge topic, and one that will constantly be evolving with browsers. As it stands today, the major things to remember are:

  • Sandbox your content in an iframe.
  • Escape HTML and watch for XSS vulnerabilities.
  • Don’t assume the DOM has loaded before injecting content.
  • Create your own element tags to ensure CSS namespacing.

Getting fancy

I’m a huge fan of Google’s new embed script. The minified version is so damn efficient, and they cleverly define the variables they need without using the var keyword.

    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)

The coolest thing about their script is that the closure’s arguments spell the word isogram, which means “a word or phrase without a repeating letter”. It’s so meta I love it! Swoon. As an added benefit, they forego the need for variable definitions or scoping via the var keyword.

Implementation is crucial

Pick the right tool for the job

While it’s really nice to have the one-line install script, it’s often not the best option. If your script needs to be loaded quickly and used asynchronously, you’ll need a queue-based embed script. If you’re just servicing WordPress installations or have full control over how your script gets loaded, the one-line install is more feasible.

Another avenue to explore is framework middleware. Intercom.io did a good job of building middleware libraries for Django, Rails, etc. that inject themselves into the page. It’s a handy way to control the implementation and have a better path for upgrades.

Going beyond

There are tons of things I didn’t cover in this post. Caching, initialization, and draining the queue could be blog posts of on their own.

If you’ve seen an embed script pattern you really like, I’d love to hear about it! If there’s a particular topic you think I should dive into more, let me know too.

The Words Every Founder Needs to Hear

I got the chance to attend the Nantucket Conference this past weekend as a young entrepreneur. Over three days, I heard countless stories of success through failure, and I’m convinced that the best entrepreneurs are the ones who heard, “No, your idea sucks,” and kept on going.

Don't take no for an answer

Not just any conference

The Nantucket Conference is a concentrated gathering of some of the smartest, most influential people in the northeast tech startup community. The event is sometimes criticized for its selectivity and price tag, but these same restrictions create an intimate, obliging environment that you won’t find at large events.

As an invited young entrepreneur, you get to see investors and high-profile entrepreneurs in their natural environment. And surprisingly, they actually get along quite well.

Overcoming the naysayers

Almost every one of the speakers had some story of an investor who told them, “no.” In Slava Rubin’s case, he had 95 storied investors, some of whom were in attendance that weekend. Each of them, from Neil Blumenthal to Gail Goodman, were written off by some of the most experienced people in the industry, then set out to prove them wrong.

As an attending entrepreneur, you get a first-hand lesson in hearing “no” in at least one of its many forms. It was inspiring to partake in this tenuous culture of give-and-take while simultaneously bearing witness to the great companies it’s created. I think it’s one of the few times one could feel good about being told no.

The reality is that, in the early days, every startup will hear more “no” more often than “yes.” In a panel titled, “Avoidable Mistakes,” Dulcie Madden shared that amid these challenges, founders need to present a “copacetic calm” to their team, board, investors, etc. Everyone’s startup is a mess, and embracing that fact without freaking out is just how things are done.

How to survive the crazy

Mentors are invaluable. A couple of the conversations I had at the conference completely reframed some of the problems I’ve been struggling with. Anyone can give advice, but only certain people can provide perspective.

Find a peer group. Madden and Goodman hinted at this in their talks. You need a peer group of people who understands what it’s like to smile while everything you’ve built is burning down. You can only bottle that up for so long before it drives you mad.

Good people are out there. Find them. There are smart, talented people who will go out of their way to help you, the Nantucket Conference just had a high concentration of them. People like David Chang, Andy Miller and Karl Büttner are actively trying to donate their time and energy to Boston entrepreneurs through different initiatives, and there are many more people like them.

Three of my biggest champions over the weekend were Brent Grinna, Karl Büttner and Simeon Simeonov. Despite knowing almost nothing about me, each of them went out on a limb to introduce me to others. Brent even pitched my startup, Appcues, to Joe Caruso!

This weekend revealed a strong undercurrent of camaraderie building within Boston (and New York). As these startup ecosystems mature, more entrepreneurs will (hopefully) reach back to help the next generation, creating the same virtuous culture that’s commonplace on the west coast.

For northeast entrepreneurs, overcoming “no” is as important as convincing future entrepreneurs, “Yes, you can do it, too.”

Make things happen, Boston (and NY too, I guess)

The Startup Hierarchy of Hard

Climbing Yosemite mountains without a rope. That's hard.

Turns out the things that I thought were hard (concurrency, caching, etc.) aren’t quite as hard as all the other stuff involved in running a startup. Here’s my take on what’s hard about startups:

8. Thinking long-term.

Taking short-term rewards and direction from a big customer can be ruinous for a startup. Ignoring the company’s vision and taking the money is tempting, especially when there are bills to be paid and funding is “just around the corner.”

7. Trusting others.

Founders need to trust other people to own parts of the business. This means hiring someone who is great at something you’re terrible at and having the humility to help them get even better.

6. Maintaining a healthy lifestyle.

It turns out that it’s extremely easy to work non-stop on something that’s interesting and meaningful. That’s a powerful thing (and a good sign), but don’t abuse that power. The human body is weaker than the impassioned mind.

5. Building/saying/doing (aka execution).

Execution is extremely difficult, and it’s what differentiates good teams from great ones. When working at a comfy job doing a specialize trade (engineering, marketing, etc.), this can feel like a formidable challenge. Yet, it isn’t as difficult as this next point:

4. Knowing what to build/say/do.

A great engineer can build anything, but how does she know what’s worth building? Being good at this skill requires a broad blend of interpersonal skills, like empathy and self-awareness, and the discipline to apply them again and again without bias.

3. Finding good people.

Despite advancements in communication and technology, finding great people is still incredibly difficult. Whether you’re looking for a co-founder, first hire or nth hire, someone who is a cultural fit, technically qualified and at the right time in their life is tough to come by.

2. Bouncing back from rejection.

In the beginning, startups hear “no” a lot more than “yes.” And by a lot, I don’t mean 4 in 5 times, I mean 95 in 100. Many yes’s are actually slow, polite no’s. Founders need the ability to end a 2-hour sales call, knowing full well that the prospect won’t buy, and immediately take the next call with unwavering positivity.

1. Riding the roller coaster.

Lots of things are going to go wrong. Even worse than wrong: sometimes nothing will happen. Other times, you’ll feel like you’re on a rocket ship, the kind that’d make Elon Musk blush. Successfully riding the startup roller coaster means fighting through the lows, celebrating the highs, and always appreciating the journey.

Despite the published statistics, nay-sayers and the seven other less difficult challenges mentioned above, you’re surviving, miraculously.

These are from my experience starting Appcues and other horror stories gleaned from friends. If you’re a founder, I’d love to hear your take.

Huge huge thanks to Ryan Hoover, Anand Rajaram, Mike Champion, Ezra Fishman and Brendan Schwartz for sharing their stories.

Pulling off the Bandaid

No one said this would be easy.

It’s been a crazy couple of months and my first time riding the infamous startup roller coaster. In January, Appcues got a nice boost in leads and customers with almost no effort. I was riding high, thinking about how I’d be able to find my first hire, office space, etc.

As I was onboarding customers, I also started setting up metrics to gauge customer engagement. I even whipped up a sweet internal dashboard that showed my customer health. At the time, hacking my own dashboard felt like an indulgence. In hindsight, it was probably the single best thing I’ve done so far.

After spending a couple of days building that sweet dashboard, I realized that my customer health was redlining. People who were actively paying me money (for months!) weren’t using the product. They hadn’t even set it up. It turns out that I had completely misunderstood the problem those customers had: no time. The kiss of death.

Fast-forward to today, and I’ve churned a majority of my customer base, mostly by proactively reaching out and suspending accounts I know will never be used. Making those phone calls was tough. I also had a handful of companies who signed up because they liked me, not because they needed Appcues. That’s the wrong kind of revenue, so I had to cancel those accounts too.

The past few weeks has made me realize that starting a company is easy. Building software is easy. Even finding customers isn’t that hard. Having the courage to see your work (and yourself) honestly is hard. Waking up every day and saying, “I’m going to fucking crush it” is hard. Mustering the strength to pick yourself up when you fail (and you will) is hard.

So if you’re an aspiring entreprener and are worried about not having a good idea or a technical cofounder, let me be the first to say, “Relax.” That’s the easy stuff.

The Heebie-Jeebies

This post is the first (and only) speech I gave at HubSpot’s Toastmasters. Spoiler alert: it’s not startup related.

This 1920's graphic makes heebie-jeebies seem like a back cold

One of my favorite things about growing up in Hawaii is the food. Perhaps one of the only advantages of being stranded in the Pacific ocean is an abundance of fresh, delicious, and pretty affordable varieties of fish. It was hard to not be surrounded by the stuff growing up in Hawaii. In my neighborhood, there was always someone parked on the side of the road selling fish they caught that day.

At some point in high school, my dad really got into making ahi sashimi. I wasn’t a big fan of it at first, but it was around enough that I ate it regularly anyway. We usually coupled that with other similar dishes, like poke–usually raw, cubed pieces of tuna, seaweed and some seasonings. Several of these tuna-heavy dinners when by uneventfully, until one night when I got a strange sensation at the table: annoyance. It’s a weird feeling to suddenly get, but I remember it distinctly. I felt like I was late for something really important but had to be polite and stay put.

Over the next hour at dinner, I became fidgety and restless. My hands started tingling, and the feeling moved up my arms and became warm until, eventually, it felt like the tips of a thousand hot, tiny needles were being pressed against my skin, but from the inside.

I stayed up after dinner, uncomfortably squirming while watching television, and the feeling went away a little while later. So I did what any teenage boy would do: I turned off the TV, brushed my teeth, went to bed, and didn’t tell anyone.

That was probably a stupid thing to do, but I was wreckless at that age. That was also around the time when I started getting interested in sports, and swallowing a bit of discomfort probably seemed like a small price to pay to the world’s scrawniest athlete-in-training.

It wasn’t until it happened a few more times that I finally told my parents. The thing that got me worried, was that I wasn’t getting it just from tuna. I got that feeling again whenever I had a big sandwich or more than one helping of soup. There was no pattern to it (unless you count a bit of gluttony).

When preparing this speech, I thought about opening with something more shocking, like, “I live in the shadow of a specter” to poeticize some unknown harbinger. But that wouldn’t really be true. From what I can tell, this sensation isn’t life-threatening. It’s not even visible, and the name my dad gave to it, “The Heebie-Jeebies,” isn’t very specter-like.

After describing it to my parents, my dad admitted that he gets the Heebie-Jeebies too, and has been getting it since his 20s or so. So far, we’re the only ones in our 7-person family who have it. To this day, my dad doesn’t know why he has it, what causes it or if it’s genetic, which is the fact most people find unnerving.

I guess we should be worried, but we’re not. I’ve lived my whole life eating (almost) all the awesome food my family makes, and so has my dad. Even in a highly Americanized Asian family, a fish diet isn’t something one just gives up.

I did some cursor research on the Heebie-Jeebies, and the closest things I’ve found suggests it’s some protein allergy. Through the “scientifically recognized” process of trial and error, I’ve narrowed it down to the following rules for myself:

  • White fish is OK in normal quantities.
  • Red-meated fish are pretty bad, especially swordfish and sock-eye salmon.
  • I’m also allergic to chicken and chicken broths in large quantities, but chicken caught in the wild are somehow fine.
  • I get Heebie-Jeebies from processed pork and turkey, too.
  • For some reason, cooking in lemon seems to make it a bit better.

Those rules have been good enough for me, but they didn’t sate my worrisome girlfriend who recently convinced me to get allergy tested. So I made an appointment a few months ago, talked to my physician, and left with the advice to simply not bother getting tested. According to him, the chance of pinpointing the cause is slim without extensive testing. “Even then,” he said, “at the end of it, they’ll probably just tell you to avoid fish and poultry, which is you’ve already been doing.”

Besides, I figure there are far more serious allergies to have. Nuts, pitted fruits, shellfish or (god-forbid) bacon. Some of those can cause serious symptoms and can be a pain in the ass to avoid, while my dad and I just have to exercise some restraint over holiday dinners.

So, for now, I have my rules, my WebMD articles, and the apathy of a certified practictioner, which, for my dad and I, have been enough to leave the Heebie-Jeebies be.

Starting Fires

This is how it feels to work on a startup sometimes.

If there’s one thing I’ve learned this past week, it’s that when starting a fire, don’t question the sparks. Just fan the flame.

I was really hoping to get some coding done last Thursday. Instead, I spent that and the following five days scrambling to put together a marketing campaign for an unexpected surge in new leads. The kicker? We couldn’t accept any new customers.

Basically, we had a great opportunity at the worst possible time. Here’s the story of how we made the best of it.

This new traffic surge came from Product Hunt, a sort of Hacker News for products. Members submit products they think are cool, and the community votes on them, floating the best to the top. Ours was casually submitted by Ryan Dawidjan, a true #hustler with a keen product sense. Ryan actually helped me do customer development for Appcues in the way way early stages, which made him among some two dozen people who actually knew about Appcues at all.

The company was starting private beta, so we weren’t planning to handle any more customers for another month or so. But here was this nice little spark that had the potential to become something.

At Nathan Bashaw’s recommendation, I did an AMA in the PH comments. We sent out a couple of tweets and a bunch of my old coworkers (organically, I swear) found the post and shared some karma.

By the end of the day, we had over 75 high quality leads, and more were expected when Product Hunt’s morning digest went out. The total was 134 qualified leads in 3 days. Appcues is built for product people (product marketers and managers), so the PH leads were HOT.

We hit our visits and leads goals for the month a bit early.

That might not seem like a lot, but for our size, it’s a mountain. We were in a position I think many business owners fear: a surplus of customers, a shortage of inventory, and only ourselves to blame. We decided to keep fanning the fire.

We quickly published a landing page and email campaign to learn a few more things from these Product Hunters while we were still relevant to them:

  1. Was the pain that they felt around onboarding bad enough that they’d commit money without even seeing a screenshot?
  2. Could we actually communicate that we’re building a product to solve that pain?

As it turns out, they did need a solution, and we were mostly able to communicate the value of ours. Getting featured on Product Hunt has been an amazing (albeit nerve-wracking) experience for us, and we hope to give back to that community over time.

By all accounts, I’m a “planner,” and Appcues already had a marketing strategy. We could have decided the timing wasn’t right and ignored the surge, but I’m really glad we didn’t. I’m learning that timing will almost never be perfect, and a startup simply needs to make the best of every good opportunity.

Huge thanks to Ryan Hooover & Nathan Bashaw for creating PH and helping fan the flames. And a special thanks to Hiten Shah and Anand Rajaram for their sage advice and honest feedback when I was freaking out over what to do.

Find Emails With No Reply

Gmail No Response in Priority Inbox

Ever send out an email but got no response? Some people (myself included) aren’t great at email, and they just need a small nudge or reminder. I use tools like Signals to get notified when someone opens an email and FollowUp to send myself reminders to follow up, but I wanted something more automated.

What Does It Do?

This script creates and manages two new labels: “No Response” for emails that have garnered no reply, and “Ignore No Response” for emails you don’t need to respond to.

The script periodically goes through your email and finds messages between 5 and 14 days old where you were the last person to respond. Basically, the goal is to find messages where a follow-up email would be appropriate.

How to Install

Visit the Google Scripts site and create your first script. Scripts are stored in Google Drive, so you can edit them there later on.

Then, get the Gmail - No Response script and paste it into your new script document. At this point, you can also modify the variables at the top of the script. These will change the label names and age thresholds.

Next, click the clock icon to create a trigger that will run this script on a schedule. I set mine up to run daily at midnight:

The triggers UI is pretty underwhelming

Make sure to save your work!

You’ll now have two new labels in your inbox that you can check and do stuff with. If you want to keep those top-of-mind, you can add the “No Response” label to your main inbox. Just go to Settings > Inbox > Inbox Sections, and add the “No Response” label:

Add the No Response label to your inbox

Now sit back and enjoy!

Why Not Use FollowUp or Boomerang?

As Chris Keller later pointed out to me, FollowUp has a Chrome extension that will auto-populate the BCC field for you, and I assume Boomerang has something similar. I wrote this script before I knew that, and I think it’s a better choice for me because:

  1. It works on emails you’ve already sent.
  2. It involves no third-party services. Your email stays put.
  3. Each user has code-level control, in case they want to go nuts.

Some emails I send are sensitive, and I’d rather not forward it to a third-party service if I don’t have to. However, those sensitive emails are often important, so I need a way to remember to follow up.

To Be Continued

I love finding ways to be more productive, and I’ve been making an effort to share more of that knowledge. If you like this project and want to keep tabs, you can subscribe to the Github repo. I might add more scripts there in the future.

A Modern Front End Stack

Building Appcues has also given me the chance to start with a fresh tech stack. As a frontend guy, I’ve always dreamed of a single language, no backend setup that let me move quickly. Hopefully this will be helpful for other frontend devs looking to build new apps.

In a Nutshell

Here’s what I ended up with:

A picture representing A Modern Front End Stack Arcade of dreams, by Chris Danger.

The Goals

Goal #1 was to have no middle layer—not even node. Middle layers are great for processing data, but they also add extra overhead. That overhead then requires even more overhead to keep it fast, and so on and so on.

Goal #2 was that I wanted something free or nearly free. For me, this also meant looking for vendors that would let me grow to 100 customers before I needed to pay.

And goal #3 was to have an efficient system. I didn’t want to get bogged down by deploy processes or have to remember to do tricky things in order to not break something crucial. I just wanted commit code and let something else take care of it.

Basically I wanted HubSpot’s infrastructure for free.

The Advantages

Brunch has a simple config and a bunch of open source plugins, which is usually nice. I can see myself outgrowing it soon, but it’s hard to match it in terms of quick development. If you just want to build a simple single-page app for Github Pages, Brunch is a great choice.

Firebase is a pretty good BaaS provider. Their API is extremely fast and reliable (so far), and the fact that data is updated in realtime is nice. They also have a decent Backbone integration library that makes good use of their realtime updating. It basically means that everything that you see on the frontend has been (or eventually will be) sync’d to the database.

I got invited to try out Divshot.io before the beta, and so far it’s been really awesome. They provide some nice things out of the box that make it a much better alternative to Github Pages.

  • Custom routes are great if you’re using pushState.
  • Separate development, staging and production enviroments created for you.
  • Awesome command line deployer that lets you “promote” environments.
  • You can set custom cache headers in your config file!
  • Custom domains.

In addition, the Divshot team has been super responsive whenever I’ve run into issues. They even helped me to get it working with Wercker.

Ah Wercker. This is the “advantages” section, so I’m going to hold back on them. They’re a CI service and FREE. The builds and deploys are actually really fast (faster than at HubSpot) and they benefit from having a community of people building boxes and steps. Their support team has been pretty good too.

The Disadvantages

Getting Wercker to werck was a pain in the ass. There is no debug mode, so the only way to test changes is to push commits to your repo. Not super fun. Their UI is also way too AJAXy, and laid out in a weird way. I feel like I have to click a bunch just to figure out how my build is doing.

In comparison, Divshot has been a walk in the park, and Firebase just took some getting used to. Unlike some other BaaS providers, Firebase doesn’t have a WHERE clause, meaning you have to store the data you want in it’s own index if you want to get it quickly.

That last part is especially important if you have no backend. If I want to find all the users named Joe, my options are either:

  • Be constantly updating a new index called people_named_joe.
  • Download all users to the client, loop over them and pluck out the Joes.
  • Don’t offer that feature.

Jury is still out on that one.

How it Works Together

It all starts with a commit.

  1. Push commits to Github.
  2. Wercker is notified of the commit and gets the code.
  3. Wercker sets up an environment and builds two versions of the project (dev and prod).
  4. Wercker runs the tests and bails if any of them fail.
  5. If everything passed, Wercker queues up deploys to Divshot.
  6. If the deploys are successful, Wercker tags the git commit with the environment name.

In the future, I plan to use Divshot’s promote command better so that builds go from staging to production after a certain amount of time or perhaps some extra tests are run. Not sure yet. The git tagging is just a convenient way for me to keep track of what is currently deployed.

And that’s it!

Save Yourself the Headache

If you’re interested in using this stack, I highly recommend using my Wercker config. It’ll save you a lot of headache trying to figure Wercker out.

Two Weeks on the Outside

The Journey Ahead

I knew starting out on my own wasn’t going to be glamourous. I knew that. It turns out it’s even less glamorous than I thought.

Maybe I’m just not doing it right, but the “hustling” I’ve been doing hasn’t felt like the hustlers of lore. That is to say, I don’t feel like a well-dressed, ex-collegiate lacrosse player who zips around town and signs deals over cocktails.

My typical day consists of me emailing people from my house, in sweats and a hoodie. Or riding my dilapidated bicycle 30 minutes across town to talk to someone for 60 minute about what they struggle with at work. Sometimes I meet people at coffee shops, but I never buy anything because I need to save money.

So it feels more like being a poor therapist with a nice computer, and I fucking love it. If you’re thinking of starting out on your own, here are a few tips that have helped me so far:

1. Learn to Say No.

I originally had this as #4, but it deserves to be near the top of the list. I’ve already written about how to say no effectively and highly recommend picking up that skill. Knowing how to say no to people, expenses and yourself will help you stay focused and disciplined.

2. Practice Lean Before Living It.

This was a tip I got from the guys at Wistia and probably the one I’m most fortunate to have put into practice. It’s no secret that your runway will be longer if you can get by with less, but doing that isn’t simple. The best thing to do is to start early and cut back (aggressively) over a period of time.

This gets easier as you start seeing gains. In the beginning, a $5 cup of coffee might seem like a trivial amount of money, but it becomes a larger percentage of your burn rate as you cut back. Knowing how to frame your expenses will help you make the right decisions.

Some cost-saving tips:

  • Make a batch of steel-cut oats. They’re delicious, keep well and are a great breakfast choice.
  • Buy a big bag of coffee beans and a French press. You can grind beans at your local grocery if you don’t own a grinder.
  • Invest in dry meat alternatives, like beans and chick peas.
  • Bake. It’s easy, involves less active time than cooking and can satisfy your sugary cravings.

Some things to try:

  • Savory pies, like Shepard’s pie, chicken pot pie, etc.
  • Chick pea salads.
  • Steel-cut oats, honey and raisins/nuts.

3. Master the Art of the Freebie.

Now is the time to reach out to your network or hack services to get the best deals. This is your livelihood on the line, and if you want to survive, then there’s no room for meekness.

A couple of tips:

Host your marketing site on Github Pages.

I prefer Github over Heroku because it’s super fast, and the code ends up there anyway. You can use it with Brunch, Jekyll or anything that compiles to static HTML/JS. As a front-end dev, I’m partial to it since it lets me work quickly and comfortably.

Find a Google Apps account.

Google Apps for Business is pretty awesome, but it was even more awesome when it was free. If you have one, start using it. If you don’t, find someone who wouldn’t mind gifting you theirs, or at least adding you as a sub-organization. Having a proper domain for email, documents AND the ability to spin up new email addresses is clutch.

Sign up for a free account(s).

Unbeknownst to some, AWS gives a free year of light-weight service for new sign ups. If you’ve already signed up in the past, use a new email address (this is where having a Google Apps account helps). Freemium was invented for just this reason, so use it to get the services you need.

Leverage your network.

If you know someone who works at an Apple store, ask them if they’ll use their discount on you. Odds are you have friends who work for product companies and can get you deals on business cards, hosting, software, etc. Now is the time.

4. Get an At-Home Hobby.

You no longer have the lunch room or water cooler to re-energize, so find something at home you can do to supplement that. Not having some way to break up your day will make you want to work from coffee shops or co-working spaces, which gets expensive and makes you more likely to buy things you don’t need.

I’ve been experimenting with infused cold-brew coffee at home. It’s both convenient and productive, because I need to make coffee anyway, and a French press holds enough cold brew for two servings. I have a bottling kit from when I tried beer brewing, so I make a batch for tomorrow and bottle one for a rainy day. It works out great and is a nice break.

Why I Started Appcues

Reaching for Coals

Sam Siskind and I worked together at HubSpot. I think it was mid-2011 when he got everyone thinking of implementing Optimizely’s Guiders.js in the app. A bunch of us thought it could be really useful to customers if it was implemented across the entire app as “always-available” contextual help. After all, HubSpot at the time was pretty ugly and hella complicated. Customers were confused and frustrated with the product, and we wanted to alleviate that pain.

Unfortunately, Sam isn’t an engineer, and I didn’t have time to maintain these guiders whenever the app changed (HubSpot averages 200+ deploys/day). In typical developer fashion, I turned to software. That weekend, I started building a Chrome extension that would let Sam create these guiders from his browser. I got the basic functionality working in no time, but for some reason the tool just didn’t feel right.

I spent weeks polishing the design and adding animations, yet I still couldn’t get past that hump. When I finally took a step back, I realized what I was actually building: I was building a tool that made a bad UX into a worse one. I was basically helping people with broken designs to build popups. Something was fundamentally wrong, but I was stuck.

So I walked away.

That problem haunted me for over a year. During that time, I noticed other open source libraries and companies spring up. They were doing the exact same thing I had tried. I casually evaluated them, and saw they were suffering from the same challenge I did (though they may not see it as a problem).

I sat and watched as more companies and open source projects appeared, until a few months ago, when I decided something was just not right. Here’s a market that’s saturated with both free and low-priced solutions, yet new contenders are joining every month with the exact same solution. Why?

I talked with a bunch of people and sought to learn as much as I could. The founders of Kera (competitor) were extremely insightful, as were the guys at Klaviyo (competitor before pivoting). After numerous conversations, I discovered that there’s a real problem here that people are desperate to solve.

That problem is that great user experience is hard. LinkedIn, Optimizely and all the others created these tools to pull people through a complicated/confusing process—to drag them over coals. When these projects hit the mainstream, developers and product managers clamored for them. It turns out that everyone has their own product coal bed.

I started Appcues to fix this problem: to eliminate product coal beds and empower everyone to deliver amazing user experiences. Today, I leave an amazing job and a phenomenal team at HubSpot to pursue Appcues full time. I believe in this problem, I’m confident in myself, and I’m ready to serve this customer.

So here it goes.

Formula for Saying No

Saying no

One of the things I struggled with was saying “no” to people. I emailed my mentors about it, posted the question on Quora and sought advice often. The turning point came from something Dharmesh said.

Remember that your time is finite. Every opportunity you say “no” to means there’s more that you can say “yes” to.

I successfully used Dharmesh’s advice to dedicate myself to HubSpot 100%. That perspective continued to work when I was approached to work on side projects, but I still felt tempted when it came to networking. Meeting someone new seemed a one-time event, and armed with that attitude, I accrued a lot of weak and useless connections. I eventually learned that a real relationship requires constant gardening. Through over a dozen polite refusals for “coffee,” I came up with a response that’s been extremely helpful in respecting that fact.

The Best Way to Say No

Hey there,

…insert some platitude…

I want to be fair and respectful of your time, and I’m already over-extended at the moment. I hate to turn down the opportunity to meet, but would it be ok if I reached out to you when I have more time to really connect?

Breaking it Down

I want to be fair and respectful of your time.

Honestly, it’s as much about your time as it is theirs, but this emphasizes that you understand that value. True relationships take time, and connections you make over coffee or a beer are not going to be worth much without follow-on conversations. If you can’t commit to those, don’t waste their time.

I’m already over-extended at the moment.

Admit the truth. Your time is finite, and there are more important things you could be doing. If that weren’t the case, you should have hunted this person down and squeezed out any amount of downtime they have. Your time is already booked, you just may not know it yet.

I hate to turn down the opportunity to meet.

This is more than just a transition—it’s intention. In this sentence, you are very politely turning down the opportunity to meet. It is not up for debate.

Would it be ok if I reached out to you when I have more time to really connect?

Put off a meeting until an undecided time. Do not cave here by amending, “in a week,” because that adds the responsibility and expectation of a follow up. That brings in a boatload of other issues, all of which can be avoided by simply not giving a date.

The more important implication here is that you convey your dedication to this relationship. This sentence leaves the door open on good terms so that the other party doesn’t feel shut out. You appear approachable despite having no time in the near future.

Is This Disingenuous?

I don’t think so. A relationship takes time to build, and if you truly respect that fact, there’s nothing here that’s insincere. If you want, you could try ruder ways to say this:

  • Sorry, but I don’t have time right now.
  • I’m not interested at the moment, but maybe in a few months.
  • I have more important things to do right now.

I’ve gone through many variations of this. Whenever I added more stuff to that formula, I always ended up giving in to a commitment or conveying the wrong intention. This is the clearest, most succinct version I could come up with, but I welcome any recommendations for improvement.

The 500-person Startup


HubSpot now has 600+ employees, yet, until recently, everyone you talked to said they worked "at a startup."

The Hollywood image of a startup looks like two disheveled people working late nights in a tiny apartment; ramen, Red Bull, thick-rimmed glasses. When we think of Silicon Valley startups, we think of seed-funded 20-year-olds in a beautiful office space; standing desks, coffee, NERF guns.

HubSpot is neither of those. The company is over 7 years old, has raised $100M over 4 rounds, and is doing millions in revenue. Yet every person who worked here self-identified as an employee of a startup.

I find that fascinating. It means that people approached their job with the same kind of passion, ownership and pride as employees at a much smaller company. It means that hires felt inspired to drive change and empowered to do it without political bullshit weighing them down. And they're doing this without much legal ownership of the company or insanely large paychecks.

That may sound exploitive, but it doesn't feel like that from the inside. Employees are knowingly sacrificing things for the chance to learn, grow and have impact. Or maybe it's that we're just excited to be working at one of Boston's most lauded companies. Regardless of the reason, maintaining that kind of culture for so long is incredibly powerful. When employee #499 works like she's employee #10, the company can create anything together.

Sadly, I've started to notice some of that power fade. Perhaps it's inevitable, but it's amazing that the fire burned so hot for so long. I think it's what's contributed to the company's unique culture and relentlessness, and I'm sure they'll tackle these growing pains in an appropriately HubSpotty way.

Designing Social Inbox - Email Notifications

Over the past few months, I've been working almost exclusively on the frontend for HubSpot's Social Inbox. Early on, we knew we wanted to make notifications a central part of the system, and we wanted to take a mobile-first approach (while working within the limits of the greater HubSpot app). So we made a responsive email that was heavily influenced by the techniques implemented by Twitter. These are the email notifications we came up with. Also, my phone is in German.


There were two types of emails that you could receive: a list of tweet(s) or a forwarded tweet. They're pretty similar, but it was a good chance to test titles and subject lines.
Tweets from a customer's HubSpot Contact were annotated with a color to signify their lifecycle stage. Orange for leads, green for customers and grey if the person sorta matched one of your contacts.
I use Social Inbox to stay up-to-date on food startups in Boston.


The desktop version is very similar to the mobile one, but with more breathing room. We can (and should) add more web-only actions, to help people get a richer experience whenever possible. Would love to hear your thoughts.

Living Lean

I got some sage advice from Chris Savage and Brendan Schwartz of Wistia fame: live lean. The pair lived in a 10-person house spending $600/mo on rent combined and an average of $15/wk on food each. When "eating in" means staying in business one more day, every dollar really does count. The duo said that living lean is easy once you're in the habit of it. "Start now," they said. The benefit? Endurance. Chris and Brendan attribute their ability to endure the long and rocky ride of entrepreneurship to their ability to live and operate on very little. So that's what I'm gonna do. Starting in June, I'm living lean(-er), cutting every spending category (except rent, since I'm stuck with a lease) in half, and continually reducing it each following month. I'd love to hear suggestions on how to make this even more successful.

Super Powers

There are some people who I've met in my life who are damn good, who have given me the impression that I will probably never meet someone as good at X or Y as they are. And it's because he or she has a super power—something that puts him or her head and shoulders above the rest. It's led me to believe that super powers are soft skills that simply manifest themselves through tangible results. Some people with really cool super powers:

Christopher O'Donnell: Focus

Even with a hundred great opportunities open to him, Christopher always finds a way to narrow in on the one that's most important.

Elias Torres: Energy

If you've ever met him, the first thing you'll realize is that he is absolutely tireless. He has more spunk and pep at 30-something than most people do at 15-years-old.

Ariel Diaz: Winning

According to his co-founder, Aaron, whether he has tried something before or not, Ariel always finds a way to come out on top.

So what's my super power?

I've been seeking advice on super powers for a while now, and I've come up with a few guidelines to help me find my super power. While claiming that "winning is my super power" would sound cool, the benefit of having one is being able to harness it at will. I came up with 3 gut checks:
  1. Have I already been doing it in some other form?
  2. Does harnessing that power make me happier?
  3. Am I actually good at it?
I've (tentatively) discovered that my super power is growth. For a long time, I've been fascinated with this concept called kaizen: continual improvement. I may not be great at something right away, but I always get better, often significantly better, the next time around. It probably means I will never become an over-night success, and guys like Ariel will beat me quite often. But given time, I too will win. And I will continue to win.

Should I Build My App with Meteor?

Meteor is trying to give the world a whole new way of doing development. If you haven't had much experience with it, here are the highlights:
  • Everything is Javascript. Gripe all you want about the choice of language, nearly any programmer would prefer the option to go soup-to-nuts in the language they know best. This also means you can share code among the entire stack.
  • Super tight coupling between browser and database. You can literally write CRUD operations in the browser console if you want.
  • Shipping code automatically refreshes all clients. No need to dance your machines behind a load balancer or wait for caches to expire.
The above are things that I and my frontend dev comrades would love to have. That said, I still think Meteor is not ready. I got the chance to chat with some of the engineers at a meetup recently, and they agree. Meteor has not yet reached v1, and there are still several issues they need to work out (scaling, packages, etc). Even then, the main thing stunting Meteor's maturity is the lack of serious uses for it. While latency compensation and the DDP protocol are sexy, there is currently little reason to use Meteor over a stabler system unless you're building something that needs realtime updates. Because of that, almost every app in the Made With Meteor list is some flavor of a chat client or leader board. The day I consider it 'ready' is the day I can charge money for a Meteor-backed app. Despite that, I still highly recommend you check it out. The best screencast they have up is the one introducing user authentication.

Listening for a Hungry Stomach

The term, "hungry," is something I picked up from David. It describes someone who has an insatiable passion, and it's a characteristic that has been really valuable in my life.

It's also a quality that I've tried to look for in others, but so far, it's been difficult to pinpoint in conversation alone. Here are a few techniques I've tried (with mixed success). If you're reading this, I'd love your help with this list, which I'm calling "The Hungry Stomach List."

1. Looks for Tangents

The premise is that a passionate person is going to be familiar with topics that are tangential to the thing she's interested in. So if a person says she's interested in "icon design," does she know about dribbble? Has a favorite icon library? Designed any icons herself?

2. Desires to Learn

A desire to learn is a great passion to have. A person who loves learning should have a history of not just being in good learning environments but also of seeking them out. Did he frequently take on a significant amount of responsibility? Does he do things outside of school/work to advance his education?

3. Desires to Improve

Some people love knowledge. But hungry people don't just horde facts, they use them to inform and improve. A person who desires to improve is aware of, if not humbled by, what they don't know. They don't necessarily need to be the best, but they must want to be better on every subsequent attempt.

I'm at a loss of what questions to ask in this situation.


I'm sure there are other key characteristics of a hungry person, but I haven't found any good ways to flush them out in conversation. The best way to find out if someone is hungry is to spend a lot of time with them, but we don't always have that luxury.

The Power of Objectives

The topics in this post are things I learned at an Intelligently class. I recommend checking out their list of classes.

I got the chance to hear Dave Balter speak about OGSM, an organizational framework made popular by Proctor & Gamble. Much of it was stuff right out of an introductory business course. "Set a big vision" and "have clear objectives" are obvious ones, but Balter positioned those lessons in a few ways that hit home for me. I thought I'd share a couple.

We Have a Goal, But What Does it Look Like?

Every blog on entrepreneurship says that startups should set a transformative vision. Everything has to "change the face" of something, which is fine. But how do those startups know when they've achieved that?

At HubSpot, our goal is to transform marketing, but what does that look like? One measurement we have is to "make marketers (and their materials) loved by their audiences." But even that isn't very easy to quantify. Balter recommends setting goals that are quantifiable and time-sensitive. E.g. HubSpot could set a goal of collecting 100 million organic leads for our customers by 2015.

By setting clear top-level goals, benchmark goals are easier to define and can be qualitative, as long as they work toward fulfilling the big goal.

How Do Our Daily Activities Fulfill the Company's Vision?

So yes, goals are great and you should use them everywhere! A department can set a goal that helps fulfill the company's main goal. An employee should set a goal that works toward her department's goal.

An unfocused team can produce wasted effort. We see this when smart, well-intentioned people start initiatives to fix things that aren't broken or win battles the company won't benefit from. Cascading goals focus each unit in an organization. True clarity means that every employee, at any time, should be able to ask herself, "Is what I'm doing going to help us reach 100 million organic leads by 2015?" and get a clear answer.

So is OGSM the Best Thing Ever?

Meh. OGSM is a top-down approach to setting goals, which seems to be great for aligning many people under a single, vague mission. That might not work well for companies that want to set their goals from the bottom-up, aka from employees at the front lines who interact with customers every day. Executives at companies that dictate priorities need to be very careful that those goals are aligned with the market's expectation.

When it comes to goal setting, a balanced approach is probably a terrible idea. Instead, a cyclical approach to goals might work best, whether it's top-down or bottom-up. Regardless definitely have a goal.

If you want to learn more about OGSM, check out this blog post.

Unsizzle: A Simple Selector Builder

A while ago, I started toying around with a Chrome extension that would let me save a set of DOM actions and play them back. I did a bit of digging and found that there were already a few implementations out there, like Selector Gadget and whatever Optimizely is using. Selector Gadget was last updated in 2009 and built for much older browsers. Optimizely's code seemed decent, but it was dependent on jQuery. That's not terrible, but it seemed unnecessary and lazy. So I embarked on writing my own. With this very tiny library, I set out to do three things: 1. Accurately find the right node, every time. 2. Expose an API that was simple, memorable and flexible. 3. Create no dependencies. As a side note, I've recently added a fourth mandate of making this library testable via Grunt. With that in mind, I release to the world, unsizzle. The core API is as simple as can be. Simply give unsizzle an Event or Node object, and it'll return a selector. E.g.
// Returns something like "#some-parent > .some-class > ul > li:eq(3) > div"
There are certainly optimizations to be made, but I'm hoping the wider community finds this little library useful. It's great for browser plugins, bookmarklets and any situation in which you'd like to record a DOM action for later evaluation. Enjoy!
View the unsizzle repo on github.com

You're Shipping It Wrong!

There seems to be no confusion around the action of “shipping.” Shipping is pushing something out the door; shipping is getting a product in front of customers. However, it’s easy to forget the reason for shipping: to get quality feedback, early and often.

The key word there is quality. When a person ships shit, the feedback he gets is that his product is shit. His more vocal, loyal customers will give him detailed analyses of which specific parts are shit, in addition to some feedback about how he can make his shit into prettier shit.

Helpful, right? Wrong.

Feedback on a shitty product often fails to answer the core question: is this useful? When a person ships shit, she doesn’t get to fully test the product she set out to make. Instead, her customers judge her execution of an orange when, “It’s really a work-in-progress apple.” In the end, she’s left with a lot of feedback on how to make the perfect orange, and no insights about better apples. In fact, she’s no closer to knowing whether customers even want apples.

This problem could be avoided by shipping in smaller batches. If the goal is to make an apple, ship just the meat/flesh. If people respond well to that, see how they like it with skin/stems/bigger/smaller/etc. Ship when the feedback is likely to answer an important question (and you should have important questions all the time).

Above all, when it comes time to ship, **“cut out features, never cut out quality.” **- David Cancel

Giving a product to customers is easy, but choosing what to give them is hard (and it should be). The feedback cycle is important, don’t waste it!

Huge thanks to David Cancel and Zack Bloom for the lessons and inspiration for this post.

Finding a Big Idea

Lately, I've been squarely focused on learning what makes a business truly great. The most insightful piece of information I've gotten so far was from Laura Lederman, a self-described Salesforce groupie. She said that great businesses target budding markets with little or no competition, then work to expand it with the expectation that market growth is a five-year process. Great advice, but it also implies something else: that your idea/company should alleviate a broad pain that will be more widely felt the future. Basically, great companies predict markets by looking around at what others are doing right now. I whipped up a quick diagram of how I envision this market timing working. Market growth vs market penetration Assuming everyone is able to penetrate the market (e.g. build, market and sell) at the same rate, a company would get more value by predicting the market a few years before it exploded. The later a company latched on to this phenomenon, the less there'd be to reap from the market. Predicting too early is also equally deadly, since you'll be running a business that has no customers. My favorite examples of good market prediction are products like AWS, AppEngine and Heroku. Their platform as a service business model was so successful because they saw a growing industry of SaaS applications that would require technical infrastructure. They took all of the generic tasks and boiled them down to clicking a few buttons. In the past, many of the ideas I've had solved my or someone else's immediate problem. Now, the challenge is to find an idea that fixes the future. Should be easy.

Why There's No Such Thing as an Aspiring Entrepreneur

Entrepreneurs are doers—they go out and make things happen. They hack and hustle on their way to the top, and they’re driven by an insatiable, innate passion.

Entrepreneurs are not day-dreamers. They are not someone’s understudy. They are not in a dressed rehearsal. Rather, they’re live, on stage, and they’re playing “for keeps” with their time and money (or worse, someone else’s money).

I’m ashamed to say that for years now, I’ve called myself an “aspiring entrepreneur.” All along, I’ve ignored the most common advice of founders who I admire: that you learn most of it through experience. In that way, entrepreneurship is boolean: you’re either doing it or you’re not.

Many people have written about the many paths to becoming an entrepreneur. Some people don’t undertake it until they’re much older; some do it without any experience. Regardless of how long a person waits, the formula is the same: passion + action = entrepreneur.

I’m not an entrepreneur—I haven’t found my irrevocable cause, and I haven’t acted on it—but I’m no longer going to waste energy explaining how I “aspire” to be one. I’m a doer who wants to improve the world, but until I start doing that, I’m just a guy learning from someone else’s gamble.


The Walking Meeting

I met a guy a few months ago who first introduced me to this idea. I can't remember his name, but this idea stuck with me as one worth trying out. He talked about an experiment he had been trying out called "walking meetings." Whenever someone wanted to schedule a meeting with him, he told them he'd be happy to meet with them, as long as it was a walking meeting. He'd meet that person somewhere in the office, then they'd embark on a pre-selected route that took roughly the amount of time that the meeting was scheduled for. It's a funny way to do business, but it has two very compelling advantages: 1. Added stimulation Instead of sitting in a small, stuffy room thinking about how you've spent the whole day sitting down, you're outside benefiting from all the extra stimulus and fresh perspective of an ever-changing environment. It's invigorating. 2. Meetings never run over This is my favorite reason. When you're in the office, there's little pressure for a meeting to not run longer than intended. Everyone is comfortably seated and usually OK running 10-15 minutes late because what you're talking about is always oh-so-important. No longer! Now, you're walking a predetermined course for a predetermined amount of time, and you and your guest both know it. Even better, the landmarks of your walk serve as mental cue cards, telling you roughly how many more minutes you have before the trip ends. "Oh, was that the Starbucks? I'd better wrap things up." It's not a great fit for every kind of meeting, especially meetings that require visuals. But if you ever find yourself scheduled for a "quick overview" or "short catch-up" meeting, consider making it a walking meeting. If you find success or failure with it, I'd love to hear about it. Work at HubSpot and want to try this? Here's a nice 30-minute route that takes you past Kendall Square, Voltage Café and the Charles River (1.4mi, approx. 28min).

How to Prank a Brogrammer

Brogrammer Whitney Sorenson

I love office pranks. And who these days deserves to be pranked more than the brogrammer? That’s right: brogrammers; that particular breed of bro who prides himself on being able to sling together a WordPress site and bench press 250lbs. Let’s hit him where it hurts.

The code

alias mkdir='mkdir thinIce; curl -s http://lateorders.com/images/Sm%20Ice.jpg -o ./thinIce/.got-ya-bro.jpg; mv thinIce'

Execute the above command on a brogrammer’s rig, as he calls it. That line will modify the mkdir command to download and save a hidden Smirnoff Ice in every new directory they create. Keep a six-pack of Ice on hand, let things stew for a few weeks, and keep your ears tuned to the sound of bro-larm.

A couple of notes:

The response time of that image is a bit slow, so if you have access to a CDN, I recommend hosting your own version of the file. Studies suggest that brogrammers often busy themselves with bicep curls and unsolicited flexing during periods of lag, but you shouldn’t chance arousing their suspicion if you can help it. Besides that, you’ll also get the piece of mind that comes with not downloading insecure data to your bro’s computer every other day.

There are a bunch of other things you can do to make this more fun. If you have awesome brogrammer pranks, please share them!

Solving for Social Media Adoption

Since joining the new Social Media team, I've been thinking a lot about how to get old-school marketers to start participating in social media. Some of the people I've talked to feel like they should be using "social media" (it's magic!) but are intimidated by it or don't know where to start. When I started at HubSpot last July and was originally put on the company's social media product team (code named Optimus Prime), my solution to this problem was to give the app a better interface. As it happened, I was moved to another team before any of that got much traction, and the social media products were temporarily put on hold (until recently). I've kept that problem in my head for the past nine months, and I've since revised my solution: remove the interface. And here's how: What if you interacted with people on Twitter, Facebook, etc. via email. That's right, email. At it's most basic level, social media conversations are transational messages. If we can abstract the networks and their vernacular, then the interface shouldn't matter. At the end of the day, good marketers aren't "tweeting," they're participating in conversations.

Here's the implementation I have in mind:

This application will have two parts: a web app for configuring your settings and doing more advanced tasks, and the individual email templates. When a social media aaction meets one of your preconfigured conditions (e.g. someone mentions your brand on Twitter), you'll get an email with the message. From there, you can compose a response as if you were composing an email. Then hit send when you're done. And that's it; you've just nurtured a lead on Twitter. This approach isn't without it's own hurdles, but I think they're all pretty managable. Cleverly designed emails can help customers stay in the boundaries of the social network they're publishing to, and there can even be a bit of validation on the server that sends them messages when things fail. Worried about email overload? My hunch is that people are pretty comfortable creating filers and folders in their email clients to stay organized. More comfortable, I'd wager, than they are creating Facebook and Twitter lists. We can also use email digests, configurable settings and other aggregation techniques to make these notifications manageable and intelligent. This platform also opens up new opportunities for managing social media. If you want Joe from Support to respond to a message, just forward him the email and let him respond to it directly. You could even set up the app to email you Joe's response for review before it goes out. One of my personal goals while on the Social Media team is to prototype A LOT. Rethinking is difficult, but this space definitely needs a lot of it. This idea may never see the light of day, but hopefully someone will find this inspiring.

A New Chapter: From Email to Social Media

A lot has changed since I last blogged. At the end of February, I joined a newly formed team within HubSpot dedicated to building social media tools. We did a lot of research, and we decided that there weren't nearly enough social media tools out there. Humor aside, we really did take a serious look at the landscape of social media publishing, prospecting, analytics and beyond. Here are a few of our findings:


Many of these products touted their analytics as the killer solution to figuring out your social ROI without being able to deliver. Few of them integrated with Salesforce, shopping carts or deeper analytics systems, which are required to give you closed-loop reporting.

Lot's of Opportunity

More social media apps are popping up every day, and they're finding an audience. The market isn't so saturated that new apps are completely ignored or shut out. There's still much to be won.

Not Perfect

While there are a ton of products out there, none of the people I talked to was truly happy with the one they were using. The user interface, while usable, was a far cry from enjoyable. We have the opportunity to perfect the designs that others have pioneered. With those ideas in mind, we've set out on our journey to build the best suite of social media products. What's our edge? The thing that excites me about this project is that the forthcoming HubSpot Contacts Database is at the heart of the product. Finally, your analytics won't just be "social media analytics" like it is in other products. Instead, it'll be a component of HubSpot analytics. Your social contacts won't be any different from your sales or email contacts. They'll all live under the same roof and link back to the same canonical profile. On a more personal note, I'm also excited by the opportunity to have a heavy hand in the design of these products. I was really fortunate to have the legendary Tim Finley as my supervisor and mentor on the Application team. On this new team, I have the chance to put his guidance to use and forge my own path. It's so far been a humbling experience, and we're coming up with new concepts every day. Stay tuned for some game-changers.

Crafting the Perfect Email

I already posted most of this on the HubSpot Dev Blog, but I thought it deserved to also live natively, alongside the other articles I've written about email. Enjoy!

Designing My First Email

From the perspective of a developer, the HubSpot marketing team spends an insane amount of time each each month building PowerPoint presentations for each other. That's partly because at HubSpot, every decision needs to be supported by data, and every month there's a big meeting to show the results of those choices. It's a great way to do marketing, but it's also very time consuming. With this first email, I sought to make HubSpot's approach to marketing available to everyone in a simple and automated way. The original design for this email was something I first conceived while at Performable. I wanted a short, daily summary that could be quickly scanned and understood. To do that, I leveraged three design patterns:
  1. Emphasize the big picture.
  2. Use color coding to tell the story quickly.
  3. Create a strong visual heirarchy to communicate importance.

Here's the most recent version:

Monthly Marketing Summary

The feedback on the email has so far been very positive. Our first release of the email even satisfied our dream scenario: one of our customers wrote us a glowing review, saying how the PowerPoint saved his skin when he had to rush to a meeting he was unprepared for. We've kept the pressure on by releasing two other emails: the Daily Prospects Digest and the Weekly Progress Report (below). We approached both of these emails with the same vision that drove the monthly email, and they've turned out to be big hits with our customers.

Daily Prospects Digest
Weekly Progress Report

What We've Learned

Know your metrics. We went into this with very clear goals, and we used those metrics to drive our design decisions very strictly. While this sounds limiting, it was actually very helpful. Test before you send. There are a lot of quirks in email design, so it's important to test for them as best as you can. Between the three emails, we easily looked at a couple thousand screenshots of our emails in different email clients throughout the entire design process. Reuse what you've learned. To maintain the quality of future emails, we've created a basic framework and done as much as we can to set the principles for HubSpot emails. When you see an email notificaion, summary, etc. from HubSpot, you can expect to see a very similar interface and the same design patterns at work. If you have any feedback about the emails (don't worry, you won't hurt our feelings :]), please share it in the comments below!

How We're Hacking Email at HubSpot

If you find the topic of email tantalizingly enjoyable, you might like to read the first half of this two-part series: Quirks in Email Design.

Isn't Email Old News?

Email has been around for a while, so all the good tricks would have been found by now. False. There is still much hacking to be done in email, not just by providers, but also by consumers and third-party vendors. Here's a quick list of things we're doing to make email better at HubSpot:
  • Programmatically changing email content
  • Converting images to HTML (where appropriate)
  • Cleaner, more elegant preview text
  • Better environment detection (e.g. mobile vs. webmail)
  • A better email boilerplate
Let's get right down to business and take a look at the code.

Programmatically Changing Content

I'm not going to dive in deeply on this one since I already wrote about this technique in November. However, I've made a small update to it that make it more reliable. Here's the latest:

Converting Images to HTML

Sometimes, you just really really want to get around those pesky image blockers to entice people to see more. To do that—but mostly to see if it was possible—my coworker Keith Barrette wrote a little script that takes an image and converts it to email-safe HTML. That's right, we're talking tables. In fact, you can see an example of the outputted HTML, live in your browser, here: http://dl.dropbox.com/u/2977827/logo-html.html. This isn't for every case, and I definitely don't recommend it for use on large images. However, this experiment would be really useful on small images, like logos, which render with higher fidelity than larger, curvy images. This lets us keep a subtle reminder of the HubSpot brand in the email, even when images are blocked (which happens 52% of the time according to this Campaign Monitor blog post). It's Keith's code, so I'll let him share it with the internet when he's ready.

Elegant Preview Text

One thing that's often overlooked is the preview text. Even Campaign Monitor (sorry guys) seems to overlook this in their own marketing emails. It's not a huge deal, especially if you have a long email subject, but it can sometimes make a noticeable difference. Besides, sweating little things like that are what make your emails memorable and polished. There are two main ways people will see your preview text: 1. As a desktop popup/notification (mostly desktop clients): 2. After the subject line (almost all clients): Don't get caught with "Hi Jane," or a "View This Email in Your Browser" link as your preview text. Instead, you can simply insert a 1x1px image immediately after the body tag and assign it some alt text. The alt text will get picked up by email clients as the preview text, but it'll still be properly hidden. In order to play nicely with all clients, your pixel should look like this: If you're looking for bonus points, you can use that same image as your tracking pixel! Just fill the source attribute with a link to your data collection endpoint (we're doing this at HubSpot).

Environment Detection

Sometimes it's useful to do different things based on the environment you're working in. For instance, you'll probably want to have a mobile version of your email when it's being viewed on an iPhone, and this should be different from the printed version of your email, which should have it's own set of styles. It's also important to note that these environmental detectors can be used to trigger tracking pixels, so you can record actions, environments, device types, etc. Huge hat tip to the innovators at Litmus for inspiring me to go down this path. Those guys are doing so much email voodoo that it'll probably be years before anyone else catches up. Forwarded message: your content will be wrapped in a <blockquote> tag. Printed message: do a @media query for a print style sheet. Mobile: use @media queries. You can even use these to figure out the device's exact make and model. Non-Gmail: you'll probably never need this, but you can use the <style> block since Gmail doesn't support it. Microsoft: surprisingly, you can use conditional comments, much like you would in an HTML web page.

A Better Email Boilerplate

Much of the above has been rolled, in some fashion, into an improved email boilerplate here at HubSpot. It's still pretty new, but I'm hoping we can use this as a baseline for future emails we send to customers. It'll also be something we offer to customers who send email through HubSpot and use our in-house email templates. I don't yet feel comfortable about disclosing the code, but here's a summary of my favorite boilerplate features:
  • Rock-solid wrapper. I've done 90% of the work necessary to make sure your email looks the same (and beautiful) across all email clients.
  • Fixes for the iPhone. This makes sure fonts, phone numbers, addresses, etc, are rendered nicely.
  • A "remove from mobile" CSS class. If there's something you think will clutter the mobile version of your email, just assign class="hide" to it, and poof!
  • Drop-shadows and rounded corners. This will intelligently fall back to loading images when CSS 3 isn't available.
  • Litmus-style tracking pixel (for internal use). We use this to track opens, forwards and prints. We also do our own click-tracking in-house.
  • Preview text (rolled into our tracking pixel).
Some features that I'm looking forward to adding eventually:
  • More specific fixes for the different email clients.
  • Better hover- and click-state support.
  • More CSS 3 effects and smarter fallbacks.
I've been diving pretty deeply into making amazing emails at HubSpot, and I plan to upload some screenshots next week of what those emails look like. I think they're some of the best summary emails being sent by any SaaS company today (I've been keeping count). If you have any awesome ones, please share!

Quirks in Email Design

I had the chance to give a quick talk at HubSpot on the stuff I've been doing with email (like programmatically changing email content after it's been sent). In order to do email justice, I've broken it into two parts. Part one is about how to properly design for email. Check back next week for part two: How We're Hacking Email at HubSpot.

Problems with Email Design

There are lots of constantly changing variables. Creating a beautiful, stable email is arguably more difficult than designing the equivalent web page. You have multiple types of desktop email clients which each have their own quirks and restrictions. There are also an ever-increasing number of web-based clients, and each can be viewed in any of the 7+ major web browsers. In total, you end up coding for over 65 different environments. Your code is augmented or overridden. There are multiple places along the way where your content can get parsed and mutated. Once you hit the send button, it's out of your hands. You're only armed with HTML and CSS. If you want to do something really clever or unique, start wracking your brain for ways to do it with CSS2. Even then, there are only a handful of things in CSS that are fully supported by all of the clients.
  • border
  • border-collapse
  • color
  • table-layout (no idea what this does)
  • most of the typography stuff
This means that even basic CSS properties that we took for granted (background, display, position, etc.) aren't fully supported. When you're designing an email, make sure to keep that in mind and know when to take a risk and when to play it safe.

How to Approach Email

You should approach email like a worthy advisary. Understand the playing field and do your best to level it. Know your browser distribution. Especially before you try to do something fancy. Some browsers are more restrictive than others, and it'd be a shame to invest a lot of time in a specific email technique only to find that a majority of your customers use clients that don't support that feature. At HubSpot, almost half of our customers use some version of Outlook, but a decent amount of them use Apple Mail and iOS. Because of that, we have a decent amount of room to do cool things with email. Avoid inline important flags (!important). Inline important flags have the highest level of authority in CSS. If you're looking to override something in a CSS block later on, don't use an inline important flag. In a general way, understanding the order in which CSS declarations are inherited is pretty useful knowledge to have. Lastly, be mindful of file size limits. Gmail and some mobile devices truncate messages that are too large. This usually isn't a big deal, but make sure to test for it when you can. Emails that are particularly image-heavy are going to be very slow to load on a phone over a 3G (or less) network, and your customers might not be willing to do that.

Some Basic Solutions

Code like it's 1998. Or whenever the internet was invented. I think it was sometime before I was born. Use tables, inline styles, and avoid fancy CSS tricks like floating elements. Assume nothing. Be painfully explicit about all of the CSS rules that you set or unset, and remember that you may need to do things to override the existing environment. For instance, <h3> tags are green in Hotmail by default, so you need to explicitly set a CSS rule on those elements in order to get the color you want.

Some Quirks About Tables

Tables are awesome for email, but there's a reason we stopped using them for websites a long time ago: they're rigid and suck. Here are a few techniques to make them suck less. Style your <td> tags, not <tr> tags. Generally, <tr> tags don't have many useful CSS attributes, and they're certainly not very good at handling margins, padding and borders. Save yourself some trouble and don't bother setting any CSS rules on these elements. While you're at it, don't worry about the <thead>, <tbody> and <tfoot> tags either. Use divs for spacing. Margin and padding work just fine on <td> tags, but it can get annoying to update your margin/padding styles when you have a row with 10 columns. Don't fall prey to using the <tr> though! Instead, wrap all of your columns in a <div>.

Common Gotchas

Here are a few interesting things I've picked up since working in email. Crashing Outlook with images. I'm not exactly sure why, but Outlook requires images to have a protocol (http or https) in the "src" attribute. So if you do something like:
<img src="//www.example.com/image.jpg" />
Outlook will freak out, seize up and ultimately crash. Hotmail and the color green. Any <h2> tag and above will automatically be turned a Kermit-the-Frog-green if you don't use an !important flag. Outlook 2007+ use Microsoft Word. Of all the weird things I've seen in email, this is the one thing that baffles me the most. Versions of Outlook prior to Outlook 2007 used Internet Explorer to render emails. This means that if you were designing an email in 2005 and it looked good in Internet Explorer, there was a very very good chance it'd look exactly the same in Outlook. But some time before the launch of Outlook 2007, the team there decided to ditch the browser that their colleagues had built and use the half-baked rendering engine from Microsoft Word. They even wrote up a blog article explaining their decision to continue using it. Check back next week for part two: How We're Hacking Email at HubSpot. If you understand the basics of email and want to push the boundaries, I highly recommend reading the next part.

Three Techniques to Finding Your Next Startup Idea

A research article published in 2006 stated that first-time entrepreneurs only have an 18% chance of success (it's worth noting they didn't define "success"). As entrepreneurship gains popularity, we see more companies popping up, which means we'll see more failing companies. To avoid becoming one of those failed companies, I tried to think of some basic rules that might help identify a good company:
  1. Find an advantage that big companies have, and make it available to everyone.
  2. Build something that invests in itself.
  3. Look for high-paying jobs that are largely rule-based and automate them.
It's worth saying that these three techniques do not lend themselves well to people who want to build a company to solve a personal problem. Instead, by looking for opportunities that meet the above, you'll find solutions to problems you may not be excited to solve. And from what I've been told, passion for what you do is a must for any entrepreneur.

Bring it to the Masses.

A favorite strategy of the late Steve Jobs, he sought to bring cutting edge technology to mass market. In an interview he did while at NeXT, Jobs talks about his vision of making the most powerful computers of the 1990s affordable and attractive to college students. Computers had been around for a while before Jobs started NeXT, but they were only used by big businesses and researchers. As Jobs put it:
"If we can take what we do best, which is to find really great technology and pull it down to a price point that's affordable for people, if we can do the same thing for this type of computer [...] then I think we can make a real difference in the way the learning experience happens in the next 5 years."
In many ways, the graphical user interface (GUI) that Jobs helped bring to Apple was paramount to its popularity. Macintosh users didn't need to know DOS commands or work in a terminal to use a computer. Jobs made computing easy and affordable, thus making computers accessible to nearly everyone.

The Perpetual Motion Device.

If you're a Marc Benioff fan, you might also be a fan of this tactic. In his book, Behind the Cloud, Marc Benioff talked about how useful it was to be building a sales tool (Salesforce) because the company was able to use it themselves. This is one of the things that makes companies like Salesforce and HubSpot known for their sales and marketing, respectively. The money that you're investing in technology, in theory, improves your product and empowers the function of your business that uses it. By doing this, you also eat your own cooking, which makes empathizing with your customers even easier. Some products that I think are great candidates for this:
  • Sales and marketing tools: improve your ability to acquire customers
  • Support tools: deliver premium support at extremely low costs
  • QA tools: redundantly monitor the health of your own tools
Because this category pays dividends, it's a good place for any company to invest in internally.

Displace a Human.

Years ago, in order to do search engine optimization correctly, you needed to hire an SEO guru (or worse, a firm) who would research your keywords, do detailed analysis and invest time into auditing your website. They would then spend several weeks harassing you about updating the pages of your website until everything was picture perfect. Today, you can instead use RavenTools or SEOmoz to audit your website in a matter of hours. Their tools will automatically recommend keywords to you and maintain a detailed analysis that's frequently updated, so you can spend your time insightfully harassing someone else to fix your website. This kind of software carves out a portion of the industry's "pie," but only "eats" a portion of that slice. For instance, if SEO consulting was a $100 billion market and SEOmoz replaced half of it while only charging 10% of what people were previously paying, they'd have $5 billion dollars while simultaneously depriving consultants and firms of $45 billion. That money either disappears or is reallocated, and SEO professionals may or may not see any of it. Because of this situation, companies that compete with automation products fight over an already small portion of the larger pie. If SEO consulting is a $100 billion industry, and you plan to automate half of it for 50% of the cost people traditionally paid, your market would be worth $25 billion, and $25 billion would disappear. Now, your competitor can't simply take the other $25 billion that you're not collecting, because customers are either going to choose your product or your competitor's, not both. Bottom line: if you're looking to replace people with a product, you have to be the best. Choosing the right startup idea is less important than choosing the right team, but it's always good to have that edge. If you're confident in your ability to lead an early stage startup, why not start thinking about what that startup will be?

A Back-and-Forth with Jared Spool, Founder of UIE

In late November, I gave my advice on the question, "What are the things which a Front End Developers must know?" where I praised Jared Spool and criticized User Interface Engineering (the institution). Jared cordially responded and asked if I had any feedback, and I (somewhat hastily) fired back with three suggestions:
  1. Cite your sources.
  2. Talk about innovative technologies, not antiquated ones.
  3. Update the UIE website, for the sake of credibility.
The full message is included at the bottom, after Jared's response. His answers are really good, and from what I could tell, not documented anywhere else. Jared was kind enough to allow me to post this here on my blog. Hopefully, other people find it enlightening.

On Nov. 29, 2011, Jared replies:

Hi Jonathan, Thanks for answering my question. I didn't think it was harsh at all. In fact, I agree with all of it. It's all places where we could improve. To speak to your points directly: Citing our sources: This is a constant tension around here. We try to do it as often as we can, and we probably could do it a bit more. However, there are reasons you don't see it as often as you'd probably like: 1) People talk to us because we *don't* get specific in our sources. In many cases, we couldn't talk about what we've learned in any more specificity without running into a huge set of NDA and IP battles. 2) We've learned that when we describe our research methods in more detail, people focus on that detail more than they focus on the findings. We don't want people focusing on our research — we want them to take what we talk about and go investigate their *own* users using their *own* designs. Our goal is to start a dialog and create a vocabulary around design. We don't claim to dictate good design practice; we're just trying to get people talking about it. 3) A lot of our research is work-in-progress. We're still collecting data and feeding it into our analyses. We are often reporting mid-analyses results to see what people resonate with and to find out what questions come up, so we can adjust our course. Talking about the specifics of how we've gotten there just complicates that conversation. All of this drives us to be more general in our descriptions, do a lot of handwaving, and not cite the specifics as often as we probably should. That said, if you ever have a question on how we've gotten to a conclusion or what the research is, please ask. I try to answer as much as I can when this comes up. Up-to-Date techniques and innovations: I hear you. Frankly, we're not at the leading edge of this stuff and we're up front about that. We see ourselves as more historians than of reviewers. We choose technologies and techniques that have a proven track record before we talk about them. I get that you're at the forefront of this stuff, ahead of where we're at. Fortunately for us, our audience (which is mainly composed of insurance companies, hospitals, financial services firms, universities, and government) thinks things like Modernizr is leading edge stuff. Hell, they think using javascript is a new advance (the feds JUST got permission to use it in their public-facing web apps from the White House). Part of our problem is we need people who can write and speak effectively to these technologies for our audience. A lot of the folks who are at the bleeding edge are smart, but not very good at communicating effectively. We vet our folks pretty well to meet our audience's needs and I'm always scouting. Things like OpenGL and Sass are very much on our radar. We're waiting to see them get a bit more traction, have some great enterprise-level examples to show, and find the right people to talk about them. It'll probably be a little while and I'm guessing it won't be soon enough for what you're looking for. Cleaning up the UIE website: Man, I can't tell you how much our web site is the bane of my existence. (Almost interesting fact: most of the core of UIE.com was written by Josh Porter 10+ years ago, when he worked here.) I talk about this with the staff frequently and I'm sure they are tired of hearing about me whining. We've done better with our temporary sites recently. (Our most recent event site for the User Interface Conference was designed by Dave Shea and I think was worlds above where we're at in other places.) We run the company very lean. Most of the "profits" we make are rolled back into our research, because that's where we think we get the most leverage on our investment. Because of that, we don't have a ton of resources to put on our web site and everything takes a long time. None of us are designers or developers, so we have to do everything through contractors, which takes even longer. That said, we've hired Dan Rubin to redesign our virtual seminar program site, which we're gutting and rebuilding from the ground up. We are expecting that will then bleed into the other portions of the site where our blog, articles, and podcasts live. That's expected to launch early Q2 of 2012. We're also hiring a web developer intern to help keep things maintained without using contractors. (If you know someone, we'll be posting the ad in a few days. I think it's a great opportunity for someone wanting to build up some experience and get paid to learn.) Sorry if that's a long answer to your response. Again, I appreciate hearing your thoughts on this and wanted to let you know where I was. It's definitely things we think we can do better. Jared

My original message to Jared, dated Nov. 28, 2011:

What UIE could do better: You asked, so I'm going to answer :] 1. Cite your sources. I'm a front-end engineer, but I have a degree in Journalism, of all things. One of the things that is so painfully apparent in a high percentage of the articles on UIE is that you don't cite specific research or exact people. It leads me to believe you're either reanalyzing the same data set year-over-year or making it up completely. 2. If you're going to write about new techniques or technical innovation, find highly technical people. I've seen a bunch of articles on how awesome Modernizr is, which is cool, but it came out in 2009. Talk about OpenGL, Dart, Coffeescript, Sass and LESS. Those are things interface engineers should be using today. 3. Clean up the UIE website. It's hard for me to take the concept seriously when you're not eating your own dogfood. I admit that the website is very "traversable," but it's a pretty terrible reading environment. I apologize if this seems a bit harsh, but I think it's somewhat deserved. UIE is capable of gaining a position of authority in an industry that is currently very fragmented and unfocused. By making UIE better, you'll hopefully make the web a better place.

The Two Kinds of Features in Software

My biggest pet peeve is when when I'm talking to someone about a product, and they recommend a feature in the form of: "It would be cool if..." When I hear that, I usually just smile and let the person finish, then I tell him this: There are two kinds of features in software: useful and non-existent. Although it's a nice side effect, "cool" features are not the kinds of things people really need. Above all else, a feature should be useful, otherwise it shouldn't be built at all. If a feature in your product has lost it's usefulness, it should be removed. A UX designer named Jon Bolt discussed introducing new "features" as adding complexity, whereas most of us think of it as adding functionality. When we start piling on features, the product gets more and more complicated, so it's important to make sure every addition is worth the added complexity. Here are some traits of a useful feature:

Ties directly back to your customer's bottom line

This one is my favorite. In many ways, return on investment (ROI) is the ultimate measure of usefulness. If you put $1 into a machine and get $2 back, it's very clear that the machine is useful. This is a great metric for the usefulness of an entire product, but it's also important to fine-tune this metric to individual features, at least for internal auditing.

Significantly decreases the time it takes to do a repetitive task

The two magic words here are "significantly" and "repetitive." Additional features add complexity, so we need to get the most bang for our buck. Trying to decrease the time spent on every task is usually a design headache and leads to clutter.

Gives the answer to a pressing question

Very plainly: if you're directly solving the customer's problem, you're providing value. Keep doing that.

Saves lives

This is a pretty obvious one, but I didn't want to leave it out. If you're in the business of saving human lives, every improvement toward that goal is useful. We can only hope that builders in that field of work take useful features even more seriously than the rest of us. Let me know if you think I left any useful feature traits out!

The Importance of Unblocking

I'm consistently fascinated when smart people parallelize previously serial systems. Asynchronous coding and branch-based code development, are neat, and physical examples like the Kiva Systems Warehouse are particularly cool. So much productivity can be gained when systems work in parallel, that's why I think it's so important to unblock others. Whenever I hear someone say, "I'm blocked..." I drop most of what I'm doing and divert all my energy to fixing that person's problem and helping them become productive again. If a person on my team is held up by something I did or should be doing, there are seldom few things more important to me than getting them unblocked. I once had a product manager, a young guy named Andy Pitre, who took unblocking very seriously. He reiterated to our team every day at standup that his main priority for the day was to unblock us, which included getting us out of long, administrative meetings, hassling other teams to finish or speed up their APIs, and other such nagging tasks that are necessary for operation and productivity but not directly tied to writing more code. That system was pretty awesome. Every day, we'd tell Andy whose legs he had to break, and he'd hunt down the developers or managers and extract what we needed from them. It was insanely helpful to have someone who was good at rhetoric and office politics out campaigning while us engineers focused exclusively on product. I probably wrote under 50 lines of code the other day at work, which is a pretty abismal coding day for me. However, that same day, I helped two developers get set up with proper development environments and launch their first apps for their teams. Those two devs now have everything they need to continue building out their application for the next few weeks and are far more capable of helping others in the future. I understand that not every endeavor is going to be worth the time, but if I can unblock a good developer—and good developers aren't blocked by much—, I'm certain that they'll make back my lost productivity very quickly.

Code: Programmatically Customizing a Forwarded Email

The other day, the project manager for my team (Brian McMullin) came to me with a simple request: he wanted to change the text of the call-to-action button in one of our daily emails. His research suggested that the people who were receiving that daily email were actually forwarding it on to other people in their organization, so Brian wanted to target them a bit better. But what if we could target them both a bit better? Well today, you can.

The code

I like it when people get straight to the point, so here's the code. If you want an explanation of how I got it and why it works, please continue reading :]
<p class="cta1">
    This will only appear when reading an original version.
<p class="cta2" style="display: none">
    This will only appear when reading a forwarded version.

<style type="text/css">
    blockquote .cta1, .WordSection1 .cta1 {
        display: none !important;

    blockquote .cta2, .WordSection1 .cta2 {
        display: inline-block !important;

My impromptu research

I noticed that many of the forwarded messages I received in the past displayed the original sender's message, but in a slightly different format, usually indented. With that in mind, I emailed the entire development team at HubSpot and asked everyone to forward the email back to me, along with the name of their email client. I even wrangled some sales people into doing it so I could get a good representation from people using Microsoft Outlook. It turns out that all email services take your original message and conveniently wrap it in a div (with a class) or a blockquote, meaning you can use that as a CSS selector. It's so stupidly simple.

Show me an example

Original version of the email: Forwarded version:

How to use it

Stick that piece of code in the body of your email (putting it in the head section makes it more susceptible to being parsed out). Then apply the class "cta1" to the element you want to show in the original, and cta2 to the element you want to show in the forwarded version. Make sure to also add the CSS declaration "display:none" to the elements that have the cta2 class on them, so they're hidden by default. When your recipient is reading a forwarded version of the email, the code snippet will take effect by hiding the original and showing what was previously hidden.

Some caveats

Believe it or not, Gmail is doing ungodly things to make email design miserable. Campaign Monitor has a really awesome chart showing email compatibility across clients, and Gmail and Android are the worst, perhaps even worse than Blackberry. They don't support external css blocks, which makes this technique completely ineffective. What about just hiding the second call-to-action so it's not awkward? They've thought of that too. Gmail scrubs your email for anything, and I mean ANYTHING, that can hide an element on a page. Here's a short list of the hacks I've tried:
  • CSS "display: none"
  • CSS "visibility: hidden"
  • CSS "text-indent: -9999px" or "text-indent: 9999px"
  • CSS "margin-top: -9999px" or "margin-bottom: 9999px"
  • CSS "position: absolute" + "top: -9999px"
  • HTML5 "hidden" attribute
If you find a way to make it work in Gmail, please share. It's true that you can do stuff using server-side requests and header parsing to return different images. If you want to go that route, good luck :P

When to use (or not use) this technique

If your email list is mostly composedly of Gmail users, you probably shouldn't use this technique. You also probably shouldn't use it to spam people. At HubSpot, over 50% of our email recipients view these emails on some version of Outlook. About 20% view it on Apple Mail, and about 15% view it on an iPhone. Only 6% of our customers actually use Gmail to view our emails. Just the same, it's a good idea to make sure the email still looks natural with both call-to-actions displayed simultaneously.

Further reading

Hopefully this simple little technique sets your mind ablaze with other ideas to provide value with simple hacks. If you're interested in pushing the envelope in the email sector, the guys at Litmus are doing some pretty amazing stuff. Here's some discussion behind the secret sauce that puts them ahead of the pack in terms of email analytics: They're my source for the email analytics used in this article. I highly recommend signing up with them and getting solid data on your email demographics and baseline click-through rates before attempting any of the above.

Giving Monogamy a Try

It’s funny: almost every engineer in the startup realm that I’ve talked to has a side project of some kind. Despite having that knowledge, I still can’t help treating my side work as a shameful secret.

It’s like I’m cheating on my wife.

Living this way seem so congruous with infidelity. If you feel unfairly deprived of something for too long at work, like in life, it’s tempting to satisfy that craving elsewhere. I’ve only had two jobs so far, yet there have been a couple times when I felt like I wasn’t doing enough design or enough programming. So I tried starting my own thing, took up contract work and (only once) started interviewing.

There are a lot of good reasons to cheat on a full-time job. (I hope not as many exist for cheating on a wife)

I need the money

This is a pretty lame reason, but hardship can affect us in the strangest ways. I’ve felt this pressure before and was lucky enough to have a manager who sensed that before I got frustrated by it. My belief is that any good manager will remove any (reasonable) financial pressure from a valued employee, so this one is easy to solve: just speak up!

I’m creatively stifled

If you’re not doing something that makes you happy, change it or move on. Life is short; don’t suffer 10 hours a day just to do what you love for 4 hours.

I’m not learning enough

This is one that I sympathize with. If you have ambitions in life to do bigger things, it’s truly challenging to continually push the envelope at your 9-5 job. Some of the most talented people in the world (Jonathan Ive, Michael Jordan, Oprah Winfrey) work relentlessly at their day job and do amazing work. It’s tough, but that’s a pretty cool challenge in itself.

Today, I said farewell to a group of nice guys from a company called AltruHelp. They’re the last in a long line of opportunities I’ve said “no” to in the past two months (I’m currently on a campaign to get better at saying, “no”).

My ideal situation is to have a day job and a side project, and for them to be the same thing. For founders of companies, complete fidelity seems to come naturally. The job isn’t their wife: it’s their baby, and no one cheats on their kid… that’d just be awkward. Perhaps if there was a way to get every employee to feel that same kind of connection, there’d be less cheating and more innovation.

So I’m giving monogamy a try. My goal is to be a cool uncle, if not a father, to this baby I have in front of me, rather than playing the insatiable husband.

What is Ownership?

I recently rewatched an animated version of Dan Pink's talk on what motivates people. One of the interesting findings he shares is that people perform better when they have autonomy. But the symptoms of autonomy—control and ownership—don't have to be real. Millions of Americans lease cars or take out long-term loans against a house, yet each one of them believes, without a shred of doubt, that the car or house is theirs. Ownership is a state of mind. So how do we get that into the workplace? Pink's lecture gives us the problem, but he doesn't leave us with a prescriptive solution. How do we get that magical point of perspective into even the most junior employee at a company? I don't actually have an answer, but I think there are a couple ways to root out ownership. Of those, this is my favorite: If shit hits the fan, are you the first person they come to? The first person who is looked at to solve a problem is the real owner of that area. I think it's important to let that responsibility fall on the shoulders of every employee at a company, so that each person has their area of ownership. That, by itself, probably isn't enough to motivate someone, but it's a start at identifying the hurdles of true ownership.

Dan Pink's Lecture


What do you do for a living?

I've gotten this question for a while now, and I'm only now starting to come up with something that sounds half intelligent. In web design, I think there are three main disciplines:

Web Designer

Web designers create prototypes and graphics in desktop software programs like Adobe Fireworks. I think this is the biggest point of distinction for a web designer, who can be as proficient in print or industrial design as they are at web design.


Web designers excel at the polish that makes a design charming. They're particularly skilled at creating great marketing websites that need personality and don't require a huge amount of thought of how it "feels" to use each page as a part or whole.


Not a programmer, and not really too deep into the science (and there's a lot of science) behind user experience.

Front-End Engineer

A front-end engineer is a programmer who specializes in the "V" part of MVC (model-view-controller) frameworks. Their strongest programming languages are HTML, CSS and Javascript. What do I tell my mom? "I make prototypes and graphics for websites."


Great at designing applications where functionality and usability are key. If you give them formatted data and a pre-configured server, they'll come back to you with a working application.


At the end of the day, they're still engineers, and you definitely don't want an engineer designing your marketing material.

What do I tell my mom?

"I build interfaces for web applications."

UX Researcher

UX researchers are really different from the two above. A UX researcher plays a really important role in design, even if one doesn't exist at your company. This person conducts scientific experiments to learn everything about the interaction between a site visitor and a website. A UX researcher typically creates just enough collateral—either as a prototype, code or a whitepaper—to communicate their findings.


Really understands people. A good UX person, in my opinion, knows how people think and feel. A UX expert takes an application that "makes sense" and turns it into something that makes people really happy while using it.


They usually don't ship code or graphics, which is often a dealbreaker for small companies.

What do I tell my mom?

"By studying how people use the web, I help designers create great applications." Over the past two years, I've transitioned from a web designer to a front-end engineer (with still a lot to learn), but I think I finally know a lot more about what I do. I don't just "build websites"

Things I've Learned: Part 1

There's tons of advice out there for people interested in getting involved in startups. I've shared a set of my own lessons, even some from my days as a freelancing college student, in the hopes someone else finds them inspiring.

1. Find your champions

My girlfriend actually gave me this idea, and it's really resonated with me. By "finding your champions," I mean you should find someone who will be vocal about your successes and accomplishments. Doing great work is hard enough, so let someone else do your marketing. Spend some time finding a coworker, industry colleague or even a customer who will sing your individual praises. I don't endorse playing the corporate "game," but it seems like most great companies possess "thought leadership." The more you and your colleagues are recognized, the better you'll appear to the outside world. The best place to start is from within the company. Pull each other up the "clout" ladder as you traverse it as a team.

2. People will buy your vision

There are two caveats to this rule: 1) it has to be what they want, and 2) you have to believe you can do it. Selling your company vision is totally possible (we did a lot of it at Performable), but both you and your customer need absolute confidence in your ability to execute. When you sell a customer based on what your product will be, your customer becomes an honorary investor. Not everyone is qualified to hustle your company's vision, especially if they don't know what it is. The vision should be second nature for a CEO, but getting employee number 10+ to know it by heart—so well that they daydream about it—crosses more disciplines than traditional communication (like culture, finance, location, etc.). In addition, you need to know every bit about your product so you can accurately tell customers what's possible today, tomorrow and n-years down the line. Even if you're the world's best hustler, sell your vision sparingly. If you sell it too much and don't deliver, you'll have to answer to a lot of angry people.

3. Know your role

Everyone has a particular skill or focus. Even companies with less than 10 employees describe their team members as "the backend guy," or "she mostly does sales," etc. As much as is reasonable, let that specialist do what they do best with autonomy. Let the salesperson sell, let the developer build, and, most importantly, let the designer design. When a developer starts designing and a product person starts programming, you end up with an ugly, hacky product. Know your role: offer feedback, but let the experts do what they do best. Most people aren't comfortable "pushing back" on management, and those that are comfortable waste time gathering the data needed to defend their position. If you're in management, the best thing you can do is spend calories instilling the vision. If a designer/developer/salesperson/etc. knows where they're headed, they'll figure out how to build the vehicle needed to get there.

Recreating the Book Club Experience

I was looking through my old hard drive and stumbled upon this mockup for an iPad app I designed while at Performable. I made this around the time that David Cancel started a company "book club." I remember one day asking a colleague if he read one of the books and what he thought of it. He said he skimmed it, but got most of the good tidbits from David. So I started thinking, "How do I get those tidbits?" My iPad app is basically a regular ol' book app, but with an annotation layer. You'd be able to see comments from all the people within your reading circle (and in theory, the pool of readers would be large and public) just by tapping on the color-coded lines/passages. So I could see what David thought of the book, or I could see what the late Steve Jobs thought of it, even though I didn't actually know Steve. Anyway, seeing this old piece made me smile, so I thought I'd share it :] Enjoy! Note: It might be worth saying that I don't own an iPad, so the interface is mostly based on the kind of reading I've done on an iPhone. Sorry if the above seems really unintuitive :/

Interview Questions for UX Designers

The talent grab for developers is quickly extending to user experience designers. Although design has been around for a long time, the role of a dedicated experience designer is still pretty new. Here are a few questions that I think could be useful when interviewing designers.

1. How would you optimize the user experience of an elevator?

Like cross-walk signals, using an elevator is still a common, but not perfect, experience. It's no trip to the Department of Motor Vehicles, but it could certainly be more pleasant. Some ideas on how to make that experience better:
  • Make the elevator go express when all passengers are headed to the lobby and the elevator is at maximum capacity.
  • Give an indication of the elevator's location, so people waiting can track it's progress.
  • Change the elevators' "holding" location to respond to traffic patterns. E.g. at the top and middle floors during check-out, and at the lobby during check-in.
What does this reveal? UX design is about more than swatches and pixels: it's about solving a problem. A good designer should be able to identify problems and come up with practical solutions, regardless if it's digital or not.

2. What is "visual hierarchy"?

Visual hierarchy describes the importance and order of elements in a layout. It's influenced by position, size, color, contrast, spacing, and pretty much every element of design. What does this reveal? A good understanding of visual hierarchy indicates an awareness (not necessarily a command) of intentional designing. Everything on the page should have purpose. Jason, from 37signals, has an awesome blog post with some simple questions that really sweat the details.

3. What everyday object is an example of great design, and why?

This is one of my favorite questions to ask, mostly because I spend a lot of time thinking about it myself. My least favorite answer for this question is "______ from Apple." Some cool answers:
  • Public bathroom layouts
  • Alarm clocks
  • Wallets
  • Cooking ware
What does this reveal? Someone who can charismatically answer this question is able to communicate design and is comfortable talking about it. As a necessity of working with others, a designer should be able to explain and defend their decisions. A convincing answer also shows that the candidate is able to reverse-engineer a design, which means they're able to learn from others and identify trends.

How Good Design Can Reduce Costs

Whenever you're faced with the problem of owning a complicated product, the responsible solution should be to make that product simpler. Redesigning what you have into something that's intuitive and easy to use is scalable. As a principle, the most responsible path is to solve this problem by revisiting the drawing board. If a customer can use your product without relying on a human being, it makes them self-sufficient and ultimately helps them do things quicker, which saves everyone money. While that's an easy thing to say, it's a tough task to live up to. The best way to avoid this situation is to make design and user experience a core part of product development and hire an excellent designer early.

The Three Ways Software Companies Retain Customers

One of the most cherished things in the software business, particularly for externally funded companies, is maintaining a low churn rate. This is especially important to SaaS companies with monthly subscriptions because the cost of acquisition is often very high for each customer. This means that in order for the company to make a profit, every new customer needs to (at least) stick around long enough to pay back the initial acquisition cost.

Everything after that is called "profit."

In order to make back the acquisition cost, companies generally employ one of three common strategies to retain their customers:

"Let's consistently provide value"

The ideal way you want to retain customers is by offering a product that's actually worth paying for month over month. As simple as that sounds, it's not the strategy that most companies adopt. Many strive for it, but they often supplement it with one of the other two tactics as precautionary measures.

It's pretty easy to spot companies that have adopted this strategy: they're customer-driven. This means that they actively seek and act on customer feedback and emphasize the user experience of the product. Customer-driven companies make every feature and interaction focused on providing and proving return on investment. If you're paying for something that's not constantly proving it's value to you, then odds are you're being subjected to one of the other strategies:

"Let's incur a high setup cost"

This is typically present in enterprise software. These scenarios typically look like this:

  • A customer (let's call him "Joe") spends a month researching the product.
  • Joe spends another month arguing with sales to get a good deal and convincing his boss.
  • Then Joe and his company go through a 6-month integration process, which includes product training, certifications, etc.
  • As a consolation, the salesperson offers Joe a "once-in-a-lifetime" deal on the software, but the contract can't be suspended or transferred.

The guilt of walking away from all the work put in and the seemingly "great" deal is too much for Joe to handle, so he never cancels the software contract, even when he starts becoming extremely dissatisfied with it. The vendor knows Joe won't cancel because they've proven this strategy with all of their other customers. In response, they offer the bare-minimum it takes to keep him (begrudgingly) using the product.

But there's a caveat here: in this scenario, the vendor's worst nightmare is that Joe takes a job at a different company. When that happens, the vendor is left with a new contact who doesn't share the same integration pain or guilt that Joe experienced. This basically puts the company back at square one.

Some of the more cunning vendors will try to establish multiple points of contact at a customer's company to quell hasty cancelations. If you're being manipulated by this strategy, you probably already know it.

"Let's make our value non-transferrable"

The third and final type of retention strategy is to make the things the customer is creating inseparable from your software. There are a number of ways companies do this:

  • No "export" buttons anywhere in the product
  • Proprietary subsystems (e.g. a templating language)
  • Saving/storing data in non-standard ways

Support software is infamous for having very non-portable information. Despite the fact that they all follow the format of "question" and "answer(s)," most support programs don't offer an easy way to extract the data and move it to a new system.

This is a common strategy among companies whose value is in historic data. Support ticket systems, analytics, and CRMs are pretty likely candidates for this strategy because historic data is (theoretically) rich with insights.

It's very difficult to know whether you're in this situation. You can have fun with this by calling up your vendor and asking them for a dump of your data in CSV format.

Undeniably, the best way to retain customers is to deliver "awesome" on a regular basis. While sneaky methods may work in the short term, it's not sustainable. The customer base for most types of software is smaller than it seems, and a vendor can quickly burn through it by souring relationships.

Startup Secret: Hire Your Best Customer

The most important thing we did at Performable is to embrace our customers' feedback. In the early days, we were fortunate enough to have a handful of customers who believed in our vision and knew we were on to something much larger than conversion buttons and landing pages. Even now, we still maintain a sizable group of absolutely rockstar customers who constantly get involved in what we're doing:

Christopher O'Donnell

Originally from Transparent Language (now current customers), Christopher's feedback greatly helped shape the Performable toolset before we developed analytics, marketing automation or the idea of the customer lifecycle. Christopher's vision for the product and his enthusiasm for the team really made him stand out as a customer. He was emailing our developers nearly every day, asking questions and giving feedback. In the end, we literally hired him (in fall of 2010), and he's now a Director and Project Manager at Hubspot.

Robbie Mitchell

The skillset that Robbie possesses makes him an absolutely killer online marketer. He's comfortable in code, has an eye for great design and is deep into data and analytics. Most importantly, he values solutions that move the needle, something that's easily forgotten while buzz-words like "SEO" and "social media" are being thrown around so loosely these days. Because of that, Robbie has been great at keeping us grounded in reality. He sends us feedback at least once a week on our marketing tone, quality of support and the usefulness of the reports. Robbie's even come down to visit us and sat through user testing with several teams at Hubspot. He's even been a huge influence in the new social media application that we're developing right now. Robbie is an invaluable resource and a great sanity checker for features.

Sarah Hodges

Sarah is a marketer who is serious about analytics and data. This woman is so data-driven, we often use her data as a basic safety check that our systems were working properly. Sarah's helped us to answer the tough questions in analytics, like finding the lifetime ROI of paid and organic keywords. She's also helped us push forward on cohort reporting and communicating first-, last- and even-touch conversion attribution. You'll frequently see Sarah in Performable marketing material as well. She's helped us put together training videos, product videos and blog posts. Performable, now Hubspot Advanced, has so many other great customers who speak highly of us. People like Greg DeVore and Caroline Tien-Spalding have done so much to help push the product and the team in positive directions. Seth Godin has popularized the idea of making your customers into great sales people, but they can do so much more for your business. You just need the willingness to ask and the commitment to repay the favor.

Finally Giving in to Blogging

I've finally declared "bankruptcy" and decided it was really time to blog, and blog seriously. Being an aspiring entrepreneur at an innovative software company means getting awesome blog content hand-delivered to you every day. So far, I've made the stupid mistake of not capitalizing on that opportunity to share what I'm learning.

Please bear with me as I develop this blog into something amazing (and attractive to look at). I'm great at shipping products at work, but I've always been my own most critical customer (although my girlfriend is a close second :P). Tearing down my old portfolio site and putting up this ugly, default theme is a huge step for me.

That's the last time you'll hear me talk about myself. Now, on to writing compelling content :].