Teaching iteration

I’ve written about the class I’d like to teach, but what I’ve been thinking about lately is the class I’d like to attend. Not necessarily now, but when I was growing up. In the 6th grade, let’s say.

I don’t know why people ask me this, but I’m often polled for my opinion on the American education system. What’s my take? What would I do to fix it?

I don’t know, really. “It” covers too much ground to be addressed accurately. Education is delivered at every scale, from an individual reading a book, to a 1:1 tutor, to a small home/classroom setting, to a larger university auditorium-sized class, to online classes that can be theoretically taken by the entire planet at once. From one to 7 billion.

You can’t fix anything that’s so big and so varied. You can, however, fix small parts of things. And hopefully, as the small, fixed parts add up, you have a chance at chipping away at a big problem.

So here’s my one small idea: I’d begin to teach iteration. Iteration as a subject, equivalient to math, science, history, language, art, music, etc. How do you make something better over time? How do you return to something that you’ve done and see it with fresh eyes? How do you apply new perspective to an old problem? Where do you find that new perspective? What trails do you follow and which do you ignore? How do you smash the familiar and reassemble something new from the same pieces?

Once you’re done with school, and cast out into the world, your job is likely to involve iteration. No matter what you’re doing, you’re probably going to have to do something over. And often times again and again. You rarely simply deliver something and move on. You’re asked to refactor, to build on it, to “make it better”.

Making anything better is iteration. When you put something out there, it’ll often land right back in your lap. Sometimes that feedback boomerangs back directly, other times you have to infer the problems by disciphering other people’s behavior when they interact with the thing you gave them. This customer struggled with this, this manufacturing tolerance didn’t line up with that, this printing process looked better on the screen than it did on paper. Or after a certain amount of time passes while working on something, you reflect on what you’ve done and don’t like the reflection.

Either way, someone’s probably going to ask you to take the state of your art, and make it the state of the art.

Now that you’ve got it back, what do you do with it? This is something you have to learn how to deal with. But in school — save for writing a few drafts before handing in the final version — you don’t get to iterate much. You move on from assignment to assignment, rarely getting a chance to revisit your work earlier in the semester. I think that’s a missed opportunity.

So, perhaps for a final assignment (no matter the subject), students should be able to choose something they did earlier in the year and get a chance to improve on it. Make version 2. I think working on four things, and getting a chance to redo one of them would be more valuable than working on five separate things. It would be a better education.

Or another take would be a single assignment for the entire semester. Every two weeks you hand in a new version of it. In time you may slam into diminishing returns, but that’s all part of it too. That would be a better education.

Or maybe you work on something and hand it in. Then the teacher shuffles the deck, so to speak, and hands you back someone else’s assignment. Now you have two weeks to improve on that. And that cycle — improving on someone else’s work — continues for the whole semester. That would closely mirror what work on the outside is really like. That would be a better education.

I don’t know, something like that.

So there, I guess that’s my initial idea to improve the educational system. Teach problem solving through iteration. Bounce things back to people for a second or third try. And then a fourth and a fifth. And so on. Require them to bring new perspectives. Demonstrate how time, space, and chance are on your side — they give you the opportunity to wander around with an idea and take it in new directions. Iteration is evolution. Hopefully what’s next is better than what came before it.

If you’re reading this, you probably don’t do hard work

Actual hard work

Designers, programmers, tech entrepreneurs, and investors love talking about how hard their work is.

Let’s get real.

Hard work is picking lettuce 8 hours a day in 90 degree heat.

Hard work is being a single mother or father who has to work two minimum wage jobs back to back with nary a recuperative break all day.

Hard work is heaving dirt and rock on a construction site. Or working with industrial equipment that could crush you if you make the wrong move.

Rule of thumb: If it’s hard you’ll have trouble finding people who want to do it. There’s no shortage of people who want to be programmers, designers, strategists, social media consultants, entrepreneurs, investors, etc… But try finding people to work the farm. Hard work is doing the work other people don’t want to do.

