PhilFreo.comhttp://philfreo.com/blog
The portfolio and blog of Phil Freo, on web design, development, and entrepreneurship.Sun, 05 Jul 2015 22:06:41 +0000en-UShourly1http://wordpress.org/?v=3.8Why you should Archive your emails when you’re done with themhttp://philfreo.com/blog/archive-your-emails/
http://philfreo.com/blog/archive-your-emails/#commentsTue, 23 Jun 2015 23:02:34 +0000http://philfreo.com/blog/?p=677There are two types of people in this world:

People who archive incoming emails when they are finished with them, and try to achieve “inbox zero”

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.

You may be thinking, “who are you to tell me how to manage my email!?” It’s true, I have no right to that, and I understand that different people have different workflows. But I have heard all the reasons and still strongly believe all Type #2 people would be better off if they become Type #1 people.

I have made my case to several people over the last few years and all of them that have ever tried it have thanked me later. I believe there is really no downside to becoming a Type #2 person and only upside.

I know that not everybody is used to archiving their email, but I’d like to make a case to you that it’s not any more difficult and that if you give it a shot, it will really help your workflow. First, let me address the top 3 reasons people usually give for why they don’t archive currently:

“Archiving is an unnecessary extra step”

The thing is, it’s not really an extra step to archive an email once you’re done with it! From Gmail it’s a single keyboard shortcut or a single click of the Archive button. You’d have to click Back anyway so it’s 0 additional steps to archive a message instead.

“I keep emails in my inbox so I can find them later easily”

Emails are still searchable even when archived, and you can see all those messages in Gmail under All Mail. Archived mail is not lost, it can still be easily browsed and searched.

“I treat ‘unread’ or ‘starred’ messages as my actionable items list, which is just as good as archiving”

Abusing the “Unread” feature to keep emails around that you actually did read but just haven’t finished handling / responding to yet is unwise for two reasons. First, it prevents you from having a true list of actually unread emails.

Second, using Unread status or Stars/Flags to indicate actionable items means that your inbox is a mix of “emails I’m done with” and “really important emails I shouldn’t forget to handle or respond to”. Those items are interspersed. Sure, having items as bold (unread) or starred can make the important ones stand out, but what happens if you don’t remember to handle them before they end up on page 2? With an infinite inbox, it’s too easy to lose messages that you saw but didn’t handle yet.

Even if you always handle these items before they get too far back in your inbox, it means you’re doing lots of extra mental work by having to continually scan your inbox for items that need handling. You have to keep seeing the already handled items unnecessarily which means more things for your brain to process. Wouldn’t it be better if there was a single concise list of emails requiring further action?

Why archiving is better…

We’ve established that there’s really no downside to archiving all email once you’re done with it. Let’s talk about the upside.

When you archive messages you’re finished with, what you’re left with is an inbox that consists only of actionable items. No more continually re-scanning past dozens of emails that are no longer important, in search of the one you need to reply to. No more lying to your email client saying you haven’t read an email after you really have. No more losing important emails in the stream.

Start out by doing a bulk archive of everything in your inbox that you know has been handled. In Gmail there’s a Select All checkbox, then a second link appears at the top to truly select all. Then you can click Archive.

When a new email comes in, of course you first need to read it (or at least skim the subject/sender). If you decide you’ve read enough and it requires no action, then simply hit Archive! If you’re done your part and replied to a message, hit Archive! If the email represented a task and you finished the task, hit Archive! If it’s a newsletter and you finished reading it, hit Archive! (If it’s a newsletter or promotional email you never care to read, then Unsubscribe… and then Archive!)

Now, you can look at your inbox anytime to see and handle emails that still need more reading, responding, or action.

Let me know how it goes!

- Phil

P.S. The best products, in my opinion, encourage an opinionated workflow that promotes success. It’s from this workflow that we built Inbox in Close.io, which syncs your CRM and your email account for an Inbox of actionable sales-focused items.

]]>http://philfreo.com/blog/archive-your-emails/feed/0HackToStart Podcasthttp://philfreo.com/blog/hacktostart-podcast/
http://philfreo.com/blog/hacktostart-podcast/#commentsTue, 23 Jun 2015 21:22:10 +0000http://philfreo.com/blog/?p=674I 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:

]]>http://philfreo.com/blog/hacktostart-podcast/feed/0The last 20% before shippinghttp://philfreo.com/blog/the-last-20-before-shipping/
http://philfreo.com/blog/the-last-20-before-shipping/#commentsSat, 23 May 2015 14:05:21 +0000http://philfreo.com/blog/?p=668What 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.

