Bargain for Bugs

Comic from xkcd.com

I found a bug . . .

When you receive an email from a customer that starts like this, what is your first reaction?

Disappointed? Are you anxious? Shocked?

The support team at Highrise is often skeptical. Why?

Because sometimes what you think is a bug isn’t a bug at all. It’s an expectation.

We’re firm believers that the best answer is a question.

Because if you expected X, and got Y — that’s not a bug. It’s an expectation. What did you expect to happen is a powerful question.


For example . . . .

I found a bug. When I filter by the tag Chicago and I only see four total contacts. There are several other people associated with the companies tagged Chicago so why does it only show four?

Please advise on when this will be fixed.

This was an email our support team received over and over again. When we began asking the question: What are you expecting to happen?

We found that the customer expected to filter by the tag Chicago, and for that filter to include all people contacts that belong to companies tagged Chicago too. However, this isn’t how Highrise was built to work at the time.

Unless, you also tagged all the people contacts with Chicago, your filter won’t include those people contacts. Only the company contacts.

This wasn’t a bug afterall. Highrise was working as it was intended in this example. The problem was that intention didn’t match most customers’ expectations.

This was an email our support team received over and over again. This isn’t a bug. It’s only a difference in expectations.

This failure of expectations led to our team to make an adjustment. Instead of the intention to only include people if they have the same tag, our team made it so if people contacts belong to a company contact, those people contacts inherit those same tags. We call it company tags.

Not a bug, but a failed expectation led us to improve Highrise using company tags.

I’m not here to argue the definition of a bug. Or to make a case that bugs don’t exist in Highrise. Or to say if a customer assumes there is a bug, that they’re wrong.

Of course, they’re not wrong. And bugs exist in all software too.

All I’m suggesting is before giving in and adding to your bug report, ask a question.

What are you expecting to happen?


Enjoy this post? Smash the 💚 to share it with others. And if you need to track leads and manage follow-ups, please check out Highrise. Your address book doesn’t do enough, other CRM software tries to do too much. Highrise is built to do just what you need — no more, no less.

Jousting with Jekyll

One responsibility of the support team here at Highrise is to maintain our Extras page.

What’s the Extras page?

It’s a list of all the 3rd party products that integrate with Highrise. Almost all were built by the 3rd party using the Highrise API.

This page is important for current and future customers because people use more than one product to get their work done. And these integrations can often save people tons of time.

But it became an absolute pain to manage for us.

Why?

There are a whopping 63 different listings on the Extras page right now. Requests to add new listings, update current listings, and remove old listings started to add up.

The Highrise marketing site is maintained using the static-site generator Jekyll. It gives our team control over our content, it works fast, and it’s not a feature heavy dynamic CMS like WordPress.

Jekyll is simple. And powerful . . . if you know how to use that power.

The Extras page was just a giant HTML page in Jekyll. All listings were written in HTML, and if you needed to update a listing, you had to edit the repetitive HTML file and find exactly what line needed to be updated.

This led to manual errors. Typos in HTML. Incorrect links. A lot of wasted time to make tiny changes.

Enter Jekyll data files.

Data files give a middle finger to repetition. You can set custom options and load custom data to make your life much easier.

Here is a short video of why we made this change with an example:

How to use data files in Jekyll

First, create a folder in your repo titled _data and save it. This is where you’re going to store your files.

Files can be in .yml, .yaml, .csv, .json format. We’re using .yml in our example.

Now, create a file you want to store in the _data folder. We’ve created the highrises.yml file.

Here is an example of one of our data files in /_data/highrises.yml format:

- name: Highrise iPhone App
link: https://highrisehq.com/apps/ios
image: extras/img_iphone_app.png
description: Collaborate on contacts, notes, and tasks all from your iPhone.

- name: Android
link: https://highrisehq.com/apps/android
image: extras/img_android_app.png
description: Collaborate on contacts, notes, and tasks all from your Android.

The data can now be accessed usingsite.data.highrises in our HTML. The filename highrises determines the variable name.

This information can now be used in your templates or HTML files.

For example:

https://gist.github.com/gallochris/a583994674eee7426896040e98de74d2

Using site.data.highrises in our file, Jekyll will insert the information from the data file.


Data files have saved us lots of time here at Highrise. Other examples of where you might use them:

  • accessing different authors’ bios of your blog
  • posting store hours for your brick-and-mortar shop
  • ordering any list of products you’re selling

If you’re interested in learning Jekyll, we recommend checking out the tutorials here and the community here.