Coding, or designing, or writing pitch decks, or making sales calls, or preparing spreadsheets, or writing blog posts, or social media marketing, or buying ads, or choosing the right color, or picking the right paper, or making a layout responsive, or investing in companies, or doing due diligence, or making decisions, or coming up with a strategy, or allocating capital, or figuring out how to spend the budget, or reading up on a subject is not hard work. That’s just work. If you can do it in an air conditioned room, with no physical threat to you or someone else, while seated, it ain’t hard work.

It may be challenging work. It may be creative work. It may be skilled work. It may require multiple tries to get it right. You may have to learn new things. You may be rejected a bunch. You may get hung up on. You may not know how to get from A to B. You may have to persuade. You may have to deal with people you don’t like. You may have to sell something someone doesn’t know they want. You may have to be creative. You may have to build something that hasn’t been built before. You may have to battle entrenched interests. You may have to put in a few days or weeks in a row to figure something out you’re stuck on. You may have to make tradeoffs. But that’s the work. Not achieving the outcome you wanted doesn’t make it hard, it means you have more work to do.

If you enjoy it most of the time, it’s probably not hard.

Solving a problem doesn’t mean you worked hard. It means you decided to put in the work to solve the problem. Maybe you thought about it differently. Maybe you came at it from an angle no one else did. Maybe you just decided to take something on other people couldn’t see. None of those things make it hard.

And maybe you’re really good at something, while other people are very very bad at it. But that doesn’t make it hard either.

Long hours don’t equal hard work. They just equal long hours. The time you put in has nothing to do with how hard something is.

Brainstorming isn’t hard work. Riffing isn’t hard work. Networking isn’t hard work. Going to conferences isn’t hard work. Dodging traffic isn’t hard work — it’s commuting. It may be shitty, but it isn’t hard.

And please, giving your opinion isn’t hard work. Bouncing from meeting to meeting giving advice isn’t hard work.

I get why people love calling their work hard. It feels good. It feels important. It makes you feel like you’re doing something that some other people would choose not to do. I absolutely get that.

But none of that makes it hard.

We all have work to do. Do good work. Do creative work. Do thoughtful work. Do your best. But there’s no need to flatter yourself about how hard it was.

Jobs to be done — Getting started


If you don’t know me, Hi. I’m Nate. I took over as CEO of Highrise as we spun it off from Basecamp in 2014. It’s been an exciting project, but holy crap is it hard.

Highrise is a simple CRM you can get your whole team on in a few minutes and it’s been around since 2007. When it came out, it was a “blue ocean” for us (the water wasn’t red from a bloody war with competition). You had the behemoth of Salesforce, which is a fine system for people ready to spend their careers learning how to wield it. Or you had desktop tools and spreadsheets that were tough to share with your team. Highrise was one of the first to bring CRM online and make it dead simple.

But… 10 years have passed. The marketplace is quite different.

Now, when people search to use a CRM for their project or organization they often come across lists of dozens and dozens and dozens of competitors to Highrise. We rank favorably on many of them, but still. We’ll be amongst 50 competitors on a list. It makes business much harder.

So one thing we seek is how to make Highrise stand out again like it did in 2007.


In 2004, a guy named Manoj was inspired by an energy drink he discovered at a trade show. Something struck him though about the 16 oz beverage he sampled. He wasn’t thirsty. He just wanted a pick-me-up. So why was this a 16 oz. drink?

Clayton Christensen made the phrase “jobs to be done” famous in business circles with his book Innovator’s Solution. In a nutshell, if you want to innovate, you really need to get to the actual job your customers have for your product, which is something few companies bother to find out.

In the book, he talks about “milkshakes” and how a fast food company had surprisingly found milkshakes were being hired for the job of: breakfast. When you understand that deep rooted need, you can make some truly innovative decisions about your milkshakes.

Manoj realized that energy drinks were often hired to bring people energy, not to quench thirst. Getting clear on the true job to be done of his potential customers, allowed him to see a way through a crowded market.

He turned a 16 oz. energy drink into a 2 oz energy shot.

