191 – Turning Agents into Software that Sells [Smarter!] with Zig.ai CEO Steve Ancheta

Experiencing Data with Brian T. O'Neill
Experiencing Data with Brian T. O'Neill
191 - Turning Agents into Software that Sells [Smarter!] with Zig.ai CEO Steve Ancheta
Loading
/
I'm talking with Steve Ancheta, CEO of Zig, a platform designed to free sales teams from repetitive, non-revenue-generating tasks. CRM and logistical tasks can consume up to 72% of the week of a sales team, but Zig’s AI agents handle them so reps can focus on closing deals. Unlike tools built for managers, Zig follows a rep-first design—simple, intuitive, and aligned with the motivation to sell more—while also creating an intelligence layer that preserves institutional knowledge and accelerates onboarding for new hires.

I wanted to chat with Steve about how he built a product that is both used—and worth paying for—with AI under the hood. Rather than relying on chat prompts, Zig surfaces prioritized tasks in panels and cards, integrates with CRMs and Slack, and builds confidence scores from user interactions.

Because Steve comes from the world of sales—and that’s the domain his product sits in—I wanted to explore his “problem clarity” and share that with you, since I often find data and technical founders to be more solution-oriented and lacking in this area. Steve was an open book with me, and I’m hoping other founders trying to turn analytical complexity into commercial clarity can see how Steve is using AI and agents to make data work for end users—and worth paying for.

Finally, I also challenge Steve to answer whether Zig.ai is a software company or a services company with a product behind the scenes—a question you might also ask yourself depending on your GTM model.

Highlights/ Skip to:

  • What is Zig.ai? (00:48)
  • When managers see the value of a product but end-users don’t—and how product leaders need to react (5:20)
  • What Zig’s UX is like and how it was designed (9:45)
  • The sales process and risks salespeople face when demoing Zig (16:12)
  • How Zig addressed their time-to-value challenge during the product experience (20:14)
  • How Zig found a problem people were willing to pay to solve (24:16)
  • We discuss whether an AI product company might be a services company with technology or a traditional software company (24:16)
  • The Invisible Intelligence Gap Steve has observed within Zig’s business space (AI and analytics-powered sales tooling) (27:57)
  • Why Steve isn’t worried about the major CRMs from building internal solutions to circumvent third-party tools like Zig (35:37)
  • Steve Ancheta’s advice for trying to bring sophisticated data products to market (39:26)

Links

Transcript:

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I have Steve Ancheta, the CEO of Zig. Welcome Steve.

Steve: Hey, how are you doing, Brian? Thanks for having me.

Brian: I’m good. So, I’m going to jump right into this. Zig, I’m going to give you my plain English description of what it is. I’d want to catch up the audience real quick on your company, before we kind of jump into the product world side of your business. But you’re a sales execution platform that removes basically administrative work from the salespeople that should be spending their time doing sales work, and gets rid of some of that admin work. So, you plug into existing CRM tools and things like this.

And then you’re also doing your pricing on outcomes. So, you’re pricing on the work that these agents—which are effectively invisible or working behind the scenes—based on the work that they’re doing, to get it off the plate of the actual salespeople. Is that basically it? So, it’s like a plugin for your CRM?

Steve: Yeah, no, correct. It’s definitely well within that and a lot more. I mean, it’s essentially infrastructure for sales organizations. That’s something that you know has been missed with sales tools. And so, plugging into the CRM creates the intelligence piece, but it definitely gives infrastructure to a department that historically doesn’t have really deep learning infrastructure historically.

Brian: Got it. And so, you’re selling into, like a VP of sales, or CRO, these are teams of under 100-ish, somewhere in that kind of space. Is the problem that they’re having that’s so burning that they’re willing to spend money on it is that their team—the salespeople, are spending too much time logging information and, like, drafting the emails and, like, doing all the kind of mechanics and not spending a lot of time on calls and things like that? Is that the thing that they want to offload?

Steve: Yeah, so it’s a couple problems, right? So, the first one is that it’s a known thing in sales that you get 80% of your revenue out of 20% of your sales force, right? And up until now, there was really no way to say what was holding back, you know, that other 60% of—I’m sorry, that other 80% of salespeople from performing at a high rate. And so, now with AI, it’s become possible to create that kind of ecosystem that allows you to really surface and allow them to move at a much quicker pace.

Part of that is offloading a lot of that administrative task, right, pushing that onto AI agents, which are very, very good at doing repetitive task to completion. And also, the second problem is when a salesperson leaves an organization, all of the knowledge that they’ve gained during that time leaves with them. So, creating that continuity through an intelligence layer is really important, so that when new salespeople come in, or new VPs of sales, or new CROs, there’s that continuity of data that allows the new folks to be able to execute at day one, as opposed to having that long cycled out, you know, six month ramp period.

