How a roadside rest stop inspired an entirely different approach to FAQs

Introducing the YesAQ

Years ago I was driving back to Chicago from Wisconsin. On the Illinois side there are a couple of rest stops over the tollway. It’s a great place to get some gas, grab some caffeine, and stretch your legs a little before the final 50 miles home.

The rest stop usually has a booth where you can buy a iPass so you don’t need to stop and pay tolls all the time. During the day there’s a person in the booth to help answer any questions you have.

It appears that a lot of the same questions are asked over and over. Enough, in fact, that the person who answers them is sick of giving the same answer. That answer is “Yes”.

So they jumped on a computer somewhere and put together what I can only describe as one of the smartest formats for an FAQ I’ve ever seen. A single answer on top, and all the questions below. The answer is always YES!! YES, YES. YES!! Then they taped it to the outside of the booth. You can’t miss it.


I thought this was brilliant. I just love it. Yeah, it’s full of passive aggression and spelling errors and formatting problems, but the idea in itself is so refreshing. It’s folk information art.

Inspired by this, we whipped up our own version of a YES! page for Basecamp 3. It was a fun exercise in messaging and design. We call it the YesAQ.


Check it out.


http://basecamp.com/svn

Then just say it like that!


Over the last 20 years I’ve been part of too many discussions where someone goes “I’m having a hard time explaining this or that…” Then they say “I just really want to say this…” And then they say it and it’s clear, concise, and obvious! They nailed it, but…

…it’s as if they aren’t even listening to themselves because they’re right back to thinking about how to say what they just said. Only now they’re back to trying to make it more complicated than it needs to be. They should just say it like they said it a minute ago.

This happens to me often as well. It just happened this morning! I was working on some copy for a new home page design and I just wasn’t locking into my point in writing… So I said a few things out loud. They were better than anything I’d written, but then when I wrote them down I tried doctoring them up a bit because “marketing” and, once again, they fell flat.

We’re all told to be good listeners when someone else is talking, but we should work on being better listeners when we’re talking. We might find that we’ve already got the answers.

Basecamp is looking for interns for summer 2017

Basecamp is looking for talented interns to join our team this summer. We’re excited to work with you, and the things you work on will impact millions of users at the world’s leading online project management tool.

The deadline for applying for a summer internship at Basecamp is February 10, 2017.


About the Basecamp summer internship program

Interns at Basecamp don’t fetch coffee. They don’t file papers or book meeting rooms. They work on real projects that have a real impact on our company, our products, and our customers. You’ll leave Basecamp with new technical, creative, and business skills and having accomplished something significant.

As an intern, you’ll work with a mentor in the company. That person will be your go-to for questions and guidance about your project, about Basecamp, and about the industry in general. You’ll participate in our Campfire rooms with the entire company. You’ll say “good morning” in All Talk, discuss ideas in Building Basecamp, and post pet pics in All Pets.

Internships at Basecamp are remote — you can work from anywhere you want, provided there’s some overlap in time zones with your assigned mentor. We’ll fly you to the Chicago office once during the summer to get together with your mentor and the rest of the intern class, and you’ll talk regularly with your mentor via phone, Skype, or Google Hangouts.

All internships are paid and require a commitment of 8–12 weeks of full time work between May and August 2017 (we’re flexible on start/end dates, planned vacations, etc.).

You can read about the experiences of some of last year’s interns for inspiration!

About you

We’re hiring interns across the company — we have openings in programming, product design, operations, support, and data. Regardless of role, there are a few key things we’re looking for in interns:

  • You are independent and self-driven. Basecamp is built on the concept of being a team of “managers of one”, and that applies to interns as well. You’ll get plenty of support and guidance from your mentor and the rest of the team, but no one will be telling you how to spend each minute of your day, so it’ll be up to you to make sure you’re making forward progress.
  • You are an excellent communicator. We write a lot at Basecamp — we write for our products, we write for our marketing sites and initiatives, we write to our customers, and most importantly, we write as our primary way of communicating internally (using Basecamp, of course). Clear and effective communication is essential to being successful at Basecamp.
  • You have fresh ideas and you’re willing to share them. We don’t know it all, and we actively want to hear fresh ideas and perspectives that we haven’t considered.
  • You’re eager to learn. You’ll dive right in to new technologies, new approaches, and new concepts and apply them to your work.
  • You’re not a computer science or design student? That’s not a problem. Past interns have been philosophy majors, poets, improv comic performers, and gelato makers, as well as computer science and design students. We’re not sticklers for traditional education.

