Starting a SaaS company within an agency and scaling it to millions in ARR – with Kyle Racki from Proposify

Product Stories

Starting a SaaS company within an agency and scaling it to millions in ARR – with Kyle Racki from Proposify

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 / 00:37:47

Apple Podcasts Google Podcasts Spotify Stitcher

RSS Feed

Share

Link

Embed

Video

Summary

Listen to how Kyle Racki and his co-founders have built a 100-person SaaS business from within an agency. Proposify is a proposal software that allows you to create sales proposals and streamline your entire sales process.

Find out how they come up with the product, validated it, and how they separated resources from ongoing client projects. Learn how he’s managing a 50-person product team, and why they have just completely removed roadmaps from their development process.

Another video you might like

Building a SaaS now vs. 20 years ago

Episode

Victor [00:00]

Welcome to Product Stories where we explore how founders build successful software products. This is a podcast about product management, development, remote work, and everything else non-technical as well as technical founders need to know to launch and scale software products. Today’s guest is Kyle Racki co-founder of Proposify who started his product within his marketing agency quite a while ago, already and grew it to a SaaS company of almost 100 people now. Welcome to the show. Kyle, great to have you.

Kyle Racki [00:31]

Hey, Victor, thanks for having me.

Victor [00:33]

So, 95 people, that’s a LinkedIn account, but not everybody has LinkedIn. Have you passed 100 people yet?

Kyle Racki [00:41]

That’s a good question. I have to check our HR software and see where we’re at. But I believe it’s around the 100% mark. If you count, we’ve got a few Co-Op students too. So, I think we’re around there.

Victor [00:52]

Nice. That’s a pretty big mark. Would you like to tell everybody a bit about the product, and what it does?

Kyle Racki [01:01]

Absolutely. So, it started as essentially scratching my own itch with proposals and working in agencies where you want your proposal to look fantastic. But the actual process of getting proposals made efficiently and quickly, is really painful and really disorganized. So, it’s kind of started there. And where we’re now, as a company is: Proposify helps sales leaders in scaling, sales teams, essentially get control over their closing process. So, a lot of teams will have CRM and sophisticated upfront sales and marketing tools and lead gen and lead qualification tools. But often, when you get kind of to the end of a sales cycle, there’s not a whole lot of process often. 

And we often find a sales rep are kind of doing their own thing sending their own PowerPoint, or PDF or Word docs to essentially put contracts or proposals in front of clients. And so, the sales leaders have very little visibility into what’s going on, often brand standards aren’t being met, or there’s out of date content, or the pricing is wrong, or they’re using a term, they’re updating terms, they’re not really allowed to sort of present to the customer. So, this lack of control, lack of consistency is essentially what Proposify solves.

Victor [02:20]

So, understand right now, the target audience is more professional sales teams, right? Did that start this way in the early days?

Kyle Racki [02:29]

It started with small agencies really, because that was the market that we knew that we came from, so we knew them well. And you and I actually met on our first podcast that we put together called Agencies Drinking Beer, which was fun to do for a while. But then as the company grew, I think we realized that there’s a much bigger opportunity when you move up market into kind of the mid-market and enterprise. And that’s where there’s a lot of pain, and not a whole lot of innovation happening currently. So, we’ve been pivoting for the last several years to move up market and to sell to those bigger teams, where there’s more pain, and where there’s more steady, consistent use of a product like this versus sort of the sporadic usage of very small customers.

Victor [03:18]

And that makes sense. And that’s how you evolve into a bigger company, I guess. But at the beginning, as you said it was scratching your own itch. So, you were running an agency back in the days, as I remember, and you wanted to solve that problem for yourself, how did you decide to actually build something in-house?

Kyle Racki [03:42]

It was a really long, slow process to actually get the product made. I think I had the idea as far back as around 2006 when I was still even employed at an agency before I even went out and started my own. So, I had in my basement one night just kind of for fun thought about it’d be cool to have like a proposal tool, sort of like a base camp but for proposals. That was where I started, that was the idea. And I wanted all the functionality of like design for making the proposal look right and not just be kind of a Word document or a quote. 

So, I mocked up like what a wireframe of the app could look like. But I sat on that for quite a few years, started my agency, a lot of learnings and lessons in business just from doing that. But then as we got about four or five years into the company, my co-founder and I really wanted to migrate towards products. And we had tried a few ideas for SaaS. Proposal software was kind of one of the ideas in the mix that we tried out. But as we actually got out and started verifying the pain in the market and showing it to people we found that it resonated strongly. There was a huge need for this type of product. And so that gave us the first evidence that maybe this is an idea we should pursue. And then over the course of several years, we got some funding to hire a developer in-house to start building out the product and then eventually migrated away from the agency and sold it off. 