Brian: Backing up for a second, a lot of these, like, AI and analytics tools, and when I talk to founders and things like this, it’s gotten so easy to build software now, [laugh] in part because of AI, so deciding what to build is becomes a bigger problem, and this means really understanding both the fiscal buyers’ problem, but also the end-users’. So, I’m curious if the thing that’s really even allowing you to have, like, the sales call that you just literally hopped off of to do this podcast a second ago, is that the labor of busy work, effectively, that makes that VP want to take your call in the first place? Or is it really, like, I have, you know, eight out of ten salespeople suck, and for whatever reason, I believe that your system is going to allow me to bring them up to the 20%. That feels more like a long-term—

Steve: Right.

Brian: Like later—a latent benefit that you don’t really realize until later. But what’s the leading one that you guys are dialed into?

Steve: No, you’re a hundred percent right. So, it is definitely the bogging down time, right? Because historically, sales organizations are like, when they’re missing numbers or missing projections, they’re like, let’s just throw more bodies at it. Let’s throw more human beings. It’s not always the right solve to that problem.

Sometimes if you can give the salespeople, you have the necessary—more than anything—the time right back in their day to be able to focus on generating revenue—I mean, the average sales person’s 72% of their week is spent on non-revenue generating tasks. So, that’s the first—kind of to your point—the first initial value there is that now we take on that 72% now, it gives them more time to focus on generating revenue. And it really gives you a judgment call of, do you need more bodies? Or was it the whole time that you just needed to give the bodies you had more time to do what they need to do?

Brian: Yeah, yeah. So, this gets into an interesting space that I’m very much thinking about and writing about a lot right now, which is this idea of when a fiscal buyer, like, a manager of a department can clearly see the value of this, it’s like, oh, I don’t need my team doing all this busy work and all this kind of stuff, so the machines can now handle a bunch of those tasks. The downside of this sometimes can be that you have now created a much harder job for the salespeople, which is, I can’t really hide behind busy work anymore. Now, I really have to deliver on the stuff I was hired to do because the machine’s now doing a lot of this. Well, I, you know, I was updating this, I could only do three calls because I had to log all the notes from last week and blah, blah, blah, and update the deal status and all this kind of stuff.

So, you can get in this position where the end-users are not necessarily incentivized or interested in using the software or dealing with it, even though the management sees the obvious value in this thing. That’s not always true. It’s not binary. There are some people that would love to just get rid of busy work and focus on the thing that they were really skilled and hired to do. I don’t think that’s always true, though, so I’m wondering if you’ve seen this at all, where you kind of like you make them more accountable now [laugh] in a way that maybe they weren’t asking for to begin with. Or maybe, I don’t know, maybe these people are just, like, “I love not having to do this work anymore.” Like, have you looked at that at all?

Steve: Yeah, so I’ll challenge that take a little bit and where I’ll challenge it is sales is a very difficult job, right? It’s not for the weak. So, you’re getting beat up on a daily basis. You do the job for one reason, usually, and it’s money, right? It’s a job that you can make more money than executives at companies, with very minimal background, right? There’s no college degree that you need that’ll get you into sales, there’s no certain type of background, right?

Sales, that, what I love about it is so unbiased around who can do the job, right? I’ve seen people go from being a waiter or a waitress at a restaurant, to becoming a salesperson and becoming a President’s Club winning salesperson within two years. Like it is an extremely level playing field. So, there’s not one salesperson in the world that likes to hide behind busy work because busy work doesn’t push that commission check forward. So, whatever gets them faster to commission.

Now, what you are saying, it does hold some weight there, where it’s like, there are some people who are able to hide behind you know, well, I had to do this, and I had to do that, so I wasn’t able to get there, but those people aren’t really in love with being salespeople. They see it as a job where it’s like, hey, I’m going to live off the base salary piece of it. And honestly, that’s not a true salesperson. That’s just somebody who’s in a sales role to kind of bide their time. And so, we definitely didn’t build for managers, right? We wanted to go very against that.

I felt like there were so many tools in the market that were very manager and stakeholder-friendly and very rep non-friendly, so we wanted to flip that on its head and say, hey, let’s build for the reps first. And obviously the stakeholders and the managers will get value out of that because of the output. But to your point, we didn’t build for the reps who would want to hide behind busy work either, I guess. So, it’s to your point, yeah, there is some weight to that, but you know, the incentive comes in the form of, if you’re able to generate more revenue, that means your commission check grows, right, and that means that you know your financial part of the job, which is really why you do sales, increases naturally.