As soon as a new feature you’ve built is running and working on your development server, there’s a strong temptation to think it’s “done”. You want to ship it. After all, the code is working, and you know many of your users would benefit immediately from the change.

It’s important to stop and ask yourself: What else should we do other than just making a new feature functional? How can I improve the experience for users or make this feature more accessible and maintainable?

We’ve learned that when you’ve only gotten a feature working, you are at most “80% done” and that the last 20% really makes all the difference. In fact, sometimes the “last 20%” of polishing a feature can take just as long to get right as the “first 80%”, however it also is what separates good from great.

Here’s our internal checklist that we use before launching significant new features or changes. Whether for launching a new reporting feature or migrating our database to a different cluster, we’ve found this list to be really helpful.

Performance

Is it fast?

Are the database queries optimized?

Will it scale for a large number of records?

Code quality

Is the code cleaned up, organized, and properly abstracted?

Is it well commented / documented? Assume someone else will have to maintain it.

Are there relevant unit tests?

Edge cases

Do you consider and properly handle edge cases and invalid inputs?

Did you test the first time experience / no-data-yet case?

Is it localized? Consider timezones for anything date specific, and unicode.

Did you test in all the supported browsers / platforms?

Have you tested for potential security vulnerabilities?

Polish

Does the UI look polished? Is it consistent or better than the rest of your application?

Does the UI react to various edge cases properly?

Is any written text as good as it can be? Did you check for typos?

Deployment

Does it need any special deployment process, and is the process well documented? Any data or schema migrations necessary?

Is everything backwards compatible? If not, did you communicate the change to users?

Should it be deployed/visible to employees only to dogfood/test for a while?

Communication

Are the relevant API docs complete?

Do any FAQ docs need to be updated or written?

Did you write a blog post announcement, if appropriate?

There you have it. Run through this list before shipping something new and you’re guaranteed to have a better launch.

Do you have anything to add to the list? Let me know!

]]>http://philfreo.com/blog/the-last-20-before-shipping/feed/0Solve multiple problems at oncehttp://philfreo.com/blog/solve-multiple-problems-at-once/
http://philfreo.com/blog/solve-multiple-problems-at-once/#commentsSat, 14 Mar 2015 19:27:13 +0000http://philfreo.com/blog/?p=612Startup 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.

Another way to phrase this idea is: rather than solving a problem, solve an entire class of problems.

While this advice may sound obvious, there’s enormous pressure to finish a project as quickly as possible. There’s always the next important feature, bug fix, or redesign from the roadmap to move on to. Shipping even the smallest version of a feature on time can be difficult enough already, since software schedule estimating is never easy. But there’s great value in not just shipping a feature or fix in the smallest form possible.

Application: Fixing Bugs

Let’s start with a simple real-world application: you notice a bug that needs fixing. After some investigation you figure out what the problem is and how to fix it. You fix it and maybe even add a unit test for this case. Time to move on, right?

NO! If you stop there, you’re making a crucial mistake.

At a minimum, you should try to figure out if the same bug exists anywhere else in the codebase. Often a single ack search is enough to find the same bug in many places. Next, consider if there might be other conceptually similar versions of this bug elsewhere. Ideally you’d also follow The Five Whys and discover how this bug got introduced, how it got past code review and QA, etc.

Again, this advice may seem obvious, but consider someone’s natural instinct when a user complains. These complaints usually come in the form of a vague problem (e.g. “it won’t let me change my email address”). First you figure out what the real bug is (e.g. “The form for changing email addresses doesn’t show a confirmation message”). Bugs usually come in very specific forms like this. It’s not uncommon for a programmer to simply fix the bug and move on. But it’s important to stop and consider if similar bugs may exist elsewhere (e.g. “how form confirmation messages work throughout every part of the app”).

It’s the sign of a mature programmer to ask “why” and consider preventing future bugs of a similar type.

Example: A broken URL on Close.io

