HubSpot API Development Panel Discussion | HubSpot.Extend() 2022

So let's get started here. So hello everyone, who's listening in? Thank you for welcome to this panel discussion. My name is Tessa Peart. I'm the research lead on developer products group here at HubSpot and we have this amazing group of panelists here today who have between them a really broad range of experience building all types of solutions on and off of HubSpot. And I'm so excited to have the chance to talk to you all just about building using HubSpot's APIs and your experiences generally. Thank you again for taking the time to do this today. Let's start with some intros. Could you all just say a little bit about yourselves and your company and what you do? Let's start with Remington.

Yeah.

All right, I'll go. So. Hi everybody, my name is Remington Bagg. I'm co founder and CEO of Impulse Creative. We're an elite partner agency.

Hi, I'm Mike Eastwood. I'm coming in from New Zealand this morning to be on this call. I'm a marketing geek and my company Webberlite is more @ the geeky end of marketing rather than the coloring in the end of marketing. So we love playing with HubSpot and making it do things that it doesn't do out of the box.

Hi everyone, I'm Luis. I'm from auxiliary. I'm the CEO of this Canadian based partner HubSpot partner firm. And yeah, I'm a guy who started in marketing and learned how to code to just push HubSpot further and that's it. Yeah, thanks.

Great. Thanks so much for those intros. Let's start with just a really high level question here. You've all had a lot of experience in the industry. As I mentioned, over time, sort of working with many different clients and seeing how they put together their tech stacks and their technology. I'm curious if you've noticed any changes in those businesses tech stacks over time, how they've evolved and how you might imagine them evolving in the future.

I think one of the things I've seen a lot over time is that everybody had an app for everything and it just exploded and all we ended up with was fragmented data in different places, people losing passwords, not being able to renew an account, just a mess. And so it's kind of exciting to see we've reached peak app and they still have a place. I'm not dismissing them, but when you look at what we can do inside HubSpot now and the way it's going, it's really exciting for me to go we can build those apps inside HubSpot, we can plug in integration and it just makes everybody's life easier.

Yeah, of course. I think that the old ecosystem of customer facing, application marketing, sales, customer service are like platformatizing. I will invent a word here where yeah, back in the days we have to build those Frank and spot like many hubspotters like to call them. And now we can do so much thing inside of a platform like HubSpot. But this is a thing that happens also outside of HubSpot. I think that many tech stacks are platformatizing to enable people building things inside of an ecosystem that is connect together. And this is super helpful because back in the days and still for some part of the things that we're building, we need to connect so many things together. And Mike, just summarize it well, how painful it can be.

I think one of the things we've been noticing is that over the years, so We've been a HubSpot partner for 10 years now. In the beginning it was HubSpot was a point solution for marketing to, you know that we had to connect everything else. There's still a lot of apps that we had to think about or ways that we had to connect. One of the biggest things back then was less API support from both sides. You know HubSpot was an earlier tool and other tools just didn't. That wasn't really a thing. So now what's the big transition is, is now everything is assumed that it can talk to each other very easily, might I add. But it's actually quite complex if we, if you think about it the right way and that's probably been the biggest area is everyone just expects it to be there. The Amazon like experience is, you know, it's very data based, data dash based in that regard. And I think a lot of people want that but they don't realize how much work it is to get all the information together in one spot.

Creating the single source of truth is easier than ever, but it's still really hard.

No kidding. So that's really interesting that you all just mentioned a little bit about this like platformatizing of business systems. What do you think that means for you know, let's say you have a company that's using a couple of those different systems that are trying to be a platform like maybe HubSpot, Salesforce, Microsoft, whatever it is. Do you think that's made those systems easier to integrate with each other or does it make it more of a competition between them? What does that look like?

I'll jump in on that one. I think everyone's fighting for the same real estate right now. Like even there's even, you know, beyond just Salesforce and Salesforce and HubSpot, but everyone's fighting for it. And I think the, you know, in the key, the opening keynote, they talked about the fact that these point solutions were like what it was in the past and now it's that platforming side of things. The problem is, is we've got, we're, we're not used as providers to, or getting used to having multiple internal teams that are the decision makers in these. So it used to be Salesforce wants sales on Salesforce Marketing wants HubSpot and oh great, they have a connection. So now service is having the same kind of conversations about whether a point solution or platform is better and it's, it's having to bring in more heads to have those conversations and it adds a lot more complexity to the stack and the decisions right there. So I think that's probably one of the biggest shifts. It's great when it happens, but getting everybody on the same page is usually more of the task.