How to apply

We’ve deliberately kept the application simple so you can tell us about yourself the way you want to. We want to know why you want to be an intern at Basecamp, what you’re interested in working on, what work you’ve done in the past, and why we should hire you. Give us the URL to your portfolio, blog, GitHub site, etc. Add a resume if you want, but remember, we’re always impressed by a great cover letter.

Oh, and while we love Basecamp, inviting us to a Basecamp project isn’t a great way to apply for a spot here. So please don’t do that.

You can fill out your application here. We’ll accept applications through Friday, February 10th. You’ll get an email to confirm your application shortly after you apply.

The projects

You’ll be working on a real project that matters to the company and the team that you’re working with, and you’ll be expected to own and contribute to the project. You’ll have the opportunity to shape the project with your mentor to meet the needs of the company and the things you’re interested in working on. We’re looking for interns on the following teams:

Data: We’re looking for someone who loves data. Someone who gets a CSV file of new data and can’t wait to dig in and start exploring. Someone who is excited to write great SQL queries and discover new R packages. We believe that data science is mostly about basic arithmetic, business judgement, and problem solving, so we value foundational skills more than machine learning experience.

You’ll spend your summer conducting independent analyses to answer important questions we have. Recent questions you might have answered have been about customer demographics, usage of Basecamp on mobile phones, conversion rates over time, or A/B test results. You’ll identify the data you need to answer the question, perform analysis, create visualizations, and write up a compelling story. You’ll also participate in peer review of other analyses, weigh in on other team data projects, and contribute to our daily chart habit.

iOS: Have you created an app that runs on your phone? We’re looking for a programmer who displays ingenuity and the skill to create software for iOS that considers the user as well as the code. If you have a product in the App Store, we’d love to see it! We’re also impressed with projects built for personal curiosity or coursework. We’re more interested in seeing that you have the aptitude to make something real than seeing what classes you’ve taken.

Examples of the kind of work you’d be doing include: Create a media viewer with gesture based controls and the ability to browse uploads of different types; Provide a way to quickly add To-do items from the home screen or a Today widget; Examine analytics data and use it to inform improvements that can be made in the app; Create a presentation mode that shows an alternate view over AirPlay for in-person meetings.

Ops: We’re less concerned with how much ops-specific knowledge you have and more interested in your ability to problem-solve and adapt, and most critically, learn. Familiarity with the command line and bash/zsh/git etc is a big plus, as is an interest in the Ops arena of problems and how systems are put together.

We’re in the middle of a huge transition from on-premises to cloud-based infrastructure, and we’ve always got something that we are interested in exploring, whether that’s alternate container runtimes, better blue/green deploy methods, better access-control and authen/authz systems (LDAP?), smaller, more efficient container strategies, or better local development methodologies.

Product design: Projects at Basecamp always start with design first, so you’ll have a unique opportunity to learn how we turn nascent ideas into real, working software that’s used by hundreds of thousands of people. We value experimentation, good writing, rapid iteration, and getting real. Our designers are a talented bunch — they’re responsible for everything from concepts to copywriting, prototypes, visual design, and production-quality code.

We’ll work on a handful of projects intended to give you a wide range of experience with our design process at Basecamp, including exploring a new idea from scratch, learning how to manage and scope work, and building a product feature all the way to production.

This position will involve working with web technologies. We’d like you to have some previous experience with visual design, and any experience with HTML, CSS, and JavaScript would be helpful too. (We’ll also be working in Rails but we don’t expect you to know it.) Beyond specific skills, we’d like you to bring fresh ideas and a new perspective to the team. If you’ve done weird side projects, drawn comics, written a blog, made an app, knitted a scarf, or invented anything else under the sun, tell us about it! We’d like to see examples of your curiosity and how you approach solving problems.