I recently noticed a problem with a specific URL on our site was not working. I discovered the cause was that two Python view functions in our Flask app shared the same name, which just silently breaks one of them. My first instinct was to rename the broken view with a unique name, and move on.

But I remembered it wasn’t the first time this had happened and I recognized it likely wouldn’t be the last, so I thought about the problem more broadly. I knew a syntax issue like this should be detectable, so I spent some time setting up pylint and reviewing its results. Pylint uncovered another case of the same error, as well as other types of logical errors elsewhere, which I fixed. Finally, I added pylint to our continuous integration system to automatically detect any Python syntax issues in the future.

So rather than fixing the broken URL, I fixed all cases where URLs were broken for the same reason. I also found and fixed other unrelated instances of “detectable” syntax issues. And I also automated this process so that this entire class of issues can never happen again. Do you see how much more powerful this type of fixing can be?

Once you’ve discovered the specific causes of a bug, there’s no better time to find and fix other similar bugs. Even when the roadmap begs you to move on, the benefits of squashing related problems are even stronger:

It’s good practice to fix bugs before writing other code (#5 in The Joel Test)

If you can discover and fix bugs before more users experience and report them, you’re preventing user pain.

You’ve already done the hard part of figuring out the specifics of the problem. If you don’t completely resolve it, you’re forcing a teammate or your future self to have to waste time relearning the same thing!

Don’t just fix bugs. Fix an entire class of bugs.

Application: Designing Features

The temptation to solve a single problem at once is even larger when it comes to features. Features are often a response for solving a user’s pain point, or an idea designed to empower your users in a new way. Naturally, the team is excited to ship as soon as possible.

Furthermore, a good product designer will optimize a feature to be as simple as possible for the specific workflow it’s designed for.

The problem is that over time, rather than designing one cohesive experience, you’ve glued a bunch of individual features together. If you’re only thinking about solving one specific problem at a time, you’re missing the bigger picture of how everything will fit together.

Software written in this way turns out to be super complex because hundreds of small problems were solved separately rather than a few big problems being solved elegantly.

Don’t design a single feature; always be designing for the bigger picture.

Example 1: Close.io Search & Filtering

An example where I think our team nailed this early was with search and filtering. From ElasticSales we knew that salespeople would want to slice and dice their leads in a million ways.

When starting Close.io it would have been understandable if we solved this initially by just slapping a couple of the most commonly requested filter options, like “Lead Status”.

However we knew that this was a narrow and short-term solution. It wouldn’t be enough to last and wouldn’t be enough to “wow” people. Quickly, power users would outgrow our simple filters and we would be forced to keep adding additional one-off filters and complexity. We’d have to keep redesigning as the number of filters grew and redesigning again for each new idea like exclusion filters or nested “OR” conditions. We would have started fast but slowed very quickly.

Instead, we designed a framework to solve the larger problem. We invented a search language and then UI to allow filtering by a very large number of useful sales attributes and combine them together with boolean and/or/not keywords. It took longer to do it this way than just adding a couple basic filters. But we established a paradigm of how searching and filtering worked in Close.io that has powered innumerable use cases our customers needed and has lasted 2+ years. Our customers rave about its power, and PandoDaily wrote about it.

I’m definitely not saying we had to build this feature to 100% completion from day 1 (and we didn’t – we still iterate on it today – and in many ways it’s very far from complete). But thinking through a scalable solution for this problem rather than slapping on a few quick filters has given us a big advantage. Having an end goal in mind allowed us build a version 1 that didn’t have to be thrown away when we built v2 and v3. We have ideas for what an amazing version 5 and 10 may look like, and we won’t have to start over – all because we planned ahead to solve search & filtering more broadly.

Example 2: Close.io Reporting

Some of our competitors have dozens of individual “reports”. They tack on a new report every few weeks because users always want more reporting. Close.io was really far behind in reporting but the thought of adding dozens of reports made us want to cry. So instead we built one super powerful charting tool (Explorer) that, in one fell swoop, allows you to visualize almost any attribute of your teams’s sales activity.

Example 3: Close.io Bulk Actions

We needed to build a way for users to “bulk delete” all their leads. Rather than building this alone, we designed a system that would work for not only Bulk Delete but also Bulk Edit and Bulk Email (two other features we knew we wanted to build). Because of designing for this, we were able to later launch the additional two features within a very short period of time. Coding the two additional features became much simpler and the UX for all bulk actions was considered together rather than tacked on without cohesion.

Architect your product to solve an entire class of problems at once.

If you don’t, you’ll end up with software that’s missing important features and users will quickly outgrow the one thing you helped them with. Or you’ll keep tacking on additions in a non-cohesive way which makes a complex product over time.

Said another way: it’s easier to end up with both successful users and a cohesive UI & UX if you solve and design for a few big problems rather than a bunch of individual little ones.

Application: Refactors

Technical debt can clearly become a big problem and slow development. But it almost never feels worth rewriting something just for the sake of code quality. The benefit of doing projects solely to “pay back” technical debt is hard to justify.

The best time to solve technical debt, refactor code, etc. is in the midst of making other changes to that part of the system. When you’re working on an improvement involving a problematic part of the codebase and you’re considering making bad code even worse… go ahead and take the extra time to refactor and improve it. There’s no better time to do so, since you’re already having to grok how it works and carefully test those parts related to your improvement.

Application: Redesigns

When redesigning how one part of your product works, consider how the rest of your product works. It may be easier to solve multiple problems that relate to each other all at once.

Example: Close.io Onboarding Process & Email Setup

We wanted to introduce a set of onboarding steps for new Close.io users. One step would be an easier way to connect your email account (for our 2-way email syncing to work) rather than having users do so later in Settings. What we did is build and launch a few features all at once:

Use OAuth instead of passwords when a Gmail / Google Apps account is detected

Support for multiple email accounts & identities per user

Not all of these features were crucial for the main priority at the time, which was to improve onboarding and make it easier to setup email. But they made a lot of sense to build together, since they were interrelated. We would have had to redesign, recode, and retest the Email Settings page regardless so it was the perfect time to design it to support setting up multiple accounts.

Supporting multiple accounts is a valuable feature that we always planned on building. But if we hadn’t built it alongside these other features, it likely wouldn’t have become a big enough priority to get built on its own for quite some time. By building to solve multiple problems at once, we were able to do more, faster, than had we been trying to solve independent problems in serial.

Risks & Rewards

You may now be thinking, “Isn’t this scope creep, and isn’t scope creep a bad thing?”

Indeed, if you keep expanding the scope of your projects to solve more and more problems you will never ship or meet deadlines.

But I’m actually advocating for more planning. More deliberateness in your design decisions and planning. More hesitation before starting projects that only solve only one problem. Design your product with end goals in mind. Design code and processes with your future team in mind.

Expand a project scope opportunistically where it makes sense. Reschedule items onto the roadmap sooner if they are easier to build alongside whatever your current priority is. Often you won’t return to a problem for many months or even years. So if you can put an entire set of problems to rest all at once, do it even if it takes a bit longer.

The principles I’ve been talking about should help you make a much better product over time. When you solve one problem, it’s not that much harder to solve a bigger class of the problem.

The way to keep from turning this advice into scope creep is to slow down. Not slow down in the sense that your team & product shouldn’t be moving quickly. But slow down in the sense that you should do less, but better. Do fewer things, but more that have longterm impact. You can’t do this for everything, but try to do it for the important parts.

So the next time you design a feature, fix a bug, or otherwise try to improve your product, ask yourself, “Can I solve multiple problems at once?”

]]>http://philfreo.com/blog/solve-multiple-problems-at-once/feed/1My mobile workstation setuphttp://philfreo.com/blog/my-mobile-workstation-setup/
http://philfreo.com/blog/my-mobile-workstation-setup/#commentsWed, 21 Jan 2015 17:48:10 +0000http://philfreo.com/blog/?p=623Since 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.