Yeah, that's really interesting. And that kind of leads to my, my next question. So as everybody is, you know, like you said, competing for the same real estate here, everybody wants to be the source of truth. How has that changed your approach to choosing and recommending and integrating all these systems, if at all?

I think for us we try and fit the software around the business rather than the other way around.

So.

I mean, we have come across customers where they've been trained to use HubSpot but not in the context of their business. So one of the good things about unfortunately having multiple sources of truth, if you want to send your email Through Gmail or HubSpot or Outlook, doesn't actually matter. So I think from a customer's perspective, that's really good. And to generalize flattery for the team here, we're good at managing complexity whereas normal human beings aren't. And so how do we manage that complexity? Whether it's choosing, recommending couple of different email clients or simplifying a business process. And so I think that's our job to solve for the customer so that we're recommending the tech and recommending how they use the tech to achieve their outcomes rather than our outcomes or HubSpot's outcomes or anybody else. It's about solving for the customer in that context.

Yeah, yeah, that's really important to have the business need or the customer's need. Or call it whatever you want first and then adapt the technology around that. But also be like focus on the technologies really working together. Because when you go to a marketplace like HubSpot Marketplace or whatever other marketplace, you can see a bunch of logos there where oh it's so cool this and that integrates together. But we need to define what is the integration because it's 100% sure that not all the objects and all the records and all everything is connecting just by the click of a button. So, so you need to be aware of that when you recommend integration. And yeah, it's easy. Your first question it was is it easier now to connect systems together? Yes, it is. But it doesn't does anything that the business needs because every business have very specific use case and those integration. If it fits your needs, you're very lucky. In fact you can be very very happy about that. But most of the time it won't fit your need 100%. It will do 20% of the job that you need to be done. It will be 40, 60, but very rarely 100%. So you need to take that into account when you analyze I call it platform consulting. When you map everything that a business tries to to achieve and if you want to check the box that everything that needs to be done, you probably need to put your hands in custom integration at some point.

Yeah, we, we go diagnostic first on all of our really just about all of our work that we do at impulse. But to that to your point, it's the same thing. We, we get a lot of asks but then when we start to peel back all the layers of the onion, um, and we interview several folks. So like we'll interview service and sales and whomever might have data that's related to it. And it's never what the, the key stakeholder says it is or at least not completely. So we, we find that going really heavy deep in earlier also lets the client know that it might be a bigger or smaller path than it it then they think it will be. But it's almost always two to three times more work or two to three times more fields or two to.

More.

Labor or change management even. And I think that's a big part too.

Yeah, yeah, that makes a lot of sense. I was really curious Liz, what you just said about platform consulting. Can you, can you say a little bit more about that? What does that look like for you?

In fact, there's a very nice certification on the HubSpot Academy about that. I think it's open only to partners if I'm not mistaken, but it is the art of like analyzing and assessing a platform stack for a company. So mapping all the process, mapping everyone that is involved in that process and every technology, every technology that is used in that process. So the tree, I will say the triple er of what we call revops, so people platform and process and mapping all those process and the people that are used that are involved in the process and the tool they use to make the process flow will give you an understanding of what you're trying to achieve or build. And it will also surface everything that doesn't make sense. Where there's manual work, where there's that can be automated, obviously, because that's not everything that can be automated. And so it's like is very mapping of all of that so we can decide what we'll be doing in each system like HubSpot but also every other system that you will plug with HubSpot because HubSpot is amazing, but it doesn't solve everything on earth. So yeah, so it's mapping all those things and decide whether we move this thing into HubSpot or we keep doing it outside of HubSpot or with an integration or maybe it's not relevant at all to integrate that with HubSpot because it doesn't make sense, for instance, to plug your HRMs with your CRM because it's not a clever thing to do in the situation of your business. So that's the goal of the platform consulting.

I love that. And Remington just touched on this a little bit when you were talking about consulting with all of those different teams and really how that might blow up the scope, at least relative to what the client was initially expecting. This is a question for anybody, but when you're in the process of doing this platform consulting initially, how do you know even who to involve? How do you get the right stakeholders in the room so you can really set them up for success?