Victor [05:17]

So, you actually went out for funding, that wasn’t a cash flow thing from within the agency. How many people do that? I think that they just set aside a few developer hours from their existing projects, or whenever a developer idle, they will use them, which often results in the product never getting done, essentially, right? So, you really went all in. You got funding, and you separated that pretty early on? Is that correct?

Kyle Racki [05:52]

Yeah, we had fallen into that trap ourselves. But I had heard other lessons about that. And so, I was pretty aware that that was a risk to this product ever getting. Because you’re right if you just leave it and you treat it like a project in your agency and have developers work on it sporadically. Looking back 10 years later, without a product still and just wondering, where it is. 

For us, we had to have a developer that was hired specifically for this product. And that developer was essentially not working on any client work. He was completely separate from the agency. And that was how we were able to get it off the ground. Now, if we were a more profitable agency, we would have been able to just self-fund this. But thankfully, where we live, there happened to be government programs, grant programs that we were able to tap into to help cover the cost or at least some of the cost of the developer.

Victor [06:53]

That’s interesting. And how did you decide on the early MVP feature set? Was that also scratch your own itch or was there any customer or early customer development insight?

Kyle Racki [07:05]

I didn’t approach customer development the way I would today, but essentially, we showed the solution. And we showed kind of the prototype to a couple agencies around town. The product had a landing page, I started with that. And then the developer that we hired was able to come in. And within about three months, he had a MVP ready to start bringing customers into and using it. And it was terrible. It was a very early stage, very rudimentary, but it was a that starting point, this would have been around April 2013, to just invite some people in, have them tinker around, most of them left immediately and never used it. And then it was probing and asking why and trying to figure it out. 

So, it took about probably a year and a half  of just constantly iterating and talking to customers pushing updates, talking to customers. And that whole process was about a year and a half before we started to really find some traction, and people were really enjoying what we were building.

Victor [08:21]

That’s super interesting. And how did you continue developing that? When you saw some more traction, some more users signing up? Did that already become profitable or did you seek more funding? How did you scale from there? Because product market fit doesn’t always mean, we have enough money to build that entire deputy, right?

Kyle Racki [08:43]

Yeah, we were able to raise a seed fund in around May 2014. We raised 250,000, from a local VC called a Nova Corp. So, they were able to sort of give us a cushion on that runway, where Kevin and I could step out of the agency afford to live essentially. With Jonathan, our developer, we were able to hire one more developer. And that gave us that little bit of runway to just keep going with what we had. We had about 10 or so paying customers when we raised the money. No serious MRR happening but the investor believed in the problem, we were ready to execute on it. 

So, it probably took about maybe four months longer after we raised the money until we actually started to really see that uptick in not only customers signing up, which was never a problem. It wasn’t hard to get people into a trial. It was always hard to get people to use it and then pay at the end of their trial. And we started to crack that around October.

Victor [09:55]

And moving forward, you see that massive uptake you start scaling, you start growing, people start paying and sticking around. Fast forward to today, what’s your team setup now? How many people are in product? How big is that entire department to speak?

Kyle Racki [10:21]

So, we have currently four product teams or squads we call them. And then outside of that we have directors of engineering, DevOps, managers, that kind of thing. So, all in all, we’ve got probably about 40 to 50 people in product Dev, QA, and the support roles around that DevOps and so forth. That’s how it’s set up today. And then essentially, those four product teams would involve Product Manager designer, about five engineers and QA. And those are the teams that go and sort of solve specific verticals within the product like integrations or the document editor.

Victor [11:00]

So, they’re very focused on certain parts of the application, or does that change around?

Kyle Racki [11:06]

Yeah, I mean, this is always changing, whatever process we have today, it’s probably going to change in two months to something different. So, we’re just always evolving it. But as it stands today, we aim to have a broad context and understanding of how customers use the product, so that there isn’t just, you know, a team that’s in a silo and all they know with one part of the app and nothing else. But generally speaking, a team that’s focused on integrations is going to have more bench strength around back end stuff and API, whereas the team who’s in the editor doing more front-end type of stuff, they’re going to be stronger in JavaScript and all the other sort of more front-end technologies.

Victor [11:51]

And where are you guys located? Are you all in-house?

Kyle Racki [11:56]