Instead of sitting in the refrigerator section with countless Coke and Pepsi brands and dozens of Red Bull variations. He could sell his energy shot right on the counter when people check out. In 2005, Manoj launched 5 Hour Energy shots, which today now makes over $700 million in revenue each year.


I’d like to get out of the refrigerator section.

So we recently finished a series of “jobs to be done” interviews with our customers looking for our own aha moment. Are we serving Highrise customers 16 oz. beverages when they need 2 oz. shots? Is there a counter where we should be selling Highrise that today’s competition is ignoring?

We had the good fortune of having Ryan Singer at Basecamp run the interview process for us. He’s been learning Jobs to Be Done theory directly from Clayton, Bob Moesta, and Chris Spieck. Bob was one of the original architects of Jobs to Be Done theory with Clayton. Bob and Chris run The Rewired Group, which helps companies complete the interviews and find their ‘jobs’.

Ryan has also run a series of successful interviews for Basecamp, and was available to help us.

Though I’m no expert, there are quite a few tips I can share about our process that might help you.

Tip #1: Wait

“Ok, so I should email a bunch of people now?” was my very first question I asked Ryan when we met to plan our interview project.

No, I shouldn’t just jump into scheduling a bunch of customers. We needed to get clear on what our goal was and how would we screen great interview candidates.

For example, if our goal was to find out why so many people were quitting Highrise, then we would probably want to interview a bunch of recent quitters and figure out the timeline of events that led them to Highrise to begin with, and then the events that led them away.

Fortunately for us, quitting Highrise isn’t our problem. Once people are in, they’re super happy (something that was made surprisingly clear in our interviews and something I’ll cover in more detail soon).

Our problem is getting people to discover us in the first place now that there are so many other choices to pick from.

So we got clear on who we wanted to interview, as well as where we wanted to spend the most time of the interview: the discovery process. The pain and the search that led to us to begin with.

Tip #2: Don’t interview everyone

One of the most important parts of successful jobs to be done interviews is to screen out the wrong people.

You need to make sure you are only interviewing recent customers who just bought your product. They’ve actually given you a credit card and paid you. It’s not still in some “trial”. The purchase is done.

But you don’t want to go too far back or the people you’re interviewing won’t remember enough detail about the problem they were solving in the first place.

Avoid interviewing people who are your repeat customers. These memories of how they discovered you and what the original pain was needs to be fresh.

We used a combination of our analytics tools and a screening survey we sent to a bunch of potential interview candidates. We worked hard to keep the survey as slim as possible, because our goal was still to have a good response rate.

One question I wish we had but didn’t was some kind of date picker of: “When did you first use Highrise?” We had one interview where the user had been using Highrise for 6 years and had just created a new account. Great customer! Wonderful person to speak with and had great feedback. But didn’t help us with the type of insight we were looking for since they couldn’t remember the original problem that brought them to Highrise so many years ago.

You also need to screen for the actual purchaser and decision maker. If someone ended up making the purchase because a boss told them to go out and do it, that’s not going to be helpful enough either or you risk your interviewee saying this throughout your interview: “I’m not sure, I’d have to ask Kathy because she’d told me we needed it.”

Tip #3: You won’t be good at doing this

For the first 3 interviews I did myself, I’d grade them a D+. At least I made an effort 🙂

The interviews themselves, were much harder to conduct than I had anticipated. And that’s just the data gathering phase. The analysis phase is another mountain to climb.

My interviews were way too short, and skipped too quickly through the parts of the customer journey that actually makes a difference to us.

The real lesson is that you need practice. After now being “second” chair to Ryan leading these interviews I’m confident I’ve gotten better.

But I still remain no expert. Reading my words isn’t going to get you to the point of truly understanding how to conduct this research. I’ve been studying jobs to be done for years now, listening to sample interviews, taking courses. And I still struggle doing these interviews.

I recommend you devour the material that Bob and Chris produce on the subject: http://jobstobedone.org. They even have an online class I’ve taken, and do workshops. I’ll even try and attend their next workshop myself. And follow Ryan’s insight on this topic.


I’ll be sharing dozens of more tips I saw as we conducted these interviews in follow up articles. But if you want the spoilers you can see the Jobs to Be Done videos on my YouTube Channel: here.