My main requirements:

Allow me to get a lot of work done, be comfortable, and have good posture. Replicating my in-office experience as much as possible.

Easy to transport in my backpack

Here goes!

Laptop Stand: Why? Because hunching over a laptop screen is terrible for you. The trick is finding something that’s portable and comes as close to replacing a monitor as possible.

Best option: The Roost Stand. (~$85). It folds up extremely small and is incredibly lightweight. It also has a really great elevation height – higher than any other stand I’ve seen (but not too tall). Definitely worth the money if you work on the road a lot. It has a unique way to hold the laptop firmly.

Cheaper option: Griffin Technology GC16034 Elevator Laptop Stand (~$32). I used this at first and it works well and is collapsable into 3 pieces. Compared to The Roost, this stand does make it faster to quickly lift your laptop from it since it’s a simple platform. But it does take up a fair amount of backpack space and isn’t super lightweight, nor is the height quite as tall as I would have liked. So for me, The Roost was a great upgrade.

Keyboard: I use and am very happy with Apple’s Bluetooth Keyboard (~$64). Looks nice, works great once it’s paired once, and is very slim. There are also cheaperoptions that probably work just as well. Just be sure to get a small one (no number keypad) so it doesn’t take up much backpack room. At my office and home desk I like USB keyboards, but while traveling having fewer wires (via Bluetooth) is a big plus.

