hubspot is a frustrating tool. at atlas every team uses it, and now that I'm informally part of our sales team, I'm in it day to day.
hubspot rarely guesses what I want to do next. some of the things that get in my way:
- there's a Cmd + K for searching across the whole app, but it's slow. it can take 3 seconds to load after I type a query, which softens the point of having a shortcut (it's often faster to click the option in the left sidebar). search results don't usually surface what I'm looking for first. the order is Contacts, Companies, Deals. if I search for a company name (because I want to land on the company profile), I have to scroll past a list of contacts that belong to that company first, because that's the order results come in. if I search for a person by email, I get a list of everyone with a similar name. if the person doesn't exist, I usually want to create them, but creating is a separate flow.
- having to manually save changes can be confusing. in modern UIs built in the last few years, changes save as you edit. having to press "save" is harder than it sounds, mostly because it's not always clear what's in scope. does the save button apply to the whole screen or just the input I just touched? can I keep editing other things and it'll store them all, or only the first one I touched? and if I accidentally refresh the page, my changes are gone.
- configuring how the platform looks is less intuitive than I'd want. you have to go to Settings, and almost everything ends up being edited inside Objects. there isn't an obvious order in either Settings or Objects. usually I have to read the entire list of options to find what I'm after. when I can't, I end up googling how to do what I want.
- the workflows screen is one of the trickier parts of the product. to build an automation you have to start from an object, which surprised me (the pattern I was used to is starting from an event). I won't go deep here because I could write a whole post just on workflows.
at the same time, hubspot is also an incredibly powerful tool, for reasons that have nothing to do with the friction I just described. if someone were building a different CRM and asked us to try it on the team, we couldn't, and the reason is clear: hubspot is wired into our entire workflow (across 3 teams: marketing, sales, and CX). we can't "just try another CRM." the implementation cost would be enormous. that got me thinking about how someone who wanted to build something in this space would actually compete with hubspot. these are my hypotheses.
the things hubspot does well
start by understanding what makes it a good tool. I think it's these:
1) integrations across the rest of the stack (it integrates with performance tools like SEM and FB ads, with outbound tools like Apollo, with Gmail and other email providers, with Stripe and others).
2) it centralizes information across at least 3 areas: cx, mkt, and sales. it's the single source of truth for those 3 areas. they go to it to check metrics and track their work.
3) it ties marketing and sales together like nothing else: tools that are just good CRMs don't do this, and that complicates the sales cycle. when you can pool mkt and sales leads in one place, it's easier to run remarketing campaigns or understand the full lifecycle of an account. same thing when those accounts get handed off to CX for expansion. all the info lives in one place.
4) it's free. that's tricky for a startup. competing with a free product is hard because the alternative has to be meaningfully better for someone to pick it over the free, consolidated version.
where to start if you want to compete
the challenges of building a tool to compete with hubspot:
1) for an organization, switching has a huge cost. one way around that is to sell only to startups at first, and I think that's a naïve first approach and not a good idea (why: startups graduate off you; they need more things; "startup" can mean ten thousand different things).
2) for it to work, it has to integrate with your current stack from day zero. that's expensive because integrations are complex and slow. the hardest part is figuring out which integrations to start with. I have a strong take here: I think the wrong approach is "whatever users ask for" or copying the most popular hubspot integrations as they exist today.
how to compete with hubspot
first claim: at some point a tool will come along that rethinks this space. it's the natural cycle of any industry, and hubspot, compared to tools born in the last 5 years, has some shortcomings that today's users feel. someone will eventually build a tool that solves this problem 10x better with today's tech, and it'll take market share the same way hubspot took it from Salesforce.
the hard question is how that tool should start. the problem to solve is clear: how do you build a tool that's a better version of hubspot in the shortest time possible, while generating revenue from day zero? the challenge is the scarcity of time. to put it another way: what does a tool look like that you can build in 4 months or less and that can pull paying customers off hubspot from day 0?
my solution
1) pick a single segment. hubspot has many types of customers. different industries use the platform very differently (and hubspot has thousands of features). an ecommerce company uses it differently than a b2b saas. a b2b saas uses it differently than a b2b with usage-based pricing.
pick one of those segments and figure out which features are priority for that group. I'll pick one because examples make it easier: a b2b saas sales team only uses a few things:
- Integrations: linkedin ads yes. instagram ads no. gmail yes. outlook yes. google calendar yes. zoho no. intercom no. stripe yes.
- Features: sales pipeline yes, automations yes (but only one: you have to figure out which one. if I had to guess, I'd say the top one is updating a deal when different events fire).
there's something very important about picking one and only one segment: you have to be inflexible. we are not going to integrate with intercom. we are not going to integrate with zoho. we are not going to add the automations marketing wants.
focus has to be brutal and unapologetic. we only do that one thing. when do we stop only doing that thing? when we have a solution that's 10x better than hubspot's for that segment. that's step 2.
2) the second thing we have to do to win is have a solution that's 10x better than hubspot's, but only for that segment. what does 10x better mean? the tool has to guess what I need and what I'm going to do next. the only way to get to that level of product quality is to be the first users of the platform yourself (we have to be sales people in b2b saas to be users), and it's really important to obsess over solving the only problem this user has. what problem? closing deals. how can the experience of closing deals be 10x better than hubspot's? you obsess over that flow and only that flow. how do I know my solution is 10x better? users will tell you.
3) this game is only won with speed and revenue: none of it matters if I build something behind closed doors for 4 years only to find out it doesn't work. the variables to optimize for here are speed and revenue, and those are the only ones that matter. what features does a product need so people pay for it after 4 months of development is the only question I'm trying to answer. neither variable is negotiable, and here's why.
why I can't stretch the release timeline: first as a matter of survival (every startup is always running out of money), but also because a short development cycle gets us user feedback faster, which is the only way to end up with a good product. I've already written about why shipping incomplete things matters, but the short version is: you have to validate with users and build with their feedback.
why I can't offer the product for free: because at this stage what we're running is an experiment. the experiment is whether there's a business in this idea. that's the only experiment we're running. we're not testing whether users like our app, or whether they want to use it, or whether it solves a problem for them. the only thing we're trying to prove is that the problem is sharp enough, and the existing solution is far enough off, that users are willing to pay for ours. an mvp is an mvp of the business, not of the technology. what we're testing is willingness to pay and nothing else.
so: the two variables we can't touch are speed and revenue. that actually gives me a lot of peace, because it sets the playing field. every other variable is fair game. for example: instead of building an app, can I run a whatsapp group with my users where they tell me how their deals are going and I update an excel by hand? yes. (one extra challenge: this is an established industry and the product isn't category-defining, so janky solutions like that won't always work. the user expects a product, because they already know the category.)
how to keep going
once you have the product I described, the next step is to do the same thing for a second user group. in my case I'd go to marketing next, because the way the work of those two areas comes together is what makes it so important. but you can't leave the industry. it doesn't matter how many intercom messages I get telling me we have to add a Shopify integration. we only solve a problem for b2b saas (now for sales and for marketing).
this was a thought experiment for me. I'm writing it because I enjoyed thinking it through, and it made me reflect on where it overlaps and doesn't with the problem I work on today (which isn't this one). I'm sharing in case it's useful to someone else, and because all that matters is shipping, even when what you're shipping is text.