Growth Tip: Email newsletter subscribers who haven’t tried your product to understand why not

If you have a newsletter that includes people who haven’t tried your product, you can learn a lot by emailing those people and asking why they haven’t tried your product.

It helps you understand not just about where they may be from a sales opportunity perspective, but also to learn about their perception of your product. For example, maybe they don’t know about your product, or thought it worked in a different way, or thought it was comparable to a product they already use, or didn’t realize it could help them, or thought it did something completely different than what it actually does. You can then use what you learn to optimize your sales and marketing efforts.

Hat-tip Tim Thyne for the insight.

Edit: And also hat-tip to John Bonini, Director of Marketing at Databox, for sharing the idea with Tim.

On the Benefits to Customers of Paying Annually

Highlights from a discussion at Help Scout about the benefits to customers of paying annually:

  • Finance teams will plan or budget for their teams web apps cost for the year.
  • Similarly, most managers prefer to know their budgeted spend and to make that spend upfront. It helps them avoid mid-year “I need more money to pay for our software” surprises.
  • This also helps managers secure their budget and get their needs resourced upfront because later on they may find their budget is cut and anything that isn’t already committed can be subject to those cuts.
  • During the planning stages for purchasing software, there is often an ambitious vision for the roll out. By securing the resources/budget for an entire year, it helps the manager realize that vision.
  • The ideal behavior is letting companies prepay, but then drawing down on that credit based on usage/engagement. It helps companies avoid paying for services they aren’t using and also lets the business earn more for companies that grow during the year. (We do this at Help Scout and I’ll write a detailed post about the mechanics of it in the future.)

Hat-tip David McFarlane for these insights!

On Making it Easy for Customers to Quickly Choose the Right SaaS Plan

One of the benefits of working with so many brilliant people at Help Scout is that I’m exposed to a lot of wisdom about how to build and grow a SaaS company.

I’m going to try to start sharing more of that wisdom here, not just for my own records but to help anybody else looking to build or grow their own software business. To avoid sharing anything competetive I won’t always be able to provide context, but hopefully the quotes mostly stand for themselves.

On SaaS plans:


In self-service models, it’s really important that customers have no hesitation about which plan to choose. They need to immediately know when they look at the plans which one is right for them.

And on pricing pages:

Pricing pages are the revenue powerhouse in a self-serve model.

Counting in MySQL When Joins are Involved

There’s a MySQL pattern that I use fairly frequently that I want to share, both to help anyone else who might find it useful and also to find out if there’s a beter way.

Here’s an example: you have one table for users, another for posts, another for pages:

And we want to know how many posts and pages each user has:

Attempt 1: COUNT with JOIN

For the moment, lets focus on just getting the post count by user.

We might be tempted to try JOINing the two tables and using COUNT:

The problem is that when we JOIN the two tables, the results will only include users who have posts. In this case, there’s no result for Jen (user id 3) because she doesn’t have any records in the posts table.

Attempt 2: COUNT with LEFT JOIN

Ok, so if JOIN doesn’t work, lets try LEFT JOIN:

Now Jen has a count, but it’s reflecting 1 post, not 0 like we expect.

We can see why it’s broken by looking at the LEFT JOIN results without aggregating them:

Jen doesn’t have any posts, but because we’re LEFT JOINing, her users record is still included. When we then aggregate the results with GROUP BY and COUNT, MySQL sees that the results have one record so returns a count of 1.

A better way to do this (as suggested by Tom Davies) is instead of counting all records, only count post ids:

Attempt 3: SUM/IF, and LEFT JOIN

Another way we can achieve what we want (for a single table join) is to use SUM/IF:

Here we’re saying “When the post id is null, give it a 0, otherwise a 1, then sum the results” which gives us the correct count. This is actually I trick I learned from the real Jen while at Automattic :).

The problem arises when we need to join multiple tables:

Now instead of Simon (user id 2) having 2 posts, he has 4 – what happened? Again, we can look at the un-aggregated results:

The problem is that each post gets joined with each page result. Simon has 2 posts, each of which gets joined with the 2 pages, so when we use COUNT it sees 4 results and returns that amount.

The solution: Subqueries and COALESCE

Here’s how I would solve it:

To understand how it works, lets focus on counting posts. The first subquery counts how many posts each user has if they have any posts:

We can then LEFT JOIN users on this derived table:

For the users with posts, the result has the post count. For the users without posts, the result is NULL. This is where COALESCE comes into play. COALESCE takes any number of arguments and returns the first non-NULL result:

So we’re saying “If the user has a posts count, use that, otherwise use 0”.

We can then LEFT JOIN again on the pages table and do the same thing with the pages count to get the posts and pages count per user. Because each subquery only returns a max of one result per user, we don’t run into the issue we did earlier where posts get joined with pages to return the incorrect count.

Somewhat complicated, but the only way I know how to do it. If you know of a better way, please drop a comment below. Thanks!


This simpler method also works:

By counting distinct post ids and page ids, we avoid counting NULLs and also avoid counting duplicates due to joining on posts and pages.