We aren’t. We are mostly based out of Halifax, Nova Scotia here on the east coast of Canada. But over the last couple years, and especially it’s been accelerated with COVID, we’ve been expanding. But a year ago, we hired our first true international hire Andre, he’s based in the Philippines, and he’s our customer success, one of our customer success representatives who’s able to sort of tackle the time zones on the other side of the world, especially our Australian customer base. And then ever since then, we’ve been hiring some people out of the US, some people out of Brazil, actually. We’ve got a few people spread out.

Victor [12:36]

That’s interesting. How is your experience here? You’ve been around for a while and you said a year ago, you’ve hired your first international hire. What was your experience? Have you ever worked with remote people before or external service providers? What was your experience here?

Kyle Racki [12:57]

Yeah, I mean, over the course of 10 or 13 years, or however long I was in the sort of design and tech business. Yeah, we’ve worked with contractors overseas, we’ve worked with you and on getting some help, I think when we were looking at different product initiatives, mobile and experimenting with different parts of the product. So, we’ve always had that. I mean, it’s a little bit different, though hiring like a contractor and hiring somebody who’s at least treated if not technically on paper, in the cultural aspect, they’re treated like an in-house employee, they’re on a team, they have one on ones and all that kind of thing. 

So yeah, that’s what I think we’re fairly new to. I mean, a couple years ago, we did actually have a sales rep out of the US. I didn’t really count that as an international hire because we sort of, we tend to think of Canada in the US as being pretty well the same thing. It doesn’t feel international. But yeah, like the first, really far away hire was Andre over in the Philippines.

Victor [13:56]

Interesting, and what do you think with COVID, everybody’s working from home right now?

Kyle Racki [14:07]

Well, yeah, we are actually all working from home. We have an office here in Halifax, so people are still free to use it. We actually don’t have too many cases here in Nova Scotia. We’re one of the safest places currently in the world from COVID. I think it was a New York Times article recently that listed Nova Scotia is the safest place in North America or something like that. We just have very few cases, we were down to zero for many months in all and then we sort of had a bit of an uptick, but we’re still around 20 or so active cases in the whole province. 

So, with that we have office people working from home but we’re able to have if your team needs to have an offsite or if the executive team meets to sort of go over quarterly plans or something we do hang out in the office. I would definitely say COVID accelerated the remote hiring because prior to that, we had actually established a pretty interesting recruitment channel out of Brazil. We had hired about six or so talented engineers who came up from Sao Paulo and we were actually able to use a government program to fast track their immigration. So, they’re all living here. Because a lot of them wanted to get out of the country that they were living in. 

And we were sort of on track for that, but then COVID hit so then the people that we wanted to hire down there, we just couldn’t get them up here. So, some are working out of Brazil temporarily until we’re able to get them over here. And then, you know, as it happened, we just ended up hiring some developers who were you know, one is in Mexico, one in coupler in the US, and, and there’s no plans for them to move here.

Victor [15:52]

Got it? Would you say that everybody or most people working from home kind of enabled that situation? Or would you say, it’s just as easy if everybody was in office with a few people scattered around?

Kyle Racki [16:07]

You know, I personally think remote has pros and cons. And the feeling and the collaboration of people sitting around physically, you know, a table with their laptops, working on a shared challenge or problem, having a whiteboard to just quickly discuss and brainstorm ideas. I think we use technology to try to get as close to that as possible. We have zoom, we have Slack, we have digital whiteboards, but it never really replaces the in person feel. So, I think the pros of remote, obviously, is that you can open up your talent pool, and talented people from anywhere in the world can work for your company. What you give away is that really close collaborative aspect of work, And I think we’re still like, probably a lot of people trying to figure out how to get better at that.

Victor [17:05]

Yeah, there are very interesting companies who really succeeded like “37 signals”, which is a classic, of course, although they’re smaller than you guys to be fair right there. I think, just about less than 50 people I believe. But then again, it is like 1200 people who are fully remote, which is insane.

Kyle Racki [17:31]

Yeah, it can definitely be done. And I think even 37 signals, they still do some in-person stuff, I believe they still should have an office in Chicago for meetings. Also, they’ve always been a bit of a rare unicorn on their own ride, they’re very much like anti-growth and anti-moving fast. They’re all kind of like, take your time, everybody just hires smart people who want to work alone and don’t need a whole bunch of management and talking and collaboration and all that. So that works for them. I don’t think that works for most companies.

Victor [18:09]