You asked me or the.

Remington said that.

Sorry, but Remington earlier said that people are farting for the same real estate. But Mike Remington and me were not fighting for that. Real.

Nobody has to answer it if you don't want to.

I think it's pretty quickly. Once you get into an organization, you find out who thinks they have the power and who has the power and who's actually doing the work. And generally it's those people that you find have the insights because if you add a minute to their process and there's 30 of those a day, you make a big dent in the year. Conversely, if you can take 30 minutes a day out of their day. They're like, they're a friend for life. So I think it's really getting down to the people that use it, not just the managers and the people higher up the food chain. Yeah, they'll be making the decisions. But if you can align also for adoption, that helps. So if you've already got a connection and you've asked them, rolling out new software is much easier because you've talked to the team, you know their pain point and you can go, hey, I solved this for you. And they're just like, great. And so then they go to the rest of the team and it sort of ripples through. A tip that we use is we'll choose a champion and not give it to everybody so that that champion's sort of got a role and the rest of the people are going, when do we get it? And once you start that adoption's easy. Whereas if you go thou shalt enforce it to everybody, it's you'll get people resisting and arguing and no, it's wrong.

So I like that a lot. Sort of making it a scarce resource as opposed to like a authoritarian kind of law.

Yeah, if you break it with one person, then you only break it with one. You're not breaking it for 10 or 50 or 100 people at the same time.

Right. So it also minimizes your risk there. Cool. So this is another pretty high level question. What types of CRM development projects specifically have you been seeing the most demand for? This question for anybody. And what do you see as the biggest business opportunities for developers building on HubSpot today?

I'll jump in on some that we're doing. We're doing a lot of, we're doing a lot of kind of connecting HubSpot to HubSpot like the same portal and kind of extending functionality. So doing a lot of, you know, CRM build outs and implementations. But then we're, we're extending that with CMS and custom objects and that kind of thing for to enhance functionality. The new CRM developer tools are going to be amazing for that even further. So we're seeing a big need for that because these point solutions have defined processes for clients and getting them away from those point solutions. How they do that in HubSpot might be different and we can kind of mine the gap a little bit, but it's really important to kind of understand the trade offs. So that's been a huge flex essentially that we can do to kind of customize HubSpot to fit and Then the other ones are a lot of automation. So custom coded actions, serverless functions and that kind of thing in automating processes. So Mike mentioned something about saving someone 30 minutes, that same kind of thing. And it's almost the stuff that no one knows is there. Which is really the bad part about it is like you build this beautiful thing and everyone's like, oh, that just magically shows up there and it's like, yeah, it's not magic. Right. But ideally that's like, that's the nirvana we're looking for is that they feel like, oh yeah, just press this button and then that happens. And so a lot of that's the serverless functions and custom coded actions that we do.

Yeah, I could have said almost the same thing as Remington, but to add up just on the same thing, we're doing the same. We're extending the HubSpot CRM with the CMS and we also do a lot of custom automation. And yeah, just to give a few example of that, it's, you know, when something can be done in HubSpot, remove that T after can and can it can without the T be done in HubSpot. Because we as developers, we have a list of tools like API, like serverless, function, like custom code action to do what HubSpot can do. And for instance, we have a lot of customer coming to us for renewal management process process. There's no button anywhere in HubSpot in the interface where you can click on renewal management process. This is not a thing built in an HubSpot but you have pipeline, you have workflows, you have objects, you can build renewal process in HubSpot if you know how to do it. So instead of looking for third party and marketplace that will do that for you, you can build a piece of something in HubSpot that will do that for you. And it's the same for partner management or prm partner relationship management. You can build that on top of HubSpot without a third party. Just connect your HubSpot with your HubSpot in some ways. So with a custom object that you will build or a CMS portal that you will build behind a membership or private content, call it whatever you want. So yeah, just extend your op spot instead of plugging a new source of truth.