So, that’s kind of in mind with what we built. And why we built not only what we built, but also the way we built it. We wanted to make something so easy to use that it wouldn’t change the way that a salesperson naturally works in their day to learn something new. So, we were very—and actually, to your point, the feedback that I just got from the sales calls I just got off of, he said, “You know what I love about this is the user experience.” He’s like, “It is so simple and comprehensive for me or any of my other salespeople on the team to pick up that there’s not these trainings we’re going to have to go to learn this process, using your product.” So, that’s really what we were aiming for when we started the building process.

Brian: Cool, yeah, and very good point too, about in this case, I think the incentives are really aligned. As you said, that the people working in the sales do tend to have high, high drive, and their salary is dependent on their work a lot more than, like, their value is very correlated to that, so that’s a good point. You kind of talked about user experience here. So, tell me a little bit about what is the user experience of a tool like this. It sounds like it’s more invisible, it’s running in the background, it’s automating tasks that normally a human would do, so effectively, is there no interface for this, and you’re just seeing the results of automation here, in terms of the, I don’t know, the logging in the CRM, or the emails already drafted and it’s ready to be edited and sent, or, like, tell me a little bit about how the experience is experienced, and how did you go about designing that experience?

Steve: So, this is the part that I love talking about and kind of the most exciting for me is, right now, I feel like there’s two very opposite sides of the… call it the go-to-market strategy tools that are out there, right? On one side of the playing field, you have traditional software. Traditional software is something that the normal, you know, average, non-technical sales person has become comfortable using, right? Albeit, some of them are a little too… there’s a little too much density to them that, you know, if there was less density, they would love it. But they’re comfortable in that, right? But the problem is that type of software can only do so much. Legacy software can only do so much in, kind of, the new AI world.

On the other side, which I’m sure you’re seeing it all over the place, there’s these conversations around, you know, using things like Claude to, you know, to handle certain tasks, or using certain models, right, being able to do that. The problem with that is you have to have enough of a technical acumen, as well as enough time to be able to make that work and then maintain it. So, you have to have almost like an pseudo-engineering kind of acumen to you to make that work long-term, you know, as you build that out.

What we did is we kind of met in the middle. So, what we did was we gave the functionality—because we’re AI at our core level—this is what I always tell customers when they ask about other competitors. I say, well, that competitor is a software company that has AI baked on top of it. We’re an AI company that has software baked on top of it. And what that means is we created a UI that looks very similar to a simplistic go-to-market software that a sales person can easily resonate with, but with all of the underlying functionalities that something like an OpenClaw would have, or like a Claude Cowork would have.

And this is kind of our thesis. So, we have three, kind of, pillars that we focus on. Number one is it should look like software that sales reps are comfortable working in. Number two, it should feel like—so the soul of the platform—should feel like what you hear OpenClaw does without having ever seen OpenClaw building it yourself because if you’ve done that, you know it’s not easy. And the final piece of it is that if it takes more than three clicks to get through to completion on something within the platform, we don’t ship it. We have to go back and readjust it to make sure that it’s three clicks or less.

Because even some of the most sophisticated software platforms that users are comfortable with using, sometimes it’s seven clicks before they get to where they want to go, and you end up getting that kind of fatigue working in the platform. So, there is a centralized UI, but to that point, we also connect to different tools and endpoints, like Slack, you know, like Teams, like WhatsApp, where you can control your Zig instance from, kind of, anywhere you work. But so far, the feedback that we’ve gotten is actually the unified UI has been a big hit with a lot of the companies that we’ve spoken to.

Brian: Got it. So just, I want to just help, since it’s an audio podcast, just for people to kind of imagine what this looks like. So, it sounds like there is a user interface, a cloud-based, I go to a URL to hit my Zig instance. Is this going to look something like a chat interface that’s actually talking to my CRMs and things like this? Or is this actually replacing my need to say, log into HubSpot or Salesforce?

Steve: Yes.

Brian: I don’t need to log in there because I just talked to Zig, and it handles doing the task in the background?

Steve: So, half of that is correct. So, you don’t essentially need to log into your CRM as an end-user, right? That’s the idea. It is not a chat interface. And the reason why it’s not a chat interface, it does have some chat interface abilities, like, if you’re trying to—think of it like an LLM—the chat interface piece only—think of it as an LLM that has a Chrome extension, right, where it pops up as a side panel, and then you’re able to say, you know, ‘Find me x,’ or ‘Tell me about y,’ But what actually happens is the agent takes control of the Zig screen, and simultaneously while summarizing, actually takes you there within the UI.

