AP: What's the origin story of CommandBar?
JE: My co-founders, Richard and Vinay, and I were working together on a different B2B product. We faced a fairly common user segmentation problem. Our power users gave us great feedback through email and Intercom, and we responded quickly to that by evolving the product. But those product changes made the product hard to use for people who didn't fall into the power-user segment that had offered most of the feedback (and frankly also hard for power users, since no one really used all the features). The product was kind of one-size-fits-all but in a way that meant confusing-for-most.
So we were sitting around trying to figure out a solution to this problem. We've all used Superhuman and other products that have a command bar inside -- basically a search bar for functionality, with keyboard shortcut "Command K" -- and we had an "aha" moment. A command bar would allow us to remove the entry points to a lot of features: instead of a button leading you to X, we could allow you to search for X. That way, any user could quickly find what they cared about, but the UI would never be cluttered or overwhelming. Basically this was a way to scale a UI but keep it discoverable. It also had the unexpected effect of increasing our product velocity; we could build narrow and experimental features without sacrificing any UX.
So we started building it. As we went, we realized that this problem was generalizable to basically every software company, and that it was hard to build well. So we decided to productize the feature.
AP: Do you believe you're creating a new category?
JE: I’d say so, in the sense that there isn’t an established buying center for what we’re building. From a product perspective, you could say we're redefining search to make it work for software.
You could also say we're tackling the same job-to-be-done as some of these companies that offer onboarding flows for customers, like WalkMe or UIPath. They're trying to make it easier for a company to onboard users of different flavors. But we're doing it in a way that helps users across the lifecycle. They can get started with CommandBar to learn how an application works, but then we can support them throughout their user journey, discovering new features or just using CommandBar to do stuff faster in an app.
It's not like there are 5 other command-bar-as-a-service vendors. So people aren't used to buying a product exactly like this, and they don't always have a perfect vision in mind when we start working with them -- but they're super energized by the possibilities. We’re addressing problems that every PM or product owner feels viscerally.
We still do personalized onboarding, hand-holding new customers through that initial configuration to try to identify ways to use the product in their business. We'll discuss, what is hard for users to do in your product? What are the five pieces of functionality that new users might be really interested in when they hit your site? What are the flows that power users complain about most often? So it becomes more of a co-creation process. We supply the activation energy for more folks to get started, and they give us incredible feedback.
AP: What do you think the rise of CommandBar says about how user interfaces will evolve for this next generation of SaaS?
JE: There’s a famous blog post from 2000 called “The End of Web Design” that basically says: because users spend most of the time in other apps, your UI should use the same building blocks as every other app -- buttons, menus, tables, etc. This I think does a good job of explaining why most user interfaces (rationally) look the same. We’ve gotten really, really good at rearranging these building blocks to create great user experiences.
But I think some trends are creating a need for new building blocks:
For me what these trends point to is a need for primitives that make it faster for users to go from intent to action. CommandBar is our proposal. In an app that uses our widget, users can open up the app, click once to open CommandBar, search for what they’re trying to do (in their own words), and be presented with a series of actions they can take immediately. No learning required. I often joke with our customers that turning off CommandBar would be like asking their users to stop using Google search and go back to Yahoo Directory. It just makes the old building blocks feel old.
I don’t think the old building blocks are going away though. Traditional UIs are really great at teaching users about information architecture, for example. But I expect new primitives -- maybe CommandBar, maybe something else -- to supplement them by providing a faster way to get from intent to action.
AP: Why do you think Command K is so powerful?
JE: Because CommandBar is a search bar, it’s very simple to use. Some people look at it and think “that looks like a command line interface, it must be for power users”, but we have tons of end users who don’t identify as power users and don’t use keyboard shortcuts. Anyone who can use Google can use CommandBar. Just type, in your own words. That’s it.
Like search, it’s also personalizable. PMs spend so much time creating flows to accommodate different user archetypes (this is basically the brick wall we ran into at our last company that motivated us to build the first version of CommandBar). CommandBar is easy to personalize: it’s very easy to show onboarding-related commands to new users and more niche features to power users.
And then the kicker is that it’s also fast. When you achieve something with CommandBar, it feels good because the time between intent and action is short. So you want to use it again. And not using it is like ordering something on Amazon and not getting free-2-day shipping: it just feels subpar.
AP: I've often thought that eventually UIs will be independent of screens — whether it's through audio commands (like Alexa, but built into software) or perhaps holographic. What's your take on this? If you agree, what kind of timeline is likely for UIs to evolve in this direction?
JE: I view Alexa and voice interfaces generally as another solution to the “intent to action” problem. When I’m lying in bed at night and need to set an alarm, I want the alarm to be set as fast as possible after I form that intent. I don’t want to do anything to achieve it, I just want it to happen.
I don’t expect voice interfaces to replace software with screens anytime soon though, because there is so much work that would be impractical with voice. Imagine trying to build a spreadsheet with your voice. Keyboards and screens are pretty great for a lot of knowledge work. Maybe there’s a Lindy effect there -- maybe they’ve stuck around for so long because they’re just really good interfaces.
Neuralink and other brain-machine interfaces could completely upend the keyboard-and-mouse status quo, though. I don’t really know anything about the technical details, so I’m not sure what kinds of workflows are actually tractable to achieve with a brain-machine interface, but I’m pretty sure that there is no faster way to go from intent to action than to go from thought to action.
AP: Do you have a specific way that you measure product-market fit?
JE: Yes, two ways. First, we ask all of our customers the question that's become commonly known as the Superhuman product-market fit question: How would you feel if you could no longer use CommandBar? Second, we ask our end users -- the people who are using CommandBar inside of our customers' apps -- the same question. It could be that the customer doesn't think there's value but their end-users actually love it.
AP: That's very interesting that you're taking ownership over the customer experience that your customers are offering. It’s a “meta” form of customer success.