So yeah, yeah, I think for the customer having that reduced number of or less infrastructure basically. So back in 2016, you'd go through a workflow, you'd send it out to a server, would do a lot of work and push the information back and Then keep going. Whereas now with custom actions, sorry, custom code, we can bring that inside a workflow and less points of failure, better security, better quality, less stress for us, which means less stress for the customer. So that's really exciting. And one example that I got to geek out on recently is the CRM development is a game changer and we had a customer in the states where they the recruitment company and we were able to add a custom CRM panel in the middle with a candidate profile. So it showed all the details and that was pulling from custom objects, it was pulling from properties, was doing data manipulation and formatting. It wasn't that easy. It was amazing. And to be able to like working with a customer at site, that's what we want. That's what they'd ask for. They'd seen HubSpot, they could see it working and then to go, what if we did this? And just like they're so excited and it just made it so easy for the team because before they were jumping from system to system to system and then back again and yeah, game changer.

It's really interesting to hear all of your responses. It sounds like the sort of unifying theme is really or one of them is really efficiency and just increasing efficiency for your users and for the customers. That makes a lot of sense given what you were all saying about this sort of like endless expansion of tech stacks and of point solutions. There's a lot to process when you first start on HubSpot. As I think Steph mentioned this earlier in her keynote that a lot of the partners who have been really successful, certainly including all of you all have a really in depth, really deep knowledge of HubSpot specifically and all the tools and the capabilities. For anyone in the audience who might be newer to HubSpot, what advice do you have to somebody just getting started. How would you recommend that they onboard and get to know the platform and its capabilities?

Go ahead, Michael. I go, yeah. So yeah, I will just recommend to be curious, very, very curious and get involved in the developer community. There's a Slack group, there's the community itself, community.upspot.com, there's like threads in that community for developers. Read the doc, but read it like for real. And also yeah, do not hesitate to ask questions in the community and I'm looking forward to the disc a new community that we'll have. It will just add another channel to just asking questions. We have a very, very, very, very nice, dedicated community. I never asked a question in that community that never got an Answer. You will always get an answer and that's super helpful to getting start and be curious. It's the first thing, get to the community. It's the second thing. And the third thing is be cautious. Sorry if English is not my first language, but I think warning, you're doing fine. Yeah, because HubSpot is simple but complex. You can do a lot of things that is simple. The API is very straightforward. But you can mess up a big ecosystem. You do it. So yeah, so you start in test portal, sandbox and everything before going on production. Because there's maybe a bunch of, let's say dozens or hundreds of marketers, salesperson, customer service agent that will suffer if you mess up their portal. So yeah, so yeah, that will be my, my recommendation to people getting started.

Go ahead Mike.

I completely agree about staging servers. Development servers like it's a normal development workflow. So start off locally in your developer account. You can spin up 10 portals inside HubSpot at no charge. Beware, they are full enterprise with all the toys and your customer may not have all those toys in their toy box. So do just be wary of that. A good example is serverless functions. Not everybody's got access to serverless functions and get the customer in there and playing with it and using it. For me, because I'm a self taught developer, which causes me lots of pain, I'm build, break, build break, build break. So you can do three iterations of the same piece of code faster than you can do one and, and try and unscramble it three times. So try something out, do a little piece of functionality, test it and then shovel that into another project so that you've then got something to work with. You know it works, you know it's safe. I think over time we'll see a bit more maturity. With some of the tools available, it's come a long way. The other thing is the logs are your friend. They're not always in an intuitive place. But have a rummage, you'll see information there, you'll swear at it and then you'll start to read it and figure out what's going wrong. Because even if you fix that, you'll probably still need to handle that exception later because of bad data which is still going to be in HubSpot. You're still going to get bad data. We've got real humans on the end of HubSpot. So yeah, I got caught the other day with not trapping a variable goes into the code and it just, you get a, you get an error. So you will make mistakes. Yeah, get over it.

For. For the. One of the big things, you know, I've been doing, I've been a part of the community for a long time and I subscribe to the docs beyond just like when HubSpot pushes them, but for actual changes in the developer documentation because that's a huge thing to be able to see that. And I'm like ultra nerd. So I actually always take a look, usually weekly I'm taking a look at the developer info on a page to see all the data structures and how they're presenting on cms. And I do a lot of the same thing looking in the APIs because when there are changes like V3 to V4, they could be very, very tiny changes that you can miss, but they could have very large impacts in how the rest of the stuff down the line are built. So it's your job as a developer to make sure you understand what those nuances are before you jump in. I'd say get in and start building. Start trying to break stuff. If you're not trying to break what you build, then you haven't done enough building yet to. To make it work. But yeah, just get your hands dirty. Jump in. Both hands, both feet.