Mouse: At work, at home, or while traveling I always use a Logitech Wireless Performance Mouse MX for PC and Mac (~$60). I’ve tried a lot of wireless mice and have happily been using this one for the last couple years. It does have use a tiny Logitech Unifying USB wireless receiver (I had lagging/performance issues with Bluetooth mice).

Headphones: While any headphones can work and simple iPhone earbuds are the most portable, I ultimately got Samsung LEVEL Noise Cancelling Wireless Headphones. They aren’t cheap (full price ~$300, though you can often find them cheaper) but I got them for a few reasons:

Bluetooth. Previously I used simple wired Sennheiser HD-280 PRO Headphones ($87) but mine were falling apart and I liked the idea of not having a big coiled wire hanging off my Starbucks table or getting tangled in my airline seat and being able to run to the bathroom at home without stopping whatever I’m listening to.

Noise canceling. Actively blocks out background noise from the coffee shop, though this is especially nice for use on airplanes.

Portable. They come with a nice semi-hard case. It takes up a good bit of room but is nice and protects them from getting ripped in my backpack.

Standing Desk: It’s good to mix sitting and standing throughout your day. At home I made a cheap standing desk. At work we’ve got Steelcase Series 7 sit/stand desks. But these options won’t work while traveling. Fortunately I’ve noticed that almost every Starbucks I’ve visited has some hightop tables that happen to be at the perfect height for me to stand at. I’ll just alternative every hour or so between standing and sitting. In hotel rooms, I’ve gotten creative with putting my laptop (or laptop stand) on top of various furniture if I want to stand.

Internet: Finding solid internet is crucial. In Stockton, I’ll only work from Starbucks with Wifi powered by Google because those are way faster than the rest.

Power: Whether it’s at an airport, coffee shop, or conference, there’s one little trick that allows me to almost always have access to power outlets, even if it looks like they are all full. I simply keep this little power outlet splitter cube in my backpack. Then even if an outlet is full, I can plug in to create an extra outlet for myself, the original plug, plus an extra free slot.

Here it is…

]]>http://philfreo.com/blog/my-mobile-workstation-setup/feed/0How one of my tweets landed Close.io a $585/month customerhttp://philfreo.com/blog/how-one-of-my-tweets-landed-close-io-a-585month-customer/
http://philfreo.com/blog/how-one-of-my-tweets-landed-close-io-a-585month-customer/#commentsTue, 09 Dec 2014 16:52:18 +0000http://philfreo.com/blog/?p=617One of my tweets is featured in an article on Mention.com:

]]>http://philfreo.com/blog/how-one-of-my-tweets-landed-close-io-a-585month-customer/feed/0Launched: ArticleListen.com – integration between Pocket & Umano to hear your saved articles read aloudhttp://philfreo.com/blog/articlelisten-pocket-umano-integration/
http://philfreo.com/blog/articlelisten-pocket-umano-integration/#commentsSat, 11 Oct 2014 22:37:07 +0000http://philfreo.com/blog/?p=607I 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.

Using Pocket can be good for productivity because you may see a headline that interests you, but you really shouldn’t be reading it now. By saving it to Pocket you know you can easily find and read it later. I’ve got a few hundred articles saved from over the past couple years. I often read a few articles at a time, but they still build up.

I also use Umano, which is a service that has professional voice actors record narrated articles from across the web. It’s perfect for commuting. Many of the articles are only a few minutes long, so even a quick trip to the store or walking to the train can be enough to hear an article or two about something that interests you. Tech, current news, etc.