But the normal interface that you’re working in day-to-day is actually not chat-based at all. And the reason why we stood away from chat focus is because chat focus essentially works on input, right? So, the problem with that is a salesperson knows that they have a million things to take care of in a day. If you left it up to them every single time to say, ‘Okay, this is what I want to work on today,’ now you get them to have to overthink their day.

What we’ve done is we’ve essentially taken that back-end of what the agents are doing, and we’ve surfaced it in panels and cards that say, here’s what you need to focus on today, here’s what I have already completed for you, and here’s some things that are coming up, right? You click into those, the work is already done, and the user, all they have to do is review, edit, or approve, right? Or all three, however they want to look at it, right? So, they review, edit, approve, those are their options. Every time there’s an approval, every time there’s an edit, a readjustment, the system takes record of that, and it drops into their user base context layer.

So, it starts learning how the user gives it feedback, what type of emails it respond—lets the agent respond to without the user ever make it an edit, which things it likes to edit, what words it likes to use. It learns about that over time, and then it has an internal confidence score that’s exposed to the user. Once that confidence score hits a threshold, then it gives them the option to go into autopilot mode, similar to how Tesla is going to, you know, have the self-driving feature, but they don’t give the user self-driving from day one. They essentially learn from the habits before going into self-driving. It’s the same exact methodology here is, once it hits that confidence score, it gives you the option, hey, for these type of emails, or for these type of leads, or for this type of outreach, you’ve hit a confidence score to be able to go into autopilot. Would you like to do that? And then that task becomes a, here’s what I’ve done for you, not a, here’s approval that I need from you before I do this.

Brian: Got it. Is the risk, when you bring this product in for I’m assuming there’s a dem—your sales process at Zig as some sort of demo of this to a VP or CRO, something like that, and then maybe the staff get a chance to look at it as well, something along those lines?

Steve: Yep, and then we go into, usually with an organization, we’ll go into a proof of value as well, proof of value period where they’re actually able to use it. We embed the agents into their workflows, we connect to their, you know, their CRM, things like that, create their context layer, and then they’re able to actually use it for a period of time before becoming a fully committed customer.

Brian: Right. Maybe in this case, the risk feels very low, but I’m curious about, did something have to be true in terms of the user interface of the experience that you had to kind of get over a hurdle before people both saw the value but also understood the risks associated with this. Or generally, are the salespeople not super concerned with the risk? If they just see the value, they’re not thinking about, like, what could go wrong, or any like that. I’m just curious if, through your process of iterating over this product, this is one of the latent problems with AI, is both the known risks, but I think there’s also the unknown risks, which is people not understanding, well, what could an OpenClaw do running on your own laptop, what you don’t know that you don’t know about these systems because you don’t have a software engineering background. I’m assuming there’s some latent risks here that’s come up, and you had to address that, but that could be wrong. Like, tell me a little bit about getting through that product iteration to address the risk side. It sounds like the value side was fairly easy to get to [laugh]?

Steve: Yeah, no, I think the risk side of it came more in two versions. So, version A was exactly what you just said. How do I know that the AI, even though it’s going to surface things at an approval level, right—and but even when it goes into autopilot, which scares you know a lot of people—it’s, how do I know it’s going to be accurate, right? So, what we built very early on was that we honed in very deeply on that compounding context layer because essentially, it becomes a single point of truth for any of the agents. The agents will not make a decision whether it’s a lead that gets surfaced, whether it’s an outreach campaign that gets created, whether it’s an email reply, whether it’s meeting notes, ICP, anything that the agents are able to build and surface within the platform, it won’t do that unless there is a point of truth within the context layer that validates that, if that makes sense.

So, it will not make any decisions with any information that doesn’t essentially derive from the context layer within the organization, right? Which is, that’s why more data that it’s able to ingest the better, right? We’ve worked with some larger organizations that have a lot of fragmented data, they have data everywhere, and what it does really well is it takes that fragmented data, aggregates into a single data lake, and then uses that for the agents from an execution standpoint. So, that’s been actually kind of a hidden value because we’ve been able to flip that into a value. Well, actually, this is how we take your fragmented data and make it usable again.

The second part of the risk factor that we’ve seen, wasn’t so much risk, it was more education, right? Because just like I told you, there’s two sides on the GTM strategy, there’s also two sides on the AI educational plane as well, right? I sit in Silicon Valley, where everybody knows anything about AI the moment that it hits the market, right, but that’s not true for the rest of the United States. It’s not true for the rest of the world. There’s a lot of education still to be done from a global standpoint outside of just the most tech-forward companies in the world.

So, making kind of that educational translation, I’ll call it, where you’re taking something that’s really complex in actuality and creating a simple, comprehensive understanding, that’s been definitely something that did take a little bit of iterating and, you know, moving through, to be able to kind of hit it correctly when having those conversations.