And if you need a simple system to track leads and follow-ups you should give Highrise a look.


It’s OK to be pragmatic (with a little help from the “crazy ones”)


Being pragmatic is engrained in me. I’m at my best being practical and boring.

Here’s the problem — experience has taught me that you’ll never do your best work through sheer pragmatism alone.

While I’m good at weighing options and making decisions, I’m not that visionary who can conceptualize grand ideas.

While planning comes very naturally to me, I find it difficult to inspire others.

And though I’m good at shipping, I often do so using following established conventions.

So while the incremental, risk-averse nature of being pragmatic can be good for many aspects day to day of work, it’s not everything.

What you’re good at and what’s good for you aren’t always the same thing.

To make long-term, deep progress in your professional growth, you need to think big sometimes.

You need to try things that don’t have predictable outcomes. You need ideas and ways of thinking that inspire innovation. You need to stretch way beyond your comfort zone.

But as a pragmatist, how can you do all this when it’s so foreign to you?


Surround yourself with the “crazy ones”

The idea of the “crazy ones” may be Apple’s, but that kind of creativity, inspiration and genius is all around you.

Look for opportunities to work with people who are the opposite of you — the dreamers, big thinkers, and contrarians.

These will be the people who will push you toward bigger and better things.

Yes, it’s going to be very hard and uncomfortable for you. You’re going to feel like you’re on a bizarro planet where everything is backwards and nobody thinks like you.

This is a good thing.

Having people challenge your baby-steps thinking with big-leaps thinking is a good thing.

Not understanding what the hell one of your colleagues is thinking (at first) is a good thing.

Having healthy discourse around big ideas is a good thing.

And shaking hands and finding compromise is a great thing.

Their thinking will seem crazy and executing their ideas will seem impossible. But in end you’ll pull it off — not in spite of you, but because of you.

You’ll be better in every way because you stretched well outside your comfort zone. And really, what’s more rewarding for a pragmatist than shipping something you didn’t think was possible? 🤘


If you liked this article, I’d sure appreciate if you clicked the 💚 button below. Thanks!

I was lucky enough to work with some of the crazy ones on Basecamp 3— especially Jamie Dihiansan, the designer of the Basecamp 3 Android app. Check out what happens when you get a happy mix of pragmatism and crazy!

The most helpful thing you can say to a teammate: “It’s your call”

Great people blossom when you nurture them with trust and respect

When a teammate asks me a question, one of my favorite responses is “It’s your call.” It’s such a simple yet powerful phrase. In just a few words it conveys…

Trust | Confidence | Respect | Autonomy | Ownership | Empowerment | Responsibility | Decisiveness

How can such a simple phrase mean so much? Take this common scenario — a team discussing what to work on next. Here’s one version of that conversation:

Julie: What should I work on next?
Shelley: How about a native homescreen?
Melissa: I’ve always wanted breadcrumb navigation!
Sara: Another option would be to squash some 🐛
Erica: File upload feature would be cool

Now there’s absolutely nothing wrong with a back and forth like this. Julie has opened the door for feedback, and the feedback provided makes total sense.

But imagine the same opening line with a single response:

Julie: What should I work on next?
Shelley: It’s your call 😀

Immediately the whole tone of the conversation has changed for the better.

Instead of asking for permission and being given specific directions, Julie has been empowered to make the decision herself.

She now has complete ownership. She’s free to explore and make her own choices. She’ll assess all the open tasks. She’ll drum up her own new ideas. She’ll decide what’s next based on her own criteria of importance.

More importantly the team has expressed sincere trust, confidence, and respect in her and her abilities to do everything. They’ve said “whatever you decide is cool with us.”

Full autonomy like this has significant long-term benefits to teams —no managers, increased motivation, time saved, sharper assessments, faster decisions, happier people, improved independent learning, better teamwork and so much more.

All of that accomplished by just saying a simple phrase.

When it comes to software development, conversational opportunities like this come up pretty frequently. Keep an eye out for questions about:

  • What to work on next
  • How to implement a feature
  • What tools, APIs, or libraries to use
  • How to manage/keep track of work