Programming: We’re looking for a generalist with experience working in full-stack development. Our environment is Ruby, Rails, and JavaScript, so you should be familiar with the ‘rails way’ of doing things. We’d love to hear from folks with experience in similar environments like Python or Django as well. You should have experience working on a real app. That could be something for a college class, a bootcamp project, a contribution to an open source project, etc.

Past intern projects have included the implementation of a strong password check across all apps, adding endpoints to the Basecamp API, and helping launch an update to the Basecamp files section.

Support: We’d like to see an intern who can help out in our social media sphere. We’ve tried to get more active on Instagram, we answer questions through Twitter, and we answer a small amount of questions from users on Facebook. How can we get better at those social media channels, and are there other social media channels we’re missing out on?

Tell us about a great social media experience you were part of. What was your role in it? What was the goal, and what was the outcome? Can you give us an example of a company that uses social media exceptionally well? What makes it so great? If you’ve worked with customers anywhere (doesn’t have to be in tech — could be in fast food or retail), we’d love to hear about it. Tell us about your experience working with people who had problems that you helped solve.

Behind the scenes: A/B testing at Highrise

Highrise launched in 2007 and was a leader in teaching folks about some successful marketing split tests. Today we’ve got a few new lessons. First let’s talk a bit about strategy, and then I’ll share a couple important results we’ve seen.

When to stop

Here at Highrise, we split test constantly. Since these can take quite a lot of time to reach statistical significance, and I want to keep using our time efficiently, it’s important to have another test ready in the queue as soon as one completes. Even if it’s changing a word on a single button.

But it’s super easy to get stuck. We run dozens and dozens of experiments and often end up with nothing. No changes. Or the new stuff just makes things worse.

So when do you stop? It’s helpful to come up with some baselines. We look at other products out there, our past, and our sister product Basecamp. How are we doing compared to those baselines? In some cases we’re behind, so those are ripe areas for testing. Other areas we’re on the baseline, and have decided our time is better spent elsewhere.

Don’t get lazy

Here’s a lesson that came to us at great cost: we weren’t measuring enough variables. When I took over Highrise in 2014, we immediately started split testing an entire new marketing site design. We compared the old and new site’s signups. Waited until we had a statistically significant result. And bingo. Saw the new site was doing better, and switched all our traffic over to it.

We were befuddled then when we saw our growth plateau. What were we doing wrong? We’ve been improving the product at a super fast pace. People seem really happy.

Turned out we were measuring the wrong thing. We were split testing total signups which include free and paid.

When we dove in, we saw our new marketing site had actually hurt our paid conversions but improved our free conversions masking the overall impact. And those free conversions weren’t upgrading at a high enough rate to make up for it.

But that’s not the whole story either. People who were still signing up for our paid plans, were now more often signing up for the cheaper plan instead of what was our most popular plan — a more expensive one. Totally changing our revenue mix.

The lesson: measure more detail than you think you need to. Put the extra work into splitting up the different variables that are important to you in your split test regime.

It could also be worth paying for a data scientist to come in and make sure you’re doing the right thing. I’ve been split testing marketing sites for many years, but it took Noah Lorang at Basecamp to open my eyes that we were doing something pretty stupid. And it didn’t take him long either. This doesn’t have to be an elaborate project. Just make sure you you’re testing the right things. Don’t get lazy. Or you could pay an expensive price like we did.

Some interesting results

Too many plans

One change we made when we relaunched our marketing site was to our plans page. We went from this:


to this:


I wasn’t in love with the change, but I didn’t hate it either. It brought our new, more minimal, aesthetic to the plans, and it also addressed one thing we heard from some customers: “Do you have a bigger plan?”

We did! We just didn’t advertise it. So let’s add that. Can’t hurt?

Well it did hurt (like I mentioned above — we just didn’t see it soon enough). Paid signups went down and people started signing up more for the Basic plan.