Brian: Yeah. The time to value thing is often a challenge with automated intelligence tools, with analytics solutions, things like this. Is this a challenge for you all? And so, how did you address this in the product experience, you know, this really kind of from the sales part, probably into the trial or somewhere there, which is, how long until we actually see the value of this? Like, conceptually, we can understand what it’s doing.

It’s offloading some what used to be human work to a machine to do it for me so I can spend more time doing high value, what we call goal time versus tool time, I have more time to spend on my goal time activities. Was there something you had to hone in on to make sure that the value came out sooner than later? Because it takes time to build context. It takes time, potentially, to build intelligence, or maybe not. Maybe there’s enough low-level grunt work that you could just immediately bang out and it was not so difficult. I mean, tell me about that. Was it hard to show the value quickly?

Steve: No, you’re a hundred percent right. Like in the beginning early iterations of talking about Zig, we focused very heavily on the work, right? Because that’s where we felt like, yeah, this is going to save so many people, you know, time, and they’re going to be able to focus on that goal time, versus, you know, tool time—which I love that, by the way—they’re going to be able to focus on that, and it’s going to make their lives much better in the role that they were hired to do. The issue that we found was that that’s very subjective, and to prove that in a 60-day window, there’s challenges with that. So, what we decided to do is we took a step back and we moved into an FDE model, right, a Forward Deploy Engineer model.

Now, our model is a little bit different than a standard FDE model. What I mean by that is we call our FDE ‘CSEs,’ Customer Success Engineers, and the reason we call them that is because they actually manage the customer’s entire life cycle after implementation. And the reason that happened is because I used to work with a lot of software companies as a consumer running different organizations, and I always hated that kind of dead period between the sales guy who sold me the software and the customer success manager who didn’t know me from Adam. And you know, there was like a three-month dead period, they introduce themselves, and now we have to build this whole new level of rapport. They don’t know any historic context about everything I just went through to get the product up.

So, what we decided to do is make our CSEs essentially be the ones who build out the workflows, right, and embed the agents in those workflows, and work with the customer to solve the problems, and then stay with the customer the entire lifecycle and manage that account. So, my point with that is the reason that we made that transition and that step forward was because we went to give us your top three problems as an organization, right, or as a sales organization, give us your top three problems and let us solve for those in 60 days. If we solve for those in 60 days, then we can consider the 60-day POV a success. You may have 20 on your list and we’re going to get through all 20, but we don’t want to give you 10% of 20 different workflows where we can give you a hundred percent of three of them. It’ll prove that value to you, and then we’ll start knocking down the other 20.

And this actually happened very recently. We had a customer who had 16 different workflows where he was like, “If you can fix all these, this will be the greatest thing I’ve ever purchased.” And we said, “Absolutely.” And we came up with the plan on how we would solve for all 16. We said, “Out of these 16, what are the three to four that are just, like, a thorn in your side, that if they were fixed tomorrow, it would add a lot of value to not only you, the organization, but also your reps?” And he said—well, you know, he talked to his reps, and he said, “These are the four that we honed in on.”

And so, through the POV, those are the four that we deeply focused on and created optimized workflows for those with the AI agents embedded throughout those workflows where necessary. And a successful POV, and then we moved into obviously paid and continued on his list of 16, right? And more ideas come up as you start real—the funny thing about becoming technology forward is, every solve sparks a new idea. So, then 16 quickly becomes 20 to 24. And so, it’s pretty funny, but it’s great. We love going down that journey. And so, that’s how we kind of mitigated that type of risk very early on.

Brian: Yeah, this gets into, I have this model, which is, if you think about, like, what a salesperson does, like, there’s 26 steps from A to Z, and you give this person a tool that collapses A through G down to one minute, what you really did is you put problem H now at the front of their day.

Steve: [laugh].

Brian: And so, we’re really, what we keep doing is the technology accelerates us through what used to be, like, oh, I need to, like, light candles so I have light so I can do my work. So, first I got to go source some candles, then I got to get matches, then I turn on the light. Now, I can do sewing. Like, now I can get back to my thing. So, we really are just bringing the next problem closer. What used to be tomorrow’s problem, we’ll get to that one day. Now, it’s like right in front of us because we [laugh] collapsed all this other stuff, so that’s interesting what you’re saying there are. You guys, is Zig really a services company that has a product in the background? Because this is a model that I’ve been hearing a lot about, which is, companies are going to—and then you basically, you’re charging for results, but you’re really a services company that has software.

Steve: I plead the fifth on that, right? No, I’m just kidding.

Brian: [laugh]. Not that it’s bad. I mean, I don’t know why that’s been—it doesn’t matter, really. The customer is getting its value, so it doesn’t matter, but I’m wondering if you think of it that way? The reason I asked is, you talked about, there’s 16 problems; we’re going to work on these four.