Of course when you’re asked for your opinion, you can certainly give it — you don’t want to leave people completely hanging.

But before you do that, consider challenging the person asking the question by simply saying “It’s your call.” You’ll be pleasantly surprised by the outcome, and the long-term benefits are well worth it. 🤘


Great things can happen when you emphasize these values — Basecamp 3 and its Android app are the result of a handful of autonomous teams working in an independent, yet highly coordinated environment.

If you found this article helpful, please do hit the heart button below and let me know on Twitter. Thank you!

If we had a Roadmap . . .


Some examples of emails we get about our product roadmap at Highrise:

Hope something like this is on the product roadmap.

Is such development planned in your roadmap soon?

I’m following up to see if we can add this to the product roadmap.

You want the truth?

Here it goes. Highrise doesn’t have a roadmap.

Our team doesn’t have a list of features with exact dates for release. We don’t know what’s going to be released on Tuesday, August 23.

We can’t advise when something will be possible. We can’t confirm if something is on our roadmap. The product roadmap doesn’t exist.

We don’t make promises.

And really that’s all a roadmap is. A promise.

A product roadmap is a promise that customers will get something on a specific date.


That’s a real photo of a map at the top of this post. It was an Uber ride Jon and I took from a Boulder hotel in an attempt to get to the Denver Airport.

Highrise is a remote company. This means all of us work where we’re comfortable. We have team members in Chicago, Boulder, Minneapolis, and Charlotte. All over the country.

Remote work is refreshing. It puts all the focus on getting work done. Our ancestors (aka Basecamp), wrote a book on it. We believe in remote work.

While remote work is great, every so often you need to meet your team face-to-face. There is no substitute for being able to look a colleague in the eye when you’re explaining something or giving them a hug instead of saying thank you over chat.

Our team met in Boulder in the middle of March for a team retreat. Michael, who resides in Boulder, told us the weather would either be perfect or it would snow a couple feet.

The retreat was delightful. We caught up and got to know one another better. We made progress on ways to improve Highrise and defined our priorities.

The weather was perfect. We went on a hike together and enjoyed the outdoors. Had a lovely team dinner. The trip was going really well.

And then it changed.

Most of us were scheduled to leave on Wednesday, March 23.

I woke up early and looked out the window of the hotel.

Holy shit.

There was about 4 or 5 inches of snow on the ground. And it was still snowing. Hard.

I looked at my phone. Blizzard warning for Denver.

I checked my flights. Still on-time. Allegedly.

The next 8 hours of that day were something I’ll never forget.

Jon and I walked to a coffee shop in downtown Boulder and met another member of our team, Grant, to get some work done.

We were checking our flights every 15 minutes or so. Nathan and Lynette’s flight was already cancelled.

Somehow the flights Jon and I had were still on-time.

We needed to get to the airport. And Jon scheduled a shuttle from the hotel.

It was time to go. The snow hadn’t stopped. It picked up.

As we got to the hotel to grab our bags, Jon got a phone call. It was the shuttle. They cancelled.

We had a choice to make.

Try to take the public bus an hour from Boulder to Denver. Or call an Uber.

We chose an Uber. I pulled up my phone and braced myself for what kind of car the driver was going to be in.

Chevrolet Suburban.

Jon and I looked at each other. That might work.

We got in the Uber. Our driver, Marty, couldn’t have been nicer. He was a mountain man. Prepared.

“Alright, gentlemen. It says it should take about an hour and a half to get to the airport. There’s a few different ways we can go. If we get in trouble, I’ve got some blankets and Heath bars,” Marty said.

Marty’s pitch made us laugh. Blankets and Heath bars? We’re not going to get stranded.

As we started our route, the first highway we attempted to go on was closed. This was 10 minutes in.

Marty tried the next route. Gridlock. Bumper to bumper. The snow wasn’t stopping.

Marty said let’s turn around and try another route.

Jon got a notification on his phone. Flight cancelled.

My flight was still on-time. Marty takes us to the next route. More traffic. We’re going at a snail’s pace.