If you enjoyed this post, please tap the 💚 and share it with others. And check out Highrise. CRM systems are cumbersome and take too much time. We designed Highrise, so you’ll be a master within minutes.

Data is Man-Made


Here’s a secret from the support team at Highrise. Customer support metrics make us feel icky.

Our team doesn’t know our satisfaction score. We’ve never asked any of the people that use Highrise to try those types of surveys.

We can’t give you an exact number for our average response time. It depends. Sometimes it’s 90 seconds, and other times it’s within 24 hours.

We can’t tell you our average handle time for an issue. Our team has a general idea, but no exact number.

These types of customer support metrics aren’t wrong. We’re sure they work for other support teams.

We’re just not sure they’re right for us.

Because there is one piece of knowledge we’ve come to realize: data is man-made.


What do you mean data is man-made?

Data or metrics or stats are all man-made. A human decides what to measure, how to measure it, how to present it, and how to share it with others.

But why does it matter to measure these things? And what’s the point?

A lot of times people avoid these questions when it comes to data. Companies copy what other teams measure, ignoring the fact if it’s important to measure the same things in the same way, or if it’s even important to measure it at all.


But isn’t all data objective?

Many people view numerical data as more trustworthy than qualitative data.

Clayton Christensen, Competing Against Luck

Numbers are black and white. Concrete. You can trust the numbers.

Right?

Nope. Almost all data is built on biases and judgement. Because humans are deciding what to measure, how to measure, and why to measure.

Numbers fit perfectly into a spreadsheet or a graph. A number gives a definitive answer to questions like how much or how many.

That doesn’t mean you should treat those numbers as insights and act immediately. Data shouldn’t be used to prove a point.

Data should be used to fuel your imagination.


Words > Numbers

Qualitative data isn’t easy. There aren’t any formulas or simple math. It doesn’t fit into a spreadsheet. It doesn’t answer questions. It’s not black and white.

It’s colorful. Messy. Qualitative data creates more questions. It’s not simple to present or share with others. It takes some time.

Our support team has found one thing to be true. Qualitative data is worth it. 100 percent worth it.

For example, our team recently updated the filters in Highrise. This update was to an earlier revision to filters we made during the year.

It was driven by one piece of qualitative data from a new user:

Thanks for pointing out those filters. I didn’t even know they were there. Those icons weren’t obvious to me at first.

This hit all of us across the nose. The filters looked better. It was a much more clean than the original design.


The original design vs. our next iteration

We didn’t make these changes just for aesthetic reasons though. The original design had a lot of trouble for most of our users who had more than a handful of custom fields. But how to use the filters wasn’t as obvious any longer.

Folks need to find a specific set of contacts in the city of: Chicago, that have the value: Interested in the custom field: Status, and that are tagged: Potential.

It wasn’t clear how to do that, so our team made a change.


We made it abundantly clear what to click on to add a filter.

Quantitative data didn’t tell us we needed to make this change. It was all qualitative.

Questions from customers and questions from our team. It was a conversation. There is not a numerical value you can put on that.


So what do we measure?

Instead of striving to lower our average response time or improve our customer satisfaction score, our support team is aiming for something a bit different. Something harder to measure. It’s not a number.

As Alison would say, we strive to put ourselves out of work.

Don’t confuse that with us not wanting to work at Highrise. We love it, and love working with our small team.

What we mean is we want to make it easier for people to use Highrise. We want to create a product that is so obvious and so easy to use that we seldom get questions on how to use it.

And when folks do have questions, we want to have resources available to them right away, so they can help themselves. So if someone has a question at 2 am in the morning, and we’re not around, they can find an answer without waiting for us.

Because we don’t believe managing a number is going to improve our support. We believe focusing on customers and what they are trying to do with Highrise is going to make a better product, and better support.


If you enjoyed this post, please click the 💚 to share it with others. Please don’t take this as gospel either. What works for our team, might not work for your team. And vice versa.

Also, chapter 9 of Clayton Christensen’s recent book, Competing Against Luck, was a big inspiration for this post. The entire book is great, and you should check it out.

The Curse of Knowledge


“Uh, it’s off Airport Road. You should be able to get there from Umstead. I think or, or maybe go up to Estes?”

I paused again. I was confusing the person asking me for directions more than I was confusing myself.

What was the matter with me?

I grew up in Chapel Hill and went to college there. I lived there for over a decade. I was a local.

And when a stranger asked me for directions, I couldn’t tell them.

I stammered over and over, and told them they might need to ask someone else or look at their phone.

Was something wrong with me?


One of the most rewarding, and challenging, things about working at Highrise is how fast the product changes.