And it’s like, in a traditional software thing, it’s like it already does that out-of-the-box. It does the same thing for everyone, or maybe you turn on this module, or you pay for that module, or whatever, but it’s not like we’re working on four things and then we’ll work on these other ones. So, tell me a little bit about that because that sounds more like services.

Steve: Yeah, you hit it on the head, right? So, we are built very closely to a services firm. And I’ll tell you that the funny thing about that is my background. If you know my background, or anybody that’s listening knows my background is, I came from consulting. So, I was in consulting for my entire sales career, right? Technology consulting, where I would go in and essentially rebuild networks for, you know, mid-market enterprise organizations from the ground up. And that took a lot of consulting work. You essentially piece asks together into cohorts of problems that you can solve for in a step-by-step process.

What I learned with AI—and you hit it on the head a little earlier on this—is building has become very easy, right, and it’s only getting easier, so the companies that I feel like are going to really be valuable in the next five to ten years are the ones who not only can just build and build quickly, but the ones who can actually get very deep in that build, right? You want to own the intelligence layer and the data layer, you want to own the workflow layer, and you really need to essentially operate as a services company where your relationship with that customer is not just, ‘Here’s a piece of software. Go use it and let me know how you like it this year, and if you want to renew at the end of the year.’ It’s going to be, ‘here’s all of the problems we were able to solve during this period of time, right, here’s how we tackled those, here’s what we learned through that, and here’s how we can make the next 12 months even better than the last 12 months of engagement together.’

So, a hundred percent it’s by design, it is not by accident that we are built very, very closely to a services company with AI and software as the—well AI is the foundation and I always call software, like, the face, right? You hear about, like, LLM or AI wrappers? I like to think of us as a software wrapper, where there’s really a lot of complexity underneath, but we surface it as software because that is what allows users to work in a very comfortable fashion that they’re historically used to.

Brian: Yeah, yeah. Have you seen—so it sounds like you found, like, a problem market fit, you found a problem people were willing to pay for. It wasn’t too hard to figure out, like, would they care about all this intelligence, all this stuff that we could automate, do they actually want—will they pay to do that? Because this is a problem, I think, in the data product space that I see is, because we can do this stuff with data now, therefore the market should want that thing because why would you possibly want to do that manually?

Whether it’s giving you insights about something, or actually taking action on the insights—because I see a lot of these intelligence tools is basically they are tools that are taking action against analytics behind the scenes. So, you get some data, some insights, and you let the machine make some decisions here. Have you seen other tools in your space that have what I call this invisible intelligence gap, where they’re technically sophisticated under the surface, but the customers can’t see the value? It’s too convoluted, or the time to value is too long, or the there’s too much behavioral change required on behalf of the users to get the value out of the solution, so they’re technically impressive, but they’re not actually connecting with a problem that people are urgently wanting to solve. Do you see that in at all in this space that you’re in?

Steve: You know, yes, and what I feel like it has come down to, right, is historically from a traditional software standpoint or a technology standpoint, it was always about who can build, right? Technical founders or people with a really good ability to build really complex, structural, kind of, pieces of software won. With AI, what’s happening is, I a hundred percent think that engineering is not going away. I think that AI does a very good job of making good engineers, great engineers, and making great engineers, like, superhero engineers, right, so the building part, though, for them, has gotten a lot easier.

What I think is becoming more and more relevant and important is, like you said, it’s going to come down to problem market fit and founder market fit, right? Is the founder of this organization somebody who understands every deep-rooted piece of the problem enough to where you can essentially go to product and engineering and build for that, right? Do they know how to effectively communicate how those problems are presented and all the faces that they could see? Because what ends up happening on the other side, what I’m seeing a lot now is because building has gotten so easy, companies are tending to overbuild for what they think is the problem that they’re going to solve for, like, “Hey, this is a problem, so we need to build this and this,” but really, that’s not even that big of a problem. You built 150% piece of your software around a problem that is, you know, a 15 to 20% problem, right?

Brian: Yeah.

Steve: So, to kind of wrap that up is, I think that the founder market fit and the problem market fit is going to be the, kind of, biggest superpowers for the companies of tomorrow because of that overbuilding aspect. You essentially need to build something that people really care about quickly, as opposed to building something that is going to be so sophisticated, but you’re going to have to spend, you know, a year building it, and then six months explaining it to people before somebody actually says, “Oh, yeah, I could see the value there.”

