I'm Director of Engineering & Product at Close. I'm interested in startups, programming, UX, SaaS, and building great web products. More about me.
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…
Read the rest of this entry »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.
Read the rest of this entry »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/
Read the rest of this entry »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 most common way feature requests are logged is in a “light” format like this:
Read the rest of this entry »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:
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.
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 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!
We’ve been getting some great press and feedback since launching Close.io software for salespeople.
They’ve got a couple good quotes from me in the PandoDaily article.
At the end of a year I like looking back and seeing what I’ve accomplished and what new technologies I started working with in the year. Here’s a little summary.
On Close.io we originally implemented Filepicker.io to allow for file uploads while sending emails. While it was a quick way to get started with file uploading initially, after several minutes of downtime of their API and then an unannounced change in their JSON response format, I was reminded once again that you shouldn’t to rely on small startups for critical parts of your tech infrastructure.
There’s nothing wrong with filepicker.io if you want to use a lot of their features, but in our case we just needed to allow simple uploading of files to our own AWS S3 bucket. Here’s how:
Read the rest of this entry »
I had my first guest post on TechCrunch last week! Here’s an excerpt:
There is often confusion about the various roles of a web engineering team. I have had to explain, even to technical recruiters, the differences between these roles and that the lines that separate them are often fuzzy. I thought I’d share the framework I like to use to evaluate whether someone is a good fit for a startup’s technical team.
In a startup, you can’t afford to have people who are only able to do one thing. Someone could be adept at writing HTML/CSS, but if they don’t have a great eye for design or know JavaScript well, it’s just not worth having them on the core team. Similarly, somebody who knows a little bit of everything but isn’t advanced in anything will just drag the team down.
The size of the company or startup will determine how many different hats each engineer must wear. Many startups get off the ground with a single founder who does a little bit of everything until he or she can grow the team. It’s also possible to outsource some roles completely. Just as cloud-hosting providers such as Amazon Web Services have drastically reduced the need for hardware/network engineers in web startups, platforms like Heroku take it further and (for a price) can reduce sysadmin and DevOps work almost entirely in the beginning.
In pretty much every case, when a startup grows, people will inevitably start specializing. Even those rare gems, who in the early days can spend the first half of the day in Photoshop and the second half scaling a database, will eventually specialize at least somewhat. If you’re hiring well, you’ll always find someone who can outperform you in at least one area.
I’m a big fan of “full stack” people and think specializing too much, too early, is a bad sign for startups. At Elastic, each of our engineers has written CSS and done database/server management. It’s good when a problem arises for there to be more than one person capable of fixing it. That said, I’m spending the bulk of my day writing in JavaScript/Backbone.js because I enjoy it much more than a coworker who’d rather be in Python as much as possible. That’s healthy and it works.
You can read the rest over there.
I just launched a website for Close.io, the product we’ve been working on at Elastic for the past few months.
Go check it out: http://close.io/
We’ve built this as “sales communication software”, which we believe didn’t really exist before. CRMs (salesforce.com, I’m looking at you!) are inadequate because they are more like databases of contacts than software that really helps you do the selling. We’ve trying to change that by making your sales phone calling and sales emailing experience tightly coupled with your lead data (CRM).
Would love to hear any feedback you have about the product!
I got to go to Y Combinator’s Startup School this year and had a great time. Between the reception dinner the night before and the day of event I got to meet a lot of great people and reconnect with some I’d met in the past or only talked to online. Most of the speakers were really good.
I took some very brief notes during some of the talks of the 1 or 2 things that stuck out to me as either surprising, motivational, or instructional.
I watched Jeff Veen’s “Designing for Disaster” talk (below) and took away a couple of parts that I thought were really good. Some notes:
How to do Product Reviews (can be design, product, process, anything) — making an objective process out of something that is very subjective.
It’s 2012 and the web and mobile devices are capable of amazing things, which is why it’s so surprising to me that some of the simplest things are still so hard.
I’ve got the latest iPhone with its 8MP camera and HD video camera, complete with iOS 5 and I pay for extra storage on iCloud. Apple’s supposed to be the best at designing simple user experiences across hardware and software – and I believe they are.
So when I want to take a bunch of photos and videos that I took from my iPhone and share those with some family members, it should be simple right?
The last two years (2010-2011) I spent working at Quizlet were an incredible learning experience.
Like I did in Jan 2010, I wanted to reflect on some of the technologies I learned and things I did over the last 2 years…
I hate to have my first blog post after over a year be a negative one, but I feel like these guys need calling out.
I recently received an email from a company, Honestly.com, that got me quite curious. I looked up the website to see what it was all about, and I saw that they are a way of reviewing former/current coworkers and business partners. Their tag lines are “Get the inside scoop on your potential boss, coworkers, or business partners.” and “Candid community-created reviews of business professionals.” I sort of expected them to be a more extensive version of CubeDuel (which was quite fun for the first few minutes), but with full reviews rather than just ratings…