A little over an hour has passed now. I check the Denver Airport’s Twitter account.

A minute later, my flight is cancelled. No surprise.

Now, we’re in no man’s land between Boulder and Denver. We’re not leaving today and we’re not quite sure where we’re going either.

Marty suggests we try to get to a hotel that’s in the direction of the airport. Jon calls what feels like 20 hotels. Almost all are booked.

Jon lands a reservation for us at a hotel in Thornton, Colorado.

The destination is now a hotel in Thornton.

We stopped moving. Must be an accident ahead. Marty takes us on new route.

We’re coming up on 2 hours in the car. I’m starting to think we might need that blanket and Heath bar.

The new route is a little more open. The Suburban is gaining some speed as we approach a hill.

The car fishtails a little. And we’re stuck.

Marty asks if we can get out to push the car.

You might think team building happens with things like trust falls. Nope.

Try pushing a stranger’s car in driving snow with a co-worker. You’ll get to know each other. Fast.

Jon and I get out and head to the back of the car. It’s a white-out. Snow is falling fast. And it’s wet. The snow on the ground is so packed it feels like cement.

We push the car and nothing really is working. A few folks in passing cars stop and help.

The best advice they give us is the road ahead is closed. Turn around. Instead of pushing the car forward, we can go back now.

Marty maneuvers the Suburban and flips it around. We’re moving now.

We all take a deep breath. Share some four letter words. And agree let’s go back to Boulder if we can.

Marty drops us off back at the same place he picked us up. Almost 3 hours later.


We made it. My goodness.


When Jon and I got in that Uber, our flights were on time and we’re expecting to get to the airport in 90 minutes.

The “roadmap” said we’d be getting home today. That was our expectation.

And that didn’t happen at all. It sucked.

This is why our team doesn’t have a product roadmap.

Our team doesn’t like making promises we can’t keep. We don’t like setting expectations and then letting people down.

If we did have a roadmap, I’d bet it would be full of detours. Much like our Uber ride. It would resemble a child’s first attempt at using an Etch a Sketch.

Lots of twists and turns. Backtracking. Turning around. A little messy.

This isn’t to say we don’t have any clue what we’re working on. That’s far from the truth.

Our team has announced over 70 updates since taking over Highrise. Seventy. New features and improvements are announced almost every week. And that’s just what we choose to announce.

We can’t do that without some planning.

Our team has a general idea of what’s coming in the next month or so. After that, we gather the response of what we released and go from there.

Sometimes this means we continue on with what we had planned. Other times it means we have to turn around. Scrap our plans and work to improve what was released in the last few weeks.

For example, when we released Broadcast, we started to notice a frequent feature request. Broadcast makes it possible to email multiple contacts at once. It replaces the need for an extra tool like MailChimp.

But we found people were having trouble selecting a group of contacts to email. Tags and filters were limiting, and it put pressure on our team to improve it. Fast.

This changed our priorities. We scrapped what was initially planned to improve tag filtering. We added company tags and NOT tags in our next releases.

We changed our focus to help people use Broadcast. And that’s not something we anticipated until people starting using it.

A roadmap wouldn’t have helped us there. It would of been pre-determined what we should be working on next.

Roadmaps are predictions and assumptions.

But you can’t predict the future. Priorities change. Shit happens. And you have to adjust.

Just like Marty did when trying to get us to the Denver Airport. And the hotel in Thornton. And then back to Boulder.


We don’t have a product roadmap.

But if we did, it would have lots of detours.

P.S. Wondering where our next detour is going to take us? Follow @highrise on Twitter, check out our recent announcements, or ask me @cjgallo.

Be the Plumber


A 30-something immigrant with no fancy education or consumer product experience started a company in 2003. The product’s first sales came out of the trunks of cars.

9 years later, the company’s products were being snagged by people checking out at Walmart and sales exceeded $1 billion.

How the hell did that happen?


One of the hardest parts about supporting customers is seeing things from their perspective. There were plenty of customers who knew the product better than me when I first started at Highrise 17 months ago.