Brian: Yeah. I mean, I think there are ways around that, which is the whole space of user experience, and user experience research in particular is slowing down to speed up. It’s spending time to really understand, like, what is someone’s experience life today, and how might we make their life better if we really understood what’s it like to be a salesperson at an automotive company, you know, doing your work every day? You can get to that as a non-founder. I do think you have a lot—there’s a lot to what you said here about domain expertise.

Like, you have—you’re a salesperson running a sales software company, so you have all this resonant domain information, which can be really good. I do want to ask you about are you a pain in the ass for your product team? Because here’s the downside of that, right? It’s when the founders, and in my experience, when founders do understand the domain really well, I think time-to-revenue is faster to get, first of all, getting off the ground, you kind of have that product-market fit much faster. That’s all really good.

Where the downside can be is that they tend to believe that their model of the world is the same model everywhere. So, your model of how an optimal sales team should be run and what they should be doing isn’t actually the ground truth everywhere else, and so retaining that objectivity that, “Well, I think you know the I don’t know we shouldn’t be doing follow-up sequences at all. Those should be phone calls, like, all this stuff about automated campaign outreach, no, no, no, no, no. You know the data says you should do phone call follow ups and blah, blah, blah, so your model is this.” Talk to me a little bit about, like, how do you keep yourself in check from your background working in this space, which is overall, I think, a win more than any type of cost, but it can have negative side effects too. Like, talk to me about that.

Steve: For sure. So, to answer your first question, I am, my opinion, as to my product and engineering team, I can almost bet money. But, um—

Brian: “Steve wants it this way.” [laugh].

Steve: Yeah, we have a very, very good—we operate by a lot of just, like, North Star rules, like, in order to move. You have to today. Like, things cannot be up for debate or up for discussion for too long because you have to operate with the mentality in today’s world that there’s somebody building something that is essentially going to compete with you, and if they can do it in one or two conversations, but it’s taking you four to five conversations, they’re going to beat you, right? And so, we operate with that. And so, this is, kind of, our three rule between me and my two co-founders, which one of my co-founders, he’s the head of product, and then the other is the head of engineering, right, and I’m obviously the CEO.

And so, it is my role to tell them what we build. And when I say that, though, it doesn’t come from me, it comes from—we have essentially a roadmap that is built out but doesn’t actually have prioritization or deprioritization built into it. We deprioritize and prioritize based on customer feedback. So, based on customer feedback, prospect feedback, conversations that we’re having with the external world, we have this dynamic roadmap that says okay, now we’re going to prioritize this, right? This was actually number seven in what we thought was going to be number seven, but actually we just got three requests for the same thing; it’s now number one, right? So, that becomes, kind of, our source of truth.

The other thing is, so that's what we build. So, it’s up to me to say, hey, “Here’s what we’re going to build this week.” It is up to my head of engineering to say, “Here’s how we would build that very quickly.” And then our head of product says, “Here is when we could build it, when we can have it completed, and what sacrifices, Steve, you’re going to have to make for us to build it. So, if you want to push this up to number one, then that means this, and this, which is in line, is going to take a backseat. Are you good with that?”

And then I make a judgment call based on conversations I’m having, internal discussions, really. And this all happens, by the way, within, like, a 48 hour period. Like, this is not, like, a long, drawn out process. This is like, from start to finish, 48 hours. And we say, “Okay, great. Yeah, no, I’m good making those sacrifices. Let’s go.” Or, “You know what? Hold on. Yes, we got a request from one customer. It sounds really cool, but let’s actually go to a couple other customers and see if this would be valuable for them before we push it this high on the list.” And that’s how we’ve operated, and we have been able to move extremely fast with those kind of methodologies in place.

Brian: Yeah, yeah. How do you not worry about these, particularly the—I tend to thi—I’m not coming from a sales background, but I have to do sales to run my business—I’m tending to think of the CRM as sort of being the heart and soul of the sales organization, in terms of the software piece about where does all the information live about all of our deals and things like this. What’s to stop a HubSpot or a Salesforce from just building all this stuff internally so that you don’t need a third-party tool? I’m sure they’re thinking about these kinds of things. I know some of them already have some of these kinds of capabilities, but what’s your moat that kind of protects you or keeps you guys safe from the tools themselves having that capability just as part of what that is inherently in HubSpot, for example?

Steve: Yeah, so a couple of things, right, is the reason we integrate into Salesforce and HubSpot, and you know, all these other CRMs on the market, like, Pipedrive and Zoho and you know, so on and so forth, is because we don’t have a desire at this time, to become that system of record, right? The system of record piece, the CRMs have done that very well for a very long time, they’ve figured that piece out, right? What they have not figured out yet is the system of execution and intelligence. And what I mean by that is you have all of this CRM data that, yes, can be surfaced when a user asks for it to be surfaced, right, but what’s actually happening with that data now becomes kind of a human-to-human problem. I wouldn’t say problem, but like, a human-to-human kind of gut shot, right?

