I spent a decade running my own sales companies. During that time, I bought a lot of software. CRMs, dialers, email sequencers, analytics platforms, forecasting tools—you name it, we probably tested it.

And here's what I noticed: almost every tool I evaluated made a compelling case during the demo. The dashboards looked great. The reporting was comprehensive. The forecasting seemed sophisticated.

But when my reps actually tried to use these tools day-to-day? That's when the disconnect became obvious.

These tools weren't built for them. They were built for me: the manager, the leader, the person who needed visibility and control.

And that's a fundamental problem that's plagued sales software for decades.

The Stakeholder Mismatch

Most sales tools are built for management stakeholders, not the actual end user—the salesperson doing the work.

Think about the typical buying process for sales software. Who evaluates it? The VP of Sales, the CRO, maybe RevOps. Who sits through the demos? Leadership and ops teams. Who makes the final decision? Executives and budget holders.

The people actually using the software day-to-day—the account executives, the SDRs, the sales engineers—are often brought in late, if at all. Maybe they get a pilot period. Maybe they get some training. But the tool was designed, built, and sold to someone else entirely.

This creates a predictable pattern: Software that's great for managers but painful for reps.

Dashboards that give leadership perfect visibility but require reps to do twice the data entry. Forecasting tools that create accurate reports but add three extra steps to every deal update. Analytics platforms that slice data beautifully but don't help the rep figure out who to call next.

"I want to build something for the actual end user, the salesperson," became my north star when I started thinking about Zig. Because I'd been on both sides—as a rep using tools that didn't serve me, and as a leader buying tools that my team quietly resented.

What Happens When You Build for the Wrong User

When tools are designed for managers instead of reps, a few things inevitably happen:

1. Adoption becomes a battle. Leadership mandates usage. Reps find workarounds. Managers get frustrated that the data isn't complete. Reps get frustrated that they're being nagged. It's a cycle that creates friction on both sides.

2. The tool becomes surveillance, not support. When software is designed primarily for visibility and oversight, reps feel monitored rather than helped. It's not serving them—it's reporting on them.

3. Admin burden shifts rather than disappears. The promise is always "this will make you more productive." But if the tool requires extensive data entry, constant updates, or complex workflows just to generate reports for someone else, productivity doesn't improve—it just relocates.

4. The best reps disengage. Top performers are the least tolerant of tools that slow them down. They know what works, they have their rhythm, and if your software disrupts that without clear personal benefit, they'll do the minimum required and move on.

The Real Question I Started Asking

As I matured in my career and eventually started thinking about building my own solution, I kept coming back to one question:

If I was still in my account executive days, my sales engineering days, my sales management days—what would I want in what I believe would be essentially the perfect software?

Not what would make my boss happy. Not what would generate impressive reports for the executive team. But what would actually help me do my job better?

"What could make me get three times the output of myself?" THAT was the benchmark.

That question changes everything about how you approach product development.

What Sales Reps Actually Need

When you start from the rep's perspective instead of the manager's perspective, the priorities shift completely.

Reps don't need more visibility into their pipeline. They live in their pipeline. They know their deals. What they need is help managing all the operational work surrounding those deals.

Reps don't need more dashboards. Dashboards are for managers. Reps need automation that handles the mundane tasks so they can focus on conversations.

Reps don't need better reporting tools. They need tools that make reporting invisible—that capture what needs to be captured without them having to think about it.

How many salespeople get excited to use their CRM? The answer is always the same: not many.

But reps do get excited about things that save them time, help them move faster, and let them focus on what they're actually good at—building relationships and closing deals.

So that's what we needed to build.

The Features Nobody Gets Excited About (But Everyone Needs)

When I started mapping out what would actually help me as a salesperson, the list looked nothing like a typical sales software feature sheet:

  • Something that could allow me to move faster
  • Something that could help me understand which customers I should reach out to and when
  • Something that could write emails in my voice without me having to type them out
  • Something that could be my assistant and just handle the operational overhead

Notice what's not on that list: forecast accuracy dashboards, activity leaderboards, pipeline health scores, manager override capabilities.

Those things matter to managers. They don't directly help the rep sell.

The Evolution: From Database to Execution Layer

When I first started conceptualizing what would become Zig, I was actually thinking about building a CRM.

But I quickly realized the CRM market is crowded and, frankly, not that exciting.

More importantly, building another database wasn't solving the real problem. Salespeople don't need better storage—they need better execution.

That's when the concept shifted entirely: We went from being a database storage to basically being this execution layer for salespeople.

Instead of building another place to log data, we could build something that runs workflows, automates follow-ups, drafts communications, routes tasks, and handles all the operational work that keeps reps from selling.

Building for the Rep Changes Everything

When you commit to building for the end user—the actual salesperson—it changes your entire approach:

You start with workflows, not features. Instead of asking "What capabilities should we add?" you ask "How does a rep actually work, and where can we remove friction?"

You prioritize time savings over visibility. The metric that matters isn't "How much data can we capture?" It's "How many hours can we give back to the rep?"

You make the tool invisible. The best experience is when the rep forgets the tool exists because it's working quietly in the background, handling what needs to be handled.

That's kind of how Zig has continued to develop and grow and get more advanced—it feels like on a weekly basis.

We're constantly asking: What comes next in the process that we can automate? What other products on the market have shortcomings we can address? Can we build something natively inside Zig that patches those gaps?

It's land and expand, but from the rep's workflow perspective, not from a feature upsell perspective.

The Feedback Loop That Changes Everything

Here's what's different when you build for reps: you can't fake whether it's working.

Managers might tolerate a tool that gives them better dashboards even if their team hates it. They'll enforce usage and make it work through policy.

But reps? If it doesn't help them, they won't use it. Period.

That's why our feedback loops are so critical. We're constantly talking to our customers multiple times a week to see what enhancements can be made, what if even if it's something about the way a box pops up on a user's interface.

We brought on a customer success engineer specifically to be that focal point between our team and our users. Not to manage accounts—to ensure that what reps are asking for is actually being built.

Because when you're building for the end user, the end user needs to be part of the development process.

What We're Building Differently

So what does it actually look like when you design sales software for reps instead of managers?

It starts with the rep's day, not the manager's dashboard. We map a typical day from the rep's perspective—what they do, what slows them down, what they wish they didn't have to do—and we build around that.

It automates the in-between work. The conversations, the relationship building, the closing—that stays with the rep. Everything else? That's what we automate.

It adapts to their workflow, not the other way around. We don't force reps to change how they work to fit our software. We build the software to fit how they already work.

It makes their job easier first, reporting second. Yes, managers get the visibility they need. But that's a byproduct of making the rep's life easier, not the primary goal.

It runs in the background. The less the rep has to think about Zig, the better we're doing our job. If they're spending time managing our tool, we've failed.

The Outcome That Matters

When you build for the right user, something interesting happens: managers win too.

Because when reps save time, they sell more. When they're not drowning in admin work, they have better conversations. When the tool actually helps them instead of monitoring them, they use it consistently. And when they use it consistently, managers finally get the clean, reliable data they've always wanted.

But it has to start with the rep. It has to be built for the person doing the work.

That's the shift that's needed in sales software. And that's what we're building at Zig.