Yeah, I would agree. Everybody needs to find their own pace here. Moving on to more of the product development side how it’s currently happening. And I know you have a great product manager, Ricky. Is he head of product?

Kyle Racki [18:30]

He is Senior Product Manager.

Victor [18:30]

Yeah, senior product manager because he’s the person that I know within your company. How do you decide which features to build? Because I assume at that stage, everybody has an idea. And every customer is submitting requests. And there’s probably a lot of features to choose from.

Kyle Racki 

Yeah, this really interesting topic and a lot we can talk about. You know, the actual team structure in the way we have it now where there’s a PM in every squad, so we have 4 PMs, with Ricky being the most senior. That’s the way it’s set up. And the way that we’re tackling the roadmap. I think roadmap is a general, interesting topic on its own. 

We’ve made a recent decision to essentially kill the roadmap. And that initially sounds quite scary to most people, especially sales and customer success and marketing, who always want to have this Gantt chart somewhere that shows you what when all the features are going to launch. But the decision to essentially kill that mindset of roadmaps came from reading the book inspired by Marty Kagan, which is a huge book recommendation for those who want to know how fast-moving product teams operate at scale. It’s got a lot of great tips in there. 

And so, the idea is essentially that what we’ve migrated towards is OKRs. So, for those who aren’t familiar objectives and key results where you kind of focus on outcomes versus output. And then individual teams set their own outcomes, their own objectives. And then the key results are how you measure that objective. How do you know you’ve gotten there. It’s a very different way of thinking, because most teams and most companies focus on output, management gets together and decides what features are most important. They feed it down to the teams and then the teams are expected to just take their tasks and get them done. The OKR model is very interesting and very kind of a mix between top down and bottom up. 

So, we’ve migrated to that, and now that teams have their OKRs set. The OKRs are essentially what customer problems they’re aiming to solve. And all that is based on the target market that we’re going after. And if we flip that mindset and go after talking about customer problems and business outcomes, then the feature really is not… You know, we don’t need a roadmap to tell people what feature is going to launch when, because “Hey, it’s going to be wrong”. Whatever we put down, whatever date we put down is going to be a lie. We’re basically just throwing darts at the wall and praying that we hit them. It gives the people from outside the product team some perspective into. Let’s just say “Okay, we know there’s this team over here and they’re solving this customer problem”. It’s around trust and reliability in the editor. 

So now we don’t necessarily need to say “Well, okay, well, there’s a thing about page flow. And there’s a thing about pricing tables or whatever feature set is within that editor”. We know that at the end of the quarter, this team wants to make the editor more reliable, and trustworthy. As they get in and they start experimenting and running discovery and testing prototypes, they’re going to find what are the right features to build, what are the right usability improvements to make. So, at the end of the quarter, they can say, “Okay, we’ve achieved a measurable improvement to this outcome”.

Victor [22:00]

And that makes sense, because in the end, what counts is not the feature. What counts is that customer problem being solved.

Kyle Racki [22:13]

I’ll just add that in order for that to work, the product managers have to be very closely in touch with customers, because they’re just guessing, or they’re just relying on sales or customer success to tell them about customer problems, there’s always going to be divide that layer in between that interpretation or bias. The only way for this to work is that the product teams are deeply engaged with customers, especially their target customer, their ICP’s. And they’re able to show them ideas in the early stages and ask about their problems and ask about their current workarounds and deeply understand it, because then when they’ve tested their prototypes of their ideas, and they’ve gotten them to a delivery stage. Then they’re able to say “Okay, we’ve achieved this measurable outcome.” 

Now, sales don’t care, as long as their deals aren’t being blocked. Sales really don’t care what feature gets built. But oftentimes, they resort to telling product what to build, because they feel like their deals keep getting disqualified because of lack of features. If their deals aren’t getting disqualified, if their pipelines are being opened up, they’re happy.

Victor [23:22]

And that’s a great point, especially on the product managers being in touch with customers, how do you ensure that on scale? What process do you have internally?

Kyle Racki [23:33]

There’s a lot of tactical things that you can do. I’d say like the first thing is you have to make sure that customer success and product have a good relationship and they trust each other because if they don’t; customer success can get very possessive over their relationships, especially the larger customers. They want to make sure that product isn’t getting in there and sort of maybe taking an at-risk account and making it worse. So, you have to open up those lines of communications. But from a tactical level, there’s a few things that we’re trying. And we’re actually in the process now of moving over NPS survey follow ups from CSM to product managers. 