When you have a system that is built on intelligence like ours, which is built on a machine learning foundation that it actually learns, not only from historic data, but ongoing data where the knowledge base is dynamic, you can’t replicate that in a traditional software company. In a traditional software company would essentially have to essentially strip down to the bare bones and rebuild to a certain degree, which would put them in a little bit of a kind of ROI gap, right? And because they’re publicly traded companies, you answer to shareholders, right? This is why I think that privately owned companies that right now are at an advantage of being able to move a lot quicker because we don’t essentially have public shareholder money behind us to say, “Oh God, we can’t afford 30 days of, you know, slow down in order to get this and this done because it’s going to communicate this type of, you know, message to the market,” right?

For us, we make a gut shot on it of, hey, this is going to hold us up for 30 days, right? Our growth is going to be 50% instead of 100% for the next month, but that’s okay because once this is implemented or once this change is made, all of a sudden, we’re going to see hockey stick, you know, type of growth. So, right now, in the AI age, flexibility is becoming the utmost moat, in my opinion, as to how quickly you’re able to iterate and move for customers.

The final piece of that is, and this is just me, kind of, you know, half jokingly, but historic pieces of software are built very heavily for management and built very heavily for stakeholders. They’ve never really thought of the end-user experience, right, and I don’t think that they’d be able to build for the end-user experience fast enough, and nor would they want to. It’s not really their realm. They get their renewals every single year because, see, nobody’s ever gotten fired for implementing Salesforce, right? It’s a known thing. And so, they have that kind of on lock, I would say so our ability to go very deep at the user level, and the benefit be indirect for the stakeholder level, like, yeah, if your reps are driving more revenue, that’s great for everybody, that’s where our focus lies, and we’re okay with that and let the systems of records focus on the CROs and their direct, kind of, God-mode visibility over their entire organization. That’s cool.

Brian: Yeah, yeah. This has been great. I really appreciate your time sharing all this today. Is there any, like, closing thoughts that you have for other founders or heads of product that are trying to bring technically sophisticated data products to market, whether they have automated intelligence or they’re providing insights and things like this? Any suggestions for them to find that product-market fit or to increase user adoption, if there’s apathy or just kind of low, low usage on the user side that you’ve learned? Any closing thoughts?

Steve: Yeah, don’t overthink. I mean, right, now, more than ever, don’t overthink. Getting it in a customer’s hands, right? I heard a podcast few months into this that I really valued, and it was, if you’re not—and you’ve heard it, I’m sure, a million times—but if you’re not embarrassed by your first iteration of your product, then you didn’t get to market fast enough, right? I think that produ—especially heads of product and heads of engineering, they have this pride around their—and passion around what they do, that they want to put out just this amazing product at day one, but that you have to iterate so many times, and then you still run the risk of, well, when I get it to market, does anybody care?

At this point in today’s day and age, specifically with the AI boom, it’s get it in a customer’s hands as fast as possible, even if you’re at you know 10%, 20% of a baked—of where you know you’re going to be long-term, and let customers rip apart that 10 to 20% and tell you what they love and what they hate. We did that really early on. Every single week we, not only on Slack channels, but on dedicated calls, we would jump in with every customer and say, “What do you like about the platform? What do you hate?” And then we would just focus on what they hate so deeply until we got it right that it allowed us to then create enhancements.

Now, what that does is it does two things, builds customer, long-term customer trust, and then number two, it lets you get to the market fast and start making some noise. Right now, that’s what is absolutely necessary. So, my one advice for founders right now that are looking is just—that are looking to build something and get it out to market—is just get it to market. Get it to market and let it iterate in the wild, and you will be so much happier long-term than if you just overthink for the next couple of months or a year, whatever it is, and then get it to market and nobody cares. That’ll crush you at this point.

Brian: Yeah, yeah. Steve, thank you so much. Where’s a good place, if people want to get in touch with you? Obviously, Zig.ai is your company. Is there a place you hang out? LinkedIn or anything like that?

Steve: Yep. So, you can check us out on our website or our LinkedIn at both our Zig.ai. And if you, you know, are a potential customer who’d like to work with us, it’s hello@zig.ai or you can reach out to me personally at steve@zig.ai.

Brian: Awesome. Steve, thanks again. It’s been great having you on Experiencing Data. I appreciate you sharing everything.

Steve: Thanks, Brian. I appreciate it, man.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Subscribe for Podcast Updates

Join my DFA Insights mailing list to get weekly insights on creating human-centered data products, special offers on my training courses and seminars, and one-page briefs about each new episode of #ExperiencingData.