Our team runs on a train schedule. This means every few weeks we announce an improvement or something new.

It could be a big feature like recurring tasks, or something small like a new rule for auto-forwarding emails.

The reward is we’re making the product more useful to ourselves because we use Highrise every day, and making it more handy to customers.

A big challenge is documenting these changes. It’s informing people that use Highrise with what has changed, why it changed, and how to make use of the changes.

The number one resource for this is our help site. It’s a living, breathing how-to guide or user manual.

It’s a beast of a resource to maintain. There are over 100 articles, countless screenshots, and videos.

And with frequent updates, this snapshot or how-to guide of Highrise can go out of date fast.

It came to our team’s realization when updating a screenshot. The settings menu now has a new option for all users (Referrals), and the old screenshot didn’t reflect that.

It was a tiny change. A person new to Highrise might not even notice it. Our team did, so we updated the screenshot.

This change sparked lots of others too. We began to notice videos were out of date by months. More screenshots too.

A pull request with one commit, a change to a screenshot, turned into a two-week project. 277 changes later, our team updated the entire help site to more accurately reflect the product.

What took us so long to realize things were out of date?


Nicholas Epley has a dynamite book on this topic. It’s called Mindwise: Why We Misunderstand What Others Think, Believe, Feel, and Want.

In the book, there is an eye-opening exercise.

FINISHED FILES ARE THE RESULT OF YEARS OF SCIENTIFIC STUDY COMBINED WITH THE EXPERIENCE OF YEARS.

Epley asks you to count how many fs are in this sentence. Start counting.

How many fs do you count?

Is it more than you can count on one hand?

If not, Epley has confirmed you’re a terrific reader, but a terrible counter.

Now count them again? Did you find all six fs?

Don’t forget that the word of has an f in it. See all six now?

Most people, including myself, only found three fs.

Why is that?

Epley explains it has everything to do with knowledge.

He continues, “Your expertise of English blinds you from seeing some letters. You know how to read so well that you can hear the sounds of some letters as you read over them.”

So, because of your expertise, every time you see the word of, you hear a v rather than a f, and you miss it.

Epley points out, “First graders are more likely to find all six in this task than fifth graders, and young children are likely to do better than this than you did as well.”

This is known as the curse of knowledge. Why is knowledge a curse?

Because once you have it, you can’t imagine what it’s not like to possess it.

Knowledge or a level of expertise gives you the lens of a microscope.

It means you notice subtle details a novice might not catch, and it also means your focus is so sharp, you might miss the big picture and you’ll struggle to understand a novice’s perspective.

Epley offers a slew of good examples in the book and elsewhere too.

One of my favorites is how Clorox bought Hidden Valley Ranch Dressing and spent a decade trying to make the original recipe so that it did not need to be refrigerated. All of their internal taste tests of the dressing came back as worse than the original. Or so they thought.

Hidden Valley finally sent a worse tasting version of the dressing to the market, and people loved it. Because not many people ever tasted the original dressing. The consumer’s perspective was way different than the company’s perspective.

Epley writes further, “The expert’s problem is assuming that what’s so clear in his or her own mind is more obvious to others.”


This is something our own team fell into at Highrise. We were spotting tiny changes like typos or a missing menu option in a screenshot, but missing the bigger picture that almost everything was out of date.

Our perspective was way different than someone who started using the product yesterday.

And it’s what happened to me when trying to give directions. I could probably get the stranger to the location if we rode in the same car.

I could tell her Airport Road is now named Martin Luther King Jr. Blvd. And there used to be tons of trees on Umstead Road that the city cutdown. I could point out all these tiny details.

But I couldn’t tell her how to get there on her own.

There was nothing wrong with me. I was cursed.

Cursed by knowledge.


If you enjoyed this post, please click the💚 and share it with others. If you enjoyed the ideas, I recommend reading Nicholas Epley’s book. It’s fascinating. And if you’re curious about what improvements we’re making to Highrise, catch up on our announcements.

Why You Should Care Less


Relationships are weird.

We have names to describe all sorts of the relationships we have with other humans.

Friends. Acquaintances. A husband or wife. Brothers and sisters. Father. Son. Mother. Aunts and uncles. A cousin.

So many names that indicate the context of a relationship.

Bosses and employees. Boardmembers. Colleagues or coworkers. Neighbors.

Defendants and plaintiffs. A judge and jury.

Customers or clients.

In all of these relationships, who is in control?


Over the past few years, I’ve worked directly in customer support for companies that make software.

It’s a job I’ve come to really enjoy. It brings a lot of purpose to my work.