So, the idea, we now have a shared calendar for the product managers. So, when somebody especially the target segment that we’re focusing on as a customer base, when they fill out an NPS, and it’s less than glowing, it’s less than eight, let’s say… They’ll actually get an email inviting them to a call with a product manager to talk through how we can make the product better. And they’ll just have a link to the shared calendar. So then, the idea is that your product managers show up on Monday morning and they see their slots are already filled with customer calls. That just ensures that they’re regularly talking to customers across the broad spectrum of the product. And then as they dig into, say a specific problem they’re trying to solve they can go into Gainsight, Salesforce all the tools that we use that have tags and sort of conversations linked. And they can read through those conversations and reach out to specific customers who maybe have talked about this one problem before and invite them to have a call.

Victor [25:17]

Do you use any specific in-product analytics tools?

Kyle Racki [25:22]

We use a number of them, primarily segment is what’s used. And then there’s different tools like Mode and others, on which we can run different types of reports on. I’d say probably the most useful is Gainsight and PX currently, because then that gives us the really the one central place for product managers to go. So, they can see not only the conversations between the CSM and the account, but also like, what is their NPS? And what is their MRR group? What kind of features are they using? What do they have turned on in their account? All that information is in Gainsight.

Victor [26:01]

And that’s very interesting. So, as I understand the development process or the overall decision-making process is from setting objectives and key results within the teams. They themselves understand how to tackle that problem and reach that goal. And if you move one level lower into actual tasks, at that point, you do get into concrete features and issues. Do you do work in sprints?

Kyle Racki [26:37]

Yeah, exactly. So, the actual development process is agile. And I think, it’s always debatable how agile but I think the goal is to get as agile as possible. So that you’ve got your sprint planning your retros, your sprint goals. You know, there’s daily stand ups with the Scrum Master, all that kind of stuff is in place. But essentially, on the product side, they’re living most of their time in discovery mode. So, they’re kind of always talking to customers, always showing them ideas, always validating assumptions involving their team in those conversations, inviting them to the calls and whatnot. But then essentially, when it’s ready to build like, okay, we’ve taken this thing, we understand the customer problem, we know they’re going to buy it, or they value the solution. We know there’s no serious risks to the business that helpers feel comfortable about the technical approach. They’ve maybe validated some technical uncertainties upfront. 

We’ve actually even tested the prototype. So, we know customers can figure it out. It’s user friendly. Well, then at that point is ready for delivery mode, where it’s like sprint planning, how are we going? What’s the end goal look like? But then what are the Sprint’s along the way, where we’re going to measure something small contained to production. Make sure that it plays well with the other code. So that it’s stable on the release. 

Victor [28:04]

And you mentioned prototypes to test before you even develop, what do you use for prototyping? How do you do those?

Kyle Racki [28:14]

You know, it’s a really interesting question. We’ve been talking about this lately is that prototype can mean many different things. And everybody has their own interpretation, the way I like to think about it is like prototypes is your tool belt, and you’ve got many different tools in there. And it’s about kind of picking the right one for the job. 

So, if you’re really concerned at the moment with just like, hey, do customers even care about this thing that we’re trying to build? You know, your prototype could be a keynote, it could be a sketch on paper, it could be a wireframe… Invision has that freehand tool. Lots of different ways to just get some sketched boxes in front of a customer to just say, like, this is what we’re thinking, do you think we’re on the right track? Would you use this thing? But then when you get into like usability, then you probably want a clickable prototype using Invision or Marvel which all the cool kids are using I guess now. But then you can also get into technical prototypes. 

So those ones obviously take longer to build and you want to be judicious about how you use development resources. But if the developers are like, “Look, we’ve never even looked at this type of technology before. We’re not good. Don’t ask us for story points or t-shirt sizes. We have no idea what we’re even building”. Then take a couple of days and just throw away code. This isn’t an actual production ready product we’re trying to build. We’re just trying to validate assumptions and see how it works so that the developers can go “Okay, we went down a few roads that were like false starts, but I think we have a pretty clear idea”. So there are tons of different tool for the job

Victor [30:01]

Maybe even as a proof of concept once you put developers on it, right, is that like, what kind of roadblocks do we have on the technical side is probably where you would throw developers at a prototype, an API you’ve never integrated before or technology you’ve never used, right? That’s probably the best use of their time here.

Kyle Racki [30:25]

