In recent years I’ve been doing less blogging here, but writing more on Twitter.

When I have a bit more to say, I’ve found Typefully as a really nice writing tool. They also have a “Profile” view that rolls up tweet threads into blog post form. My latest posts are here:

https://typefully.com/philfreo

Enjoy!

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…

I built a micro-SaaS as my pandemic side project:

TeamHome.app – An internal company directory designed for remote teams. Try it out and let me know what you think.

Read on for details & some background…

As an engineering team at @Close, we’re trying to write more about what we are learning/doing. I recently got to dabble in a little coding project, so I wrote it up. This post originally appeared on the Close Engineering Blog here.

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.

Watch the interview here: https://www.insidesalessummit.com/interviews/wednesday/phil-freo/

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:

There are two types of people in this world:

1. People who archive incoming emails when they are finished with them, and try to achieve “inbox zero”
2. People who leave all incoming email in their “inbox” forever but use “Mark as Unread” or Star/Flag message to indicate items still requiring action

If you’re a Type #1 person, you can stop reading now.

If are a “never archive anything” type person, I’d like to make a case for why you should become an “inbox zero” type person and archive emails when you’re done with them.

Read the rest of this entry »

I got interviewed for my first podcast recently. It’s called HackToStart, and it’s one that I’ve been listening to for a while now, so I was excited to be a guest on the show. Check it out here:

Hack To Start | Phil Freo, Full Stack Developer, Close.io

In the show we also discuss one of my latest blog posts: The last 20% before shipping.

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.

Read the rest of this entry »

One of my tweets is featured in an article on Mention.com:

How Close.io Closed $585 in Monthly Revenue from 1 Tweet.

Check it out!

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!

Read the rest of this entry »

Sales 4 Startups published an interview with me about Close.io.

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…

Read the rest of this entry »

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″).

Read the rest of this entry »

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.

I’m working on invoice/receipt generation for Close.io and wanted to create simple PDFs using nothing but HTML.

Using Flask, mimerender, and xhtml2pdf, here’s how:

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.

Here are a few examples:

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.

Read the rest of this entry »

Originally published on the Close.io blog.

The startups and services behind Close.io