I took my first sabbatical this year, after Close started (generously) offering fully paid 4-week sabbaticals for all employees after 5 years.
Recently I spoke with our CEO, Steli, who just came back from his own sabbatical, about how our sabbaticals went and what we learned. Our conversation was recorded for our company’s internal podcast (we use Castos) but I thought I’d also write up some of my sabbatical thoughts and lessons learned while our conversation is still fresh…
We host our main marketing website, close.com, as a static site (in our case, generated via Lektor) served by AWS. We store all the staticly generated files in S3 and have a Cloudfront distribution in front as our CDN.
Occasionally, we’ll need to setup a redirect, to point an old URL to a new URL, for example when combining two pages.
In S3 hosted static websites like ours, there were basically two main ways to accomplish redirects…
This is the blog post version of a talk I gave at True University in Berkley, CA in June 2018 to help early stage startups scale their engineering teams from 2 to 20.
Hiring is hard. Really hard. I’ve been hiring on small startup engineering teams for the past 8 years (most recently grown Close’s engineering team from 2 to 14) and hiring really great engineers never gets easy. But it does get easier with practice and the right strategy.
Here I’m going to share some things I’ve learned about when and how to find the right people for your stage, how to structure a hiring process, and distributed/remote work. And most importantly: mistakes I’ve made along the way at Close.
I did an interview for the Close.io Inside Sales Summit, a free 5-day virtual summit with perspectives from 50+ leaders on inside sales. Ryan Robinson interviewed me for an engineer’s perspective on topics related to sales, including how sales teams and engineering teams can work best together.
Below is an internal team post I wrote to help us at Close.io do a better job of capturing customer’s feature requests in a way that leads to better product development outcomes.
I’m sharing this publicly because I believe this advice can help other startups and SaaS product companies as well.
When a customer request for a new feature come in, it’s easy to not log it at all (“we’ve heard that one before”) or to log it in a suboptimal way. Here are a few details on how to best capture customer needs and why it matters.
The typical, but unhelpful, way
The most common way feature requests are logged is in a “light” format like this:
A common pattern in SaaS apps is to allow a free trial period of 2 weeks or 1 month, and then to require a credit card to use it any longer.
Either out of curiosity or out of a genuine need for a tool that some SaaS service is offering, I will often sign up for a free trial soon after learning about it in order to check it out. For a variety of reasons by the time the free trial is up, I’m not ready to purchase.
It could be because I was just poking around. But more often it’s because I got too busy. Or my reason for signing up didn’t stay a high enough priority to be ready to purchase and fully implement some solution. Or maybe because the product just wasn’t far enough developed to satisfy what I was looking for.
What I find happening is that 3, 6, 12, or 18 months later I’ll find myself thinking about this tool. Perhaps the problem that led me to originally check out tools of the service has become more pressing than ever before. Or perhaps I’m fed up with another tool I chose, and am searching again for a better option. Or I’m hoping that the product has evolved more. Or whatever.
When logging back into your previously-created account, what you typically see is something like this:
What makes a new feature or product update “done” versus what makes it “really done”? At Close.io we developed our own process to answer this question, based on years of shipping new features for our sales communication platform. Today, we want to share this checklist with you.
Startup engineering teams face many decisions about what to build. At Close.io, many areas compete for the focus of our small engineering team. Customers often have one little thing they really need. Our team envisions the next big thing to move the product forward. There are poor UX workflows to optimize. We have an idea on how to grow our customer base faster. And of course there are always bugs to fix. The list is endless!
A small engineering team doesn’t have the time or resources to regularly improve every part of a product. It’s not uncommon for a section of an app, once launched, to remain untouched for a year or longer. We usually work to solve a problem or empower customers in a new way or fix a pain point, and then we move on to something else.
One reason I believe our super small team at Close.io has been successful is that we often solve multiple problems at once. When a feature needs to be built, we often expand the scope a bit to include other related problems or features that naturally go together with the first one.
Since my wife got a nursing job in Stockton, I’ve drastically increased the time I spend working while traveling, in coffee shops or hotels where I don’t have my typical desk and monitor setup. Since I get a ton of compliments and questions about it when I’m working from Starbucks all day, I thought I’d share my ultimate mobile workstation guide.
I built a quick mashup/integration between two services that I love using, that I thought would be “better together”. It’s live at ArticleListen.com.
I use Pocket to save a queue of any article (blog post, news story, etc.) that I see on Hacker News, Twitter, Facebook, etc. There’s a web & mobile browser extensions for saving articles you see, and Mac & iOS apps for reading these articles later all in one place, even offline.
I just finished reading “The Elements of User Onboarding” by Samuel Hulick. I discovered the book through the excellent site UserOnboard.com which has chronicled every screen in the onboarding process of several web and mobile apps and added great commentary (positive & negative) on each screen.
If you help make a web/desktop/mobile app, I highly recommend going through a few of these teardowns, as they alone will make you re-think some parts of your onboarding process. These teardowns together with the book have given me lots of great ideas for drastically improving the liklihood that a new user of Close.io will become successful.
For each chapter, I wrote down a brief summary or simply something that stood out to me. By all means, this isn’t a replacement for getting the book – but a teaser and reminder to myself what I read!
Sales4StartUps: Tell us about the Close.io story. How was it started? What problem were you trying to solve?
Phil: Close.io was developed as an internal product to make our own salespeople at ElasticSales more efficient. Our company was doing sales for a bunch of companies (with different types of sales processes and needs) and through all these difference sales campaigns we recognized a lack of good software geared at the day-to-day tasks a salesperson faces. Our team needed to be able to make many phone calls quickly, send more emails, and see a history of sales activity for any given lead without having to do a bunch of manual data entry, and surprisingly none of the solutions we tried seem to actually be designed to make salespeople’s lives better in these ways.
After several of our customers asked if their salespeople could use our software (since they saw our productivity improvements from it), we decided to focus on productizing it, and Close.io was born.
Coinbase is one of the best Bitcoin related sites/services. They’re certainly the easiest way to buy or sell Bitcoin if you have a U.S. bank account. When I saw their Bug Bounty program where they offer $1,000 USD worth of Bitcoin if you find a security vulnerability, it improved my trust in their security, but of course also made me want to look for security bugs…
I’ve been wanting a standing desk at home, ever since our old Elastic office had standing desks. The key though is getting it to be the perfect height, and not spending a fortune. After some careful measurements I determined that my standing desk surface should be exactly 40″ from the ground, so that my arms at ~90 degree angles would fall perfectly on them when I’m standing (I’m 5’6″ or 5’7″).
I recently had to look at two different legal documents (PDFs) that were mostly the same, but I wanted to spot any differences.
My first attempt was to install the cross-platform GUI tool DiffPDF. This mostly worked but was annoying because it seemed to basically only diff within a page – so if your paragraph bumped to another page in the new version of the document, you couldn’t really spot changes.
Then I installed pdftotext with macports: “sudo port install poppler”. From there you can diff the two text files, like normal.
My blog post on the Close.io blog was pretty popular (18,000 pageviews & lots of HN comments) so I wanted to cross-post it here:
Sweating the UI & UX details in Close.io: Emails & Email Addresses
We like to think of our sales software, Close.io, as having a lot of magic under the hood. When we do our jobs successfully, our users may not even notice, but their lives will be made a little easier. We try to make features just work without requiring users to think too much, even if that adds complexity in code.
On my goals list for 2013 was to write an eBook of some sort. When I was approached to join some other Backbone.js contributors in a “book sprint” to write a book on developing a Backbone.js application, I happily accepted!
The process went fairly smoothly (all things considered, when 5 people all write a book at once, mostly over a weekend). There were some challenges with timezones and schedules, but overall the team did a great job getting it done.
We use git and GitHub’s Pull Requests fairly heavily in developing Close.io sales software. My main problem with pull requests as code review is that it focuses my attention too much on the specific lines of code added/removed/modified, but not enough on the context of where they were added/removed.
In creating Close.io software for salespeople, we rely on a number of other startups and services to do what we do. While there are alternatives to using each of the following, we have chosen them for specific reasons because we think they’re the best.
The common theme is that these services allow us to move faster and have better insight into our business. We could live without any of them, but it would mean slower iteration and less innovation.