Well and also architecture panel, that’s something that I’ve got established within the last 12 months is our engineering team has an architecture panel. So, if there is something if there’s an idea that we want to test out the engineer on the team can look at it and say “This has major implications to our whole how we build things, I’m going to take this to the panel”.  And there’s that process in place so that the engineering panel or the architecture panel can look at it and come up with a proposed approach to how to actually build the underlying architecture behind it. So that’s one of the ways to do that.

Victor [31:01]

Do you have something like that for design as well? How’d you decide on the actual UI design or is it not that important? Because at that point, you already have the wireframes and everything figured out? And you have a brand guide of course, or how does that play in there?

Kyle Racki [31:22]

Well, the designer on the squad would primarily be tasked with coming up with a visual solution to the problem. So, in most cases, you can leave it to the squad to figure out how that design is going to work. And the designer is going to collaborate and work with other designers across the squad to sort of show them ideas and get feedback and whatnot. But we are actually in the process of hiring a design director. That’s sort of the goal of that hire is that the person is going to come in and help establish that cohesive, higher level plan behind the product design.

Victor [31:58]

That makes sense. And now is the last question really, just out of interest to see what’s out there and what’s being used. What’s the tech stack behind your product?

Kyle Racki [32:12]

So, we are still on PHP for the backend, we use CodeIgniter as the framework. And we use essentially JavaScript for most of the front end. There’s a custom written framework that was built for that. But yeah, I mean, other than that, it’s the typical kind of stuff, Bootstrap and jQuery for certain things we use. A lot of the work lately has been on the Salesforce side. So, we have a developer who writes in Java and builds within that Salesforce AppExchange sort of framework. But yeah, I think where the Dev team is going is more of like the API first approach. I think there’s probably plans to move out of CodeIgniter to something else. And I think the real future of where they want to take things is with microservices and have a very segmented architecture, but I’m sort of speaking out of turn now, because that’s not my domain of expertise.

Victor [33:13]

Of course. Since you’ve been around for 10 years now, and not many SaaS applications actually have had a product this long on the market. Do you feel feedback from the engineering team, that there’s something getting too old, or that some technologies are not up to date anymore, or even maybe, since we have a market that we have that some engineers don’t want to work on a 10-year-old codebase or anything like that?

Kyle Racki [33:46]

The way I’ve seen it evolve is that it’s almost kind of the mark of a more established senior engineering leader, like a VP or a CTO is that when developers are less experienced, I find them often wanting to go the route of rebuild, and retool, and especially use the latest greatest framework. But I think as you see, the more seasoned engineering leaders grow and emerge, it’s much more about iterative improvement. And we kind of liken it to rebuilding the foundation of the house while there’s a party going on and not interrupting the party because the last thing that anybody wants to do is tear down and rebuild from scratch and then deal with migrations, and we’ve been down those roads before, and we’ve made a lot of fumbles. But essentially, it always sounds great on paper. Oh, it’s just easier to start over again, with a whole new framework and like the world’s your oyster, you can do whatever you want. You’re not hampered by legacy but in practice, it always turns into a shit show.

Victor [34:48]

Awesome and on that note, what’s coming next for Proposify, what’s the next big thing?

Kyle Racki [34:57]

I think in terms of the product, where we’re getting with it is, we’re very focused around helping sales leaders and sales teams at SaaS, especially Sales Tech Companies. And to do that, we’re working towards building an extremely tight Salesforce integration with managed packages and other integrations with HubSpot primarily. And then the core web app is just going way more down the road of control and visibility into the sales process. 

There’s a really cool thing we’re experimenting with now, which hasn’t been announced but it’s essentially like a real time analytics engine so that you could actually watch a replay of somebody who’s reading your proposal. The people we’ve shown it to are pretty excited about. A lot of tools like our competitors and us ourselves will show you the sections that customers view and how long they’re on it, but being able to actually see a visual replay of their session, which is actually not even recording anyone’s screen. It’s just recreating it all from the data.

Victor [36:08]

It is like a hot jar for proposals. Nice. Awesome. So where can people find out more about you and connect?

Kyle Racki [36:19]

I’m fairly active on LinkedIn, if they look at Kyle Racki. R-A-C-K-I. They can connect with me on LinkedIn. Otherwise, the product is Proposify.com. 

Victor [36:31]

You have got .com lately, or it’s been a while already probably?

Kyle Racki [36:37]

A couple of years, maybe two or three years, we have the .com. I finally tracked down the owner and negotiated.

Victor [36:43]

Awesome. Well, thank you so much for being on here. I think there was a ton of useful tips and advice on scaling a company on the product side. Thanks for being on the show.

Kyle Racki [36:57]

My pleasure. Thanks for having me.