I love that. That's such good advice from all of you. Thank you. This is sort of a similar question but even as. And you all touched on this a little bit. But of course even as very experienced HubSpot developers, you're all continuing to grow and learn what are your best sources for inspiration and education ongoing as a HubSpot developer.

I can go in. Yeah. So community documentation Remington Add that it's very important to subscribe to newsletter or whatever to have like the official when they are sunsets or new APIs or whatever that are available. But it is also a good thing to be like developer developing stuff on HubSpot. It's cool. But HubSpot is a thing. It's also a thing outside of the code. So subscribe to the other news about HubSpot for the non coders because this is for them that you will build stuff and you need to see what the tools they are using looks like and how they are using it. Because at some point if you want to extend what they are already using, you need to understand what they use. And you will also probably avoid to build something that is already available in HubSpot because we get a lot of that. A developer who's passing hours to solve something. And I'm like, you can do that in a Workflow, it takes three clicks. Sorry about that, Paul, but that's the reality, so. Yeah. So being aware that what HubSpot can do without any code or low code is very, very important. So you won't waste time building code stuff that is totally useless.

Yeah. To extend what Lewis was saying, talk yourself out of a project, you may be able to do it without using HubSpot at all. You may be able to, as you say, do a workflow and solve a problem. If you have to go to development, that should be your last resort, not your first resort. Yeah. Solving for the customer means that. So for me, that inspiration is the customer. It's their organization. So how can I improve the efficiency of something? And that may be changing their business process, not their HubSpot process. How can I save time for someone? Because every mundane job we take away from them, that means they're now able to do proactive jobs. And we've all got proactive things we want to do. So how do we enable an organization? It's really exciting looking at that and going, wow, if I could do some code and knock out that piece of the process, then that's a great solution. Go build it. If you're going, oh, it'd be cool to do this, but they haven't asked for it, then really, you're better off to go and build something for yourself or solve somebody else's problem. So inspiration for me comes from that customer.

I've got nothing to add on this one.

Great. Let's see. We got a few more minutes here. I think I'm going to jump to this one just because I think I'd love to hear all your thoughts on this, but is there anything about building on or using HubSpot's APIs that you just really wish you'd known earlier? And if so, what is that thing or things?

Postman.

Yeah, Postman. Postman's good for me. I think it's a lot around limitations, like understanding how many API calls you can do, which portals have what features. I've seen a lot of times people get stuck and like built this great solution for HubSpot and then only realizing the client doesn't have that hub. And so that can. Like, that's not a real great place to be after you've invested the time and then the client has to invest additional funds. So it's always better to do that up front. But the. A big. I think a big thing is understanding, like, what the ceiling is and whether it's a hard ceiling or a soft ceiling. For me is like going to like, object limits, for instance, and understanding those types of things. Association limits, like just knowing what you got going on. I saw someone said that HubSpot API keys being depreciated. Yeah, that kind of thing. Like you've got to plan for that and understand it, but just trying to keep. Keep that stuff in track. And then. And then again, understanding what happens before your API calls or adjustments or the things you're doing, and also what happens after. Because if you make a change here, you can affect things on both sides.

For me, one of the big things, when you're writing code, you're in the development, everything's in your head. Document it. Not a new code, somewhere where humans can read it and understand what's going on. And write those notes first as if you're writing it for yourself in the future. Because you will come back and you will be going, who did what? And then you realize it's yourself. So you'll save a lot of heartache because when you're writing that code, it's all fresh in your head. You know why you did it. When you come back and read your code later, you'll be just like, why did I? Who did what? Yeah, so there's git blame. Zach's mentioning. Get blame. Yeah, you can make it public if you want, but private.

Lou, do you have anything, Louis, do you have anything to add on to that one?

No, just that since I learned how to code just to code on HubSpot API, the thing that I want to know earlier is coding, but, yeah, that's it.