That’s not a great feeling. Because people are asking you questions and you’re supposed to have answers.

How do you get to know the product better?

You use it.

In my first 12 months at Highrise, our team tried using the product more and more. We assigned tasks for following up with customers. We tracked email with our dropbox addresses. We built support to autoforward in tons of mail.

We were learning the product, but we really weren’t using it as much as we could. Especially for supporting customers.

The majority of my time was spent in help desk software. That’s where I was replying to customers. It wasn’t spent in Highrise.

One day, our CEO, Nathan, asked me what would it take to use Highrise to support customers?

My first reaction was that wouldn’t even work. There is no support queue. It would be terrible and slow us down a ton.

But Nathan knew if we could pull it off, it would mean our entire team would spend a ton more time in Highrise.

By using Highrise, it would become more useful to us and our customers.


But it wasn’t going to be all ice cream and nuts. It was going to be tricky. Rough spots were ahead.

Our team started small. One of the first things we announced was autoforwarding support for Gmail.

All email was being autoforwarded into Highrise. It was a firehose of information. Overwhelming. Noisy.

It became impossible to search and find information. It sucked.

But if our own team was having trouble with it, customers probably felt the same way.

This shitty experience put pressure on us to make it better.

A little later our team built a way to connect Gmail and send emails directly out of Highrise. Our support email address used Google Apps, so we were inching closer to being able to support customers with Highrise alone.

The first version to send email out of Highrise was a bit underwhelming. You couldn’t attach files. No way to CC or BCC others.

It was good enough for us to start using it, but there was still too much friction.

Weeks later we introduced rules including a way to only forward in email from existing contacts. This reduced the noise and made it easier for us to use Highrise. The firehose was no longer always on.

It was still hard to find notes and emails when searching. Tons more email was still in our account. So we improved search and made it easier and faster to find things.

When replying to customers, we sometimes needed to copy others or attach files when replying to customers. So our team made it possible to CC/BCC from Highrise and followed that up with attachment support.

More progress. But still more pressure too. No queue for emails. We had no idea what needed to be replied to or what was outstanding or important.

Next, we introduced a personal assistant. We call it Good Morning.

Good Morning helps us organize and respond to incoming activity that needs attention. It’s our take on a support queue.

Now we were damn close.

We couldn’t tell who was replying to what. Our team sometimes replied to a customer twice because we had no idea someone else was already replying to them. Definitely not ideal.

Our team built presence to see if someone else is responding, and it improved. No more replying to the same customer twice.

By the fall of 2015, our team was using Highrise to reply to every customer email. Something I thought wouldn’t be possible.


5-Hour Energy founder Manoj Bhargava will tell you he grew his product company to over $1 billion in sales with combination of common sense and a sense of urgency. By not doing dumb stuff.

Bhargava claims his company isn’t efficient at all. They just don’t do useless stuff. He cut out everything that didn’t make money, didn’t improve the product, or didn’t make the customer happy.

Business isn’t complicated to Bhargava. It’s just do useful stuff. And avoid useless.

That belief turned 5-Hour Energy into one of the most popular consumer products in the world.

Bhargava, who dropped out of Princeton after one year, doesn’t believe in MBAs. Why? They’re useless.

It’s a simple thing. If you’re going to learn plumbing, go learn from a plumber that has actually seen a pipe. That has fixed a leak.

Not just written about pipes, lectured on pipes, and researched pipes.

I’m not for theoretical plumbers.

Manoj Bhargava, Why a MBA is Useless

Our story is similar. Our team made a commitment to using Highrise more. Instead of being theoretical users of the product, we became customers of it. We depended on it.

We felt the pain our customers were telling us about. It wasn’t pleasant. But it gave us a new insight into what it was like to use the product. It forced us to improve Highrise and to do it quickly.

Sometimes you have dig in and fix it from the inside. It might take a little pain, but it may also be the only way you’ll figure it out.

This post was inspired by this talk from Manoj Bhargava.


P.S. Curious about how we’re applying this to Highrise now? Follow us on Twitter, check out our recent announcements or ask me @cjgallo.