Companies with large sales teams tend to negotiate more on pricing

Another insight from Tim Thyne around pricing:

If a company has a large sales team, they have more capacity to work 1:1 with potential customers to close deals, even small ones. That means that they will tend to negotiate more on pricing compared to a company without a large sales team. Remember that when you see the pricing they display on their website: the actual price that their customers pay is likely less than that.

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.

Experimenting with waking up early to work on side projects

In the past when I’ve worked on side projects it’s been primarily on nights and weekends. Between school and work, I never had time for them during the day and because I’m not much of a morning person, nights and weekends always worked better.

When my son was born about three years ago, a lot of the time that I would have put into side projects went towards trying to be a good dad to him and now also to my daughter. This led to less time during the week because after I would get done with work, I would spend time with them and after they would go to sleep, I wanted to spend time with my wife and relax. I also can’t stay up too late because I needed to get up with the kids in the morning. Similar story on weekends.

This has led to my side projects time dropping from maybe 10-15 hours/week to only 3-4 hours/week for the last several years.

Inspired by my friend and coworker Dave Martin, I’ve started experimenting with waking up early to work on side projects. Not 4am-5am like him (!), but just at 6am. That gives me 1 to 1.5 hours to focus on side projects most days. I take Saturday off and also wind up skipping some other days, but it’s probably doubled the amount of time I put into side projects to around 7-8 hours per week.

To make this work, I’ve also had to adjust my evening routine. Instead of going to bed around 10:30pm, I try to be in bed by around 9:30pm to make sure I get in 8-9 hours. I wind up watching less Netflix, but don’t feel like I’m missing anything important.

And as a side effect, I’ve found that I’m sleeping a lot better now that I’m no longer jumping straight from coding into bed a lot of nights. All too often I’d just lie there for hours waiting for problem solving mode to turn off. Now I read and it makes it much easier to fall asleep.

If you typically work on side projects at night like I did in the past, I encourage you to experiment with waking up and going to bed early for a few weeks to see how it works for you.