When we moved back to something more akin to the old design:


Paid signups went back up 51.4%. And our new revenue improved 67.6%!!

Quite the mistake and improvement. Why the difference? Probably easy to guess that more plans doesn’t mean better. Too many choices. The extra choice probably just made for too much anxiety and killed people’s desire to sign up. And the original design, really made things a no-brainer: “Here, don’t debate, just sign up for this.”

The free link also became bigger in our changes that weren’t working well, encouraging folks to bail into that plan. So we bumped the font size back down to what it was originally.

Revisit old hypotheses and assumptions

Another interesting result we just bumped into was an explainer video we had on our features page.


I remember when we added that over a year ago; we split tested it of course. Though again, a mistake we made, we only split tested total conversions.

Recently we decided maybe the explainer video wasn’t up to date enough (Highrise is improving at a very fast clip), but before removing it, we tested three things: removing it, leaving it at the bottom of the page where it was, or moving it to the top.

Removing it improved our free signups by 53.2%! And didn’t change our paid signups at all.

Why would getting rid of a video sitting at the bottom of a page that doesn’t get a ton of our traffic make that much of a difference?

It’s also an important reminder that not all customers behave the same way on the site. Maybe folks who are more anxious about signing up spend more time pouring over the details of our features and how we present them. Then they bail into a free plan. What can we do to take advantage of that information? Maybe offer the free signup at the bottom of the features page? Improve our call to action on that page stressing free trials? Lots of options when you get more granular about what you’re testing.

It’s also worth rethinking a lot of assumptions and hypotheses that we thought we knew a couple years ago. Not just because our testing is more thorough. But also because maybe these things have changed since then. Maybe an image or a video or some copy that converted well just doesn’t have the same impact today. Maybe the consistency of those images with other assets have changed (logos and styles in screenshots). Maybe, simply tastes have changed since we tested those.


Just a couple recent lessons from us. Stay tuned for a lot more. There’s some really interesting changes we’ve been testing and haven’t gotten quite right yet, but have angles on improving…

P.S. You should follow my YouTube channel, where I share more behind the scenes of Highrise and how history, psychology, and science help us run our own business. And if you find yourself overwhelmed while managing your customer relationships, customer support, or the tons of people you communicate with, check out how Highrise can help!


It’s OK not to use tools

Recently I did a little side project to improve the website for a non-profit animal shelter in our town. The existing site was an outdated Microsoft FrontPage menagerie, so basically anything I did would be a big improvement.

I spent around 20 minutes creating a simple design in HTML, and then several hours editing, rewriting, and refining the copy. In the end, I reduced a scattershot 25-page website down to about 8 focused pages written in a friendly tone.

My next instinct was to apply our great modern web toolset to the site. Let’s add a static site generator or a CMS! Let’s add Sass and a grid system! Let’s do more fashionable things!

Then I started looking at those tools critically. A static site generator usually requires knowing Markdown and esoteric commands and configuration. A typical CMS will need setup, logins, security patches, templates, and maintenance. Even hosted CMSes have a lot of cognitive overhead, and the content is trapped away inside someone else’s system.

These are tools made by geeks, for geeks. Why do we need a CMS for an 8-page site? And for that matter, why even bother with Sass? Regular old CSS can do the job just fine.

Who knows who will take over the site in the future. I’ll hang with it for a while, but someday someone else might have to work on it. It would surely be easier to do that with 8 simple, straightforward HTML files than with some custom WordPress installation that’s several versions out of date. So what if I have to repeat the navigation markup 8 separate times? It’s not that hard. We used to do it for much larger sites!

Today, a basic HTML/CSS site seems almost passé. But why? Is it because our new tools are so significantly better, or because we’ve gone overboard complicating simple things?

As builders, we like tools and tech because they’re interesting and new, and we enjoy mastering them. But when you think about the people we’re building for, the reality is usually the opposite. They need simple designs, clear writing, less tech, and fewer abstractions. They want to get stray animals adopted, not fuss around with website stuff.

Remember when the web was damn simple? It still can be. It’s up to us to make it that way.