Gotcha. Okay, and then maybe the last question that we have here, if there's any more in the. In the comments here, I'll peruse through that in a second. But we've heard a lot from our developer community that. And again, I think Steph at least mentioned this in her keynote earlier, but just hiring is really hard. Hiring people to build on HubSpot or just at all developers specifically. Do you have any tips for anyone looking to hire developers to build on the HubSpot CRM.

Can go. Or maybe Remington. I don't mind.

All right, I'll go.

Yeah.

Yeah, I think so. One of the biggest things over the years that has been helpful is if you're out helping other developers in the community when they're looking for a job, they're going to go find you to see if you're. If they can come work for you. So the more helpful you are and the more you know, the more that a developer respects and looks at you as an organization or as a, as a person. Like you've got a much higher opportunity to have people come and want to be a part of the team. On the flip side, developers are very sought after in general, but HubSpot developers and it's, it's hard to, sometimes it's hard to remember that we're in a HubSpot bubble and there's a lot outside and so like yes, ideally to get someone up and going it's best to have a someone that's proficient, understands HubSpot. But the, you're gonna pay for that one way or another. And so you know, you've gotta be able to make that expectation of, you know, trying to hire early, trying to make it, make a training program, make trying to get them in, don't close people off because they don't have HubSpot experience if they're really strong developers in other areas.

Can you say a little bit more about that? Remington, you said you're going to pay for that in one way or another.

Yeah. So I mean everyone's going. I get recruiters all the time that are reaching out to team members and asking me if I know any developers that are looking for a job that are working with HubSpot and it's very cutthroat there. For the record, we don't use recruiters like if you want a job you have to ask us or apply. But the, you know, the ecosystem right now, especially with how technical hubspots go on technical stuff but like they would definitely widen the technical side of the port of the hubs. That's, that's increasing people that never thought they were going to hire a developer in the first place to start saying oh we need one and of course, what do they want? They want a developer with 35 years experience in HubSpot which doesn't exist but you know, it's, that's kind of where everyone goes for and it's easy to miss really brilliant folks that might be really great WordPress developers that arguably probably hate WordPress and are looking for an alternative. And so when you throw Those must have 35 years HubSpot experience, you're missing out on a lot of potential opportunity to bring in really great folks that can help you build. Amazing. Thanks.

Yeah, I think you need to find someone on a matrix of curiosity and I will say commitment because you know, you need a developer that will be very curious to learn new things always. But a developer who's just curious but not able to commit is always like changing his tech stack. He will do his first project on WordPress, the second on Shopify and then the other one on CraftCMS and then. And he's not able able to commit to learn a platform and be becoming the expert of that one platform. He wants to be the expert of everything and this doesn't exist an expert of everything. So you need to find someone that is curious and is able to commit to learning to use his curiosity inside of the HubSpot ecosystem. And I think the people at HubSpot are with the developer community and everything are doing a really great work to make HubSpot sexy for developers. It was not very appealing for developers five years ago. Every developer wanted to keep coding on their platform. They were using whatever that was. But now developers are starting to getting all HubSpot is cool and is very nice to develop. So yeah, I think that if you find the person with the right amount of curiosity and commitment, you'll find a good developer.

I think for me communication is really important. A developer that's good at communicating will outperform a developer with superior development skills if they can't communicate. And I've hired some people way smarter, way better at code than me. But if you can't help them to get a good outcome or work with them or work within a team, then you're going to pay a lot of money and they're going to make really expensive mistakes and sometimes you won't even know. So communication is key and without being stereotypical, that can be counterintuitive. But if they can't hold a conversation and talk about a project, then you're doomed.

Sorry.

Yeah, that sort of ties in with what you were saying about documentation earlier. Also, I think we're out of time here. I just want to thank you all so much for taking the time to be a part of this panel. This was wonderful for me to chat with you all. Hope it was useful for the audience here as well.

Way smarter, way better at code than me. But if you can't help them to get a good outcome or work with them or work within a team, then you're going to pay a lot of money and they're going to make really expensive mistakes and sometimes you won't even know. So communication is key and without being stereotypical, that can be counterintuitive. But if they can't hold a conversation and talk about a project, then you're doomed.

Sorry.

Yeah, that sort of ties in with what you were saying about documentation earlier. Also, I think we're out of time here. I just want to thank you all so much for taking the time to be a part of this panel. This was wonderful for me to chat with you all. Hope it was useful for the audience here as well.