Umano has some article discovery built in (a “popular” page and a way to see which articles your Facebook friends on Umano liked), however they have thousands of articles already recorded and so finding what you really want to listen to is still difficult.

Then I realized that all the articles I wanted to read or listen to were already saved in my Pocket queue, so during part of a couple weekends I put together this site to do a few things:

Look through my Pocket queue and identify which articles were already on Unman

Allow me to very easily add matching articles to my “playlist” in Umano

Also allow me to “Vote” in Umano for the articles that are already in my queue

Add “tags” into Pocket for articles that were added to my Umano playlist, so I can easily archive those in Pocket

Umano does have a Chrome extension (and generic bookmarklet) for “voting” for articles, but I wanted my primary queue to be something like Pocket, which is better built for general purpose article saving, I didn’t want to have to save every article to two places, and I mostly wanted to listen to the articles that were already in my queue.

Future improvements I’d like to make: It should continually monitor a Pocket queue for new articles ongoing – looking for matches and adding them to Umano without any user interaction. At the moment you just have to login to the site occasionally.

]]>http://philfreo.com/blog/articlelisten-pocket-umano-integration/feed/2The Elements of User Onboardinghttp://philfreo.com/blog/the-elements-of-user-onboarding/
http://philfreo.com/blog/the-elements-of-user-onboarding/#commentsMon, 04 Aug 2014 00:58:22 +0000http://philfreo.com/blog/?p=592I 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!

Ch 1Onboarding starts way back with your marketing / how users hear about you and needs to be consistent throughout their entire experience.

Ch 2-3Show people how you will make them better

Ch 4Help people see specific details of how your app would improve their life (“aha moment”)

Ch 5
Cater to their emotions – show you understand the struggle of their current methods (use the exact wording of a similar audience expressing their pain points) + help them emotionally connect with your superior way.

Ch 6Your app has a personality. What is it?

Ch 7Give them logic to help defend emotional connection. Focus on how your product is as good as competitors + exceeds all other options. Also pitch customer service, resources, tech support, humans, add trust via testimonials (face/name/title/logo), and numerical social proof. state that you serve “stars” and “aspirational stars”.

Ch 9Design an experience that’s attainable in their first usage that gives that some joy / quick win / at least a glimpse to help them believe your product will be able to help them

Ch 10
Cut down the first run experiences to the fewest ones strictly necessary for helping them achieve a goal

Ch 11First page after signup matters. Don’t keep users in a limbo state too long

Ch 12Imagine you were in-person standing behind a new user helping them become successful with your app. Design your onboarding to be like this. Adding more UI to explain your UI is not onboarding. Make your UI better rather than adding explanations. Rather than fake sample content, use that default content to explain your app / give them a walkthrough, if possible.

Ch 13Give users steps to complete in a way that motivates them to accomplish them. Show that progress has already been made even from the beginning. Make them happy by congratulating/rewarding upon first difficult or important action accomplished (Close.io: we should congratulate them when they close a deal or get their leads imported).

Quora has a nice “quest” that stays open as they browse around, giving them things to do on their own rather than forcing them through a mandatory guide

Ch 14Send an email “congrats – your making progress!” after they do something good, that serves as a catalyst for next action.

Interview: Phil Freo, Engineering Lead @Close.io

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.

]]>http://philfreo.com/blog/my-interview-on-sales4startups-about-close-io/feed/0Coinbase Bug Bounty Awardhttp://philfreo.com/blog/coinbase-bug-bounty-award/
http://philfreo.com/blog/coinbase-bug-bounty-award/#commentsSun, 16 Mar 2014 01:47:59 +0000http://philfreo.com/blog/?p=577Coinbase 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 had recently heard about Burp and wanted to play around with it. When I had some spare time around Thanksgiving, I fired it up and started poking at all the forms in the various Coinbase settings pages, trying to find an XSS or other security issue. I pretty quickly managed to generate a few 500 errors, but that wouldn’t be enough. But within a couple hours I found what I considered to be a real XSS issue. It wasn’t a huge issue, and not something a large number of users would have been affected by, but could result in an XSS nevertheless.

It took a while for them to get back to me, but eventually they agreed it was an XSS and granted me the $1000 worth of BTC and added me to their Awards section!