People buy a product or subscribe by paying a monthly fee to use a product, and they have questions or requests. Someone needs help, and you help them. That’s my job. It’s to satisfy these questions and requests.

It’s an incredible feeling when someone says something nice about you or the product. The folks that work in customer support know they get the glory first. The warm fuzzies. The good vibes from the satisfied people that use the product.

But you can’t satisfy everyone.

For all the glory, there are people who only want to argue with you. The ones who say they have a question, but don’t ask one and end their email with please advise. The people who aren’t a good fit for your product. And don’t know it yet.

Customer support can get ugly. When a customer says something not so kind, it can really take the wind out of your sails.

I’ve learned you shouldn’t take it personal. After all, they’re not blaming you, specifically. They’re blaming the product. You’re not the product. You’re you.

But that’s hard to do. Real damn hard.

Over the past few years, I’ve found myself in a fair share of arguments or disagreements with customers. Situations where I get really worked up at times.

So worked up I take it out on the people around me. Or so angry, I need to take a walk. Or play music like this with the volume turned all the way up.

When I feel like this, I realize it’s because I care. And it’s because I care a lot.

I care about my job. And the people I work with. I care what people say about me and them. I care about the product.

I take pride in being able to help people. If someone is complaining, it’s my job to address it and listen. To try to understand why, so we can improve the product.

But when someone says something nasty or uncalled for, it’s hard not to take it personally. It’s so hard to give it a good five minutes. To take some deep breaths before replying and do something silly.

And because it’s hard, I’ve had my fair share of spirited back-and-forths with customers. Email conversations or threads that are exhausting. That are a road to nowhere and that leave me mentally spent.

Why do I do this to myself?

It’s because I care too much.


Gordon Livingston was a therapist and author. He wrote lots of books on being human.

In one of his books, Too Soon Old, Too Late Smart: Thirty True Things You Need to Know Now, he shares a lot of wisdom.

Each chapter is a truth that you need to know. And one chapter is on relationships. Livingston had lots of experiences with relationships, and cites helping couples navigate their marriages.

Here’s his truth about relationships:

Any relationship is under the control of the person who cares the least.

Livingston continues to explain that in these marriages, there is one person that cares a lot more than the other. The person who cares the most is at wits end about what to do. This person is pushing for the marriage counseling and they’re the one invested in the relationship.

And if the other person is not, the person who really cares feels powerless.

This idea really hit me.

It got me thinking about my own world. How I let myself get so worked up when a customer says something unkind. And how I care too much, putting the other person in control.

When I care too much, I’m putting the other person in control of a relationship I shouldn’t even be in.

You have to have thick skin working in customer support. You have to let some things go. One person being upset isn’t a reflection of you or the majority of people that use the product.

It sounds backwards, but you’ve have to care less. Not more.


This applies in every relationship in life too.

A boss or colleague might not respect you. Or a neighbor or an acquaintance might be rude. You might disagree with others about politics, and others might say hurtful things to you.

If you get worked up and care too much about what they say, you’re putting that person in control.

That’s what they want too. The control. Don’t let them have it, they don’t deserve it.

Care less.


If you found this post helpful, please click the heart below to share it with others.

This was originally published on my blog. I also transcribed an interview with Gordon Livingston that you might enjoy, check it out here. And if you’re looking for a great summary of his book mentioned in this post, I’d recommend reading through Derek Sivers’ notes here.

Exploring Paley Studios


Our team is always blown away by the useful advice Highrise customers are willing to share with us. Here’s another we think you’ll want to hear.

Paley Studios has been using Highrise daily since 2007 to help organize various projects, information and contacts.

It’s an invaluable online resource that allows us to keep project information, for multiple projects, organized and instantly accessible no matter where in the world we are working from.

But this isn’t about Highrise; it’s a story about Albert Paley, a world famous artist, and it’s a lesson in exploration, learning, and… having a plan B.


Diversify. Learn to be good at one thing many ways.

Albert Paley is a lifelong artist. He was the first metal sculptor to receive the coveted Lifetime Achievement Award from the American Institute of Architects, the AIA’s highest award for a non-architect.

You might have seen his work on Park Avenue in New York City. You’ll see his massive sculptures outside of national museums, the St. Louis Zoological Park, or maybe you’ll even find piece of his unique furniture at one of your friends’ houses.

And when you see his work, you’ll know it’s his.

Why?

As the director of Paley Studios, Jennifer Laemlein shares, “you can definitely see Albert Paley design. You can see elements he uses. The combination of the geometric and the organic. The ribbons and the flow of the steel.”

Paley’s Animals Always sculpture as a gateway to the St. Louis Zoo. Photo credit Paley Studios Archive.

Nothing about Paley’s work is shy. It’s not timid. Or submissive.

Laemlein continued, “he tends to like to do large public art. We’re generally working in the realm somewhere from 50 to 100 feet tall.”

To put that in perspective, these sculptures range from 5 to 10 stories high or wide.

Albert Paley’s work is physical. It’s bold. Big. Aggressive.


So how did Paley get his start?

Albert Paley has been making things out of metal for over 40 years. Paley started as a goldsmith making jewelry.

Paley has always been an artist. His goal with designing jewelry was to do something that hadn’t been done before. It was to explore.

And he did. His jewelry was approached as a sculpture art form to adorn the human body. The oversized pieces responded to the shape and movement of the wearer.

But Paley had bigger ambitions for his work. He understood iron and transformed himself to work on larger scale projects. He embraced architecture.

In 1975, Paley described what he does as, “a lot of my work has to do with exploration. Exploration of processes. Within the metal field, there is great diversity of process orientation. I felt that with metal I had the flexibility of exploration that I didn’t have in any other medium… There is no limitation whatsoever.”

Paley’s process of designing is like his personality. It’s intense. The process is always evolving and changing shape depending on what Paley is creating.

For most works, the first step of the process is lots of sketches on paper.

Paley’s wife, Frances, claims he doesn’t know even how to turn a computer on and he has no email address.

He would rather sit with a pencil and piece of paper. That’s where he likes to work from. Very basic.

For Monumental public art projects, he starts with hundreds of drawings to build a matrix. Paley then selects what’s most important from the drawings and creates 3-dimensional sketches using cardboard. This helps with understanding angles and developing a visual vocabulary. This takes Paley to a metal model, a smaller version of the sculpture. The studio might go through 3 to 5 different cardboard and metal models before beginning to build the sculpture at full scale.

Once at full scale, Paley and his staff work in stages to complete the large sculptures. There are fabrication and forging stages that can take months to complete.

Paley going through his processes. Photo credit Paley Studios Archive.

Today, he could be described as a goldsmith, an artist, a blacksmith, a sculptor, or an architect. But in the truest form, Albert Paley is an explorer.

He is in constant pursuit of creativity. And his definition of creativity is refreshing.

So many people think of creativity in artistic pursuits. But creativity is just a fundamental human condition. You build on a vocabulary. On a foundation to build a concept or understanding,

If you’re already dealing with your understanding on an order of things, that’s something that you already know. Where real innovation comes in is getting those things that are unknown.

It comes from exploring and discovering what you’re capable of doing. And each of Albert’s projects is bigger and more ambitious than the last.

In 2013, Paley created 13 unique landscape sculptures for a 6-month exhibition on Park Avenue in New York City, the largest exhibition ever on the famous avenue.

Like Paley, this project wasn’t tepid or ordinary. This project was brash and exhaustive. It was ambitious.

Watch more about the project:

Elizabeth Cameron, archivist at Paley Studios, describes the installation process:

In June 2013, over the course of 2 nights we installed 13 landscape sculptures for exhibition on Park Avenue in New York City. Imagine the communication and permitting necessary for shutting down sections of Park Avenue overnight, while running 2 crane and installation crews at the same time as the 13 flat-bed tractor trailers loaded with 15–20 foot sculptures are waiting across the river in New Jersey. The sculptures are radioed in two at a time. There 2 film crews there, other photographers and media too. Then imagine doing it all in reverse six months later when the exhibition ends and all the sculptures have to ship to their new homes.

That’s a serious project and one that requires the help of an entire staff. While Paley started as a one-man band, his staff includes 14 people who help him toward his creative vision.

The studio is constantly prototyping or building something. And what they’re building is usually large, so any mistakes will be costly.

The staff thrives on this challenge. Jeffrey Jubenville, a foreman at the studio, confesses, “it’s very fulfilling, and that’s what is important to me. Being challenged daily. There are probably 200 items on the the floor at one time. There are pieces everywhere, all under different stages of development.”

The studio’s archivist agreed with Paley’s advice around exploring and learning to be good at one thing many ways:

Albert’s ability to create on multiple streams has allowed the studio to continue to exist during lulls in the various markets. So when public art is slow the galleries pick up, or when the galleries are slow the commissions pick up. Always have a plan B.

And keep exploring.


P.S. If you need help keeping track of who you talk to and what you talk to them about, please take a look at Highrise. It’s a simple tool to manage your communication with others. And be sure to follow us on Twitter: here.

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.