In this episode
In episode #30 of season 6, we speak with Rehman Abdur, co-founder of Saber, about pivoting twice before finding a product customers would actually pay for, why enthusiastic feedback can be the most dangerous signal in sales, and how an unexpected wave of Claude Code users became Saber’s strongest growth opportunity.
Rehman Abdur’s career followed a clear path through B2B sales. He started as a sales development representative, became an account executive, and moved into head of sales and VP of sales roles. That specialization gave him a close understanding of the challenges sales teams face, as well as a network of people who could help test potential solutions.
Today, Saber helps businesses understand which prospects may be in market, what is happening inside those companies, whom to contact, and what to say. The aim is to replace “spray and pray” outreach with fewer, better-informed interactions.
Rather than sending thousands of emails and hoping something resonates, teams can use relevant company signals to make their outreach more specific. Reaching that focus, however, required the founders to move away from much broader ideas about how sales software should work.
Entrepreneurship as a Series of Informed Attempts
Rehman sees entrepreneurship as a process in which most attempts will fail. In his own framing, perhaps 90–95% of the shots a founder takes will not work, while the small remainder can create substantial value. This is his perspective on experimentation, rather than a measured startup success rate.
That outlook also shapes how he thinks about working hours. Although he describes working long weeks himself, he considers the number of hours less important than continuing to test, learn, and recognize what deserves to scale.
Andre adds an important distinction: taking more shots is not the same as building unrelated apps and waiting for one to succeed. AI makes it easier to launch software, but it does not automatically provide customer understanding, distribution, or domain expertise.
For Saber, experimentation stayed within a familiar market. The team changed its approach to sales problems rather than jumping between industries. That continuity allowed customer relationships and accumulated knowledge to remain useful through each pivot.
The First Product: A Useful Solution Without Enough Urgency
Saber’s first product addressed sales enablement. Rehman had seen substantial differences in knowledge, skills, and access to information across sales teams. The initial idea was to bring internal organizational knowledge together from different tools and make it easier for salespeople to consume.
The founders followed a familiar startup process. They interviewed potential buyers, involved them during development, and spent several months building the product. On the surface, the response was encouraging.
But when the product was nearly ready, the commercial conversations stalled. Prospects praised it while explaining that it did not solve one of their most pressing problems. They could imagine buying it eventually, just not now.
After more than 50 similar conversations, the pattern became difficult to ignore. The product was interesting, but not urgent enough to command a budget.
The failure was not a lack of positive feedback. It was the absence of a compelling reason to buy. A prospect could genuinely appreciate the idea and still have several more important problems competing for attention.
The “Happy Ears” Problem in Customer Validation
Looking back, Rehman identifies “happy ears” as a major source of confusion. Founders invest deeply in their products, so encouraging comments can easily sound like stronger validation than they really are.
Someone saying “this is nice” does not establish how much they would pay, where the budget would come from, or what would make them act now. Those questions need to be explored directly.
Rehman still sees value in startup books such as The Mom Test, The Lean Startup, and Zero to One. His concern is that applying a familiar framework mechanically is not enough in a market where buyers have many alternatives. Talking to customers remains essential, but the quality and interpretation of those conversations matter.
The appropriate test also depends on the sales model:
- For a low-cost, self-service product: Asking someone to enter a card or begin a paid subscription can provide a direct test of willingness to pay.
- For a larger B2B purchase: Validation often involves understanding the buying process, involving stakeholders, and establishing a business case.
- For either model: Enthusiasm needs to connect to a concrete problem, an intended use, and a credible path to payment.
For products selling at around $15,000–20,000, Rehman looks for signs that the conversation is expanding beyond one enthusiastic contact. When that person brings colleagues into discussions and helps the vendor understand different stakeholders’ needs, the opportunity becomes more credible.
A payment link can be useful, but it is not a universal substitute for understanding how a customer buys.
Rethinking the Minimum Viable Product
Another lesson concerned what buyers now expect from an MVP. Rehman argues that “minimum” means more than it once did, particularly in technology markets where prospects know how quickly polished prototypes can be created.
A convincing interface or a handful of basic functions may no longer be enough to stand out. His proposed threshold is more specific: an MVP should solve one meaningful problem better than most available alternatives.
That does not require building a comprehensive platform. A product does not need to outperform competitors across 20 capabilities. It needs a narrow strength that customers can adopt within their existing environment and explain in business terms.
Rehman suggests that some early customers may accept missing administrative or advanced security features when there is a credible plan to develop them. The central question is whether the core capability provides enough value to justify adding another tool.
In his view, goodwill toward an early-stage founder is less reliable than it used to be. Buyers may like the team, but they still have fixed budgets and many competing options.
The First Pivot: Following a More Important Problem
The decision to move away from internal sales enablement became easier when a different pattern emerged in customer conversations. Consolidating internal information was a challenge, but gathering and interpreting external prospect information appeared to be a bigger one.
Rehman and his co-founder, Joey, were aligned on building a successful business rather than defending the original idea. When multiple people independently described the same external-data problem, the founders had a clear direction to investigate.
The harder part was the transition itself. Rehman describes a period of roughly two weeks to a month in which the team moved between products and restarted parts of the work. At the time, that could feel like wasted effort.
Yet the learning carried forward. The founders had gained a better understanding of where customers spent time and which challenges were most important. The product changed, but the customer discovery was not discarded.
The Second Product: Paying Customers Without Repeatable Growth
The next version helped salespeople consolidate external information about prospects so they could approach conversations better informed. Unlike the first product, it generated revenue.
That was a significant milestone. It also exposed a different problem: the people who loved using the product often lacked the authority to buy it.
Individual salespeople and even first-line managers could be enthusiastic trial users. But purchasing required escalation to more senior leaders. Along the way, sales leadership or revenue operations might question why another tool was needed, whether it duplicated the CRM, or which budget should cover it.
Even expanding into another team inside an existing customer could be difficult. User satisfaction did not automatically create an easy route to growth.
A second challenge was workflow variation. Different organizations worked differently, and individual salespeople within the same organization wanted the product adapted to their own preferences. That created friction in both selling and delivering the software.
The experience revealed a distinction between user fit and buyer fit. A product could be genuinely useful to its daily users while remaining difficult for the organization to purchase and expand.
Why Adding More Features Did Not Solve the Problem
The team initially responded by continuing to build. Customers and prospects regularly suggested that one additional capability would make the product indispensable.
Some wanted an extension to an existing module. Others needed a different workflow or an extra step before they could become regular users. Each request sounded reasonable on its own, but together they pulled the product in many directions.
For a small team, those requests competed with limited time, budget, and development capacity. The challenge was no longer simply getting the first dollar of revenue. It was finding a repeatable way to win the next five customers, then the next ten, without rebuilding the experience around each account.
These struggles took place before the team had access to the agentic coding tools that later became central to its work. Development support from AI existed, but the team could not yet rely on the coding-agent workflows it would eventually adopt.
More importantly, faster development alone would not have resolved the underlying question: which part of the product created value that many customers could agree on?
The Second Pivot: Isolating the Data Customers Valued
Joey proposed the next pivot after noticing a consistent pattern across paying customers. People disagreed about workflows and interface preferences, but they repeatedly praised the specific prospect data Saber could uncover.
These were not simply company names, websites, locations, or employee counts. They were business-specific signals that could help explain why a prospect might need a particular solution.
For a company in the observability market, useful questions included:
- Does the prospect use Kubernetes?
- When did it last hire a site reliability engineer, and is it planning further hiring?
- Has it experienced outages, how frequently, and for how long?
- Is there evidence of an initiative to improve observability?
- Does it use several monitoring tools, such as Datadog, Grafana, and New Relic?
These signals were difficult to gather at scale and closely connected to the customer’s commercial priorities. They offered more context than basic company information alone.
The founders’ question became straightforward: if they removed the surrounding features and sold only this capability, would buyers still want it?
That shift became the foundation of Saber’s current form. Instead of continuing to shape a broad application around different sales workflows, the team focused on the data customers consistently found valuable.
Claude Code, MCP, and an Unexpected Route to Growth
Discussions about the new direction began in late November 2025, with active work underway during the first two weeks of December. Around the same time, a team member encouraged the founders to explore Claude Code.
The team began using it both to develop the new product and to test Saber itself. That internal use exposed a practical need: accessing the product through an agent-friendly interface would make testing easier.
Saber first built an integration using the Model Context Protocol, or MCP. The decision was initially for the team’s convenience rather than a response to customer demand.
As they used it, they found that tool calls consumed more tokens than they wanted. That prompted them to build a command-line interface, or CLI, as another way to access the product.
At the same time, they noticed more people discussing how they were building revenue workflows on top of Claude Code. These potential customers were easy to identify because they were openly describing the way they wanted to work. Some immediately asked whether Saber had an MCP integration.
Within a month of the interface decision, the team closed its first deal for the new direction, and more followed. Rehman estimates that roughly 95% of Saber’s biggest users are now Claude Code-native, accessing the product through its CLI and connecting it with tools such as HubSpot and n8n.
For Rehman, that outcome contained a substantial element of luck. He had not expected sales teams to adopt a terminal as a primary working interface. Saber’s earlier iterations involved considerable planning, yet this unexpected change in customer behavior helped create its strongest growth opportunity.
The preparation still mattered. The team already had valuable data, domain knowledge, and experience working with customers. When a new way of consuming that value appeared, it was able to respond.
Letting Paying Customers Inform Product Decisions
As Saber’s customer base developed, prioritization became less dependent on internal debate. The team could take a lightweight mockup—or even a single HTML page—to customers and ask how they would use it.
Some ideas were quickly dismissed because customers could not see themselves using them. Other requests came directly from customers who explained that a missing capability would increase their usage.
The business model makes those conversations particularly useful. Saber is largely credit-based, so customers understand that asking for more functionality may also mean consuming more credits.
That does not eliminate product judgment, but it creates a clearer connection between a request, intended behavior, and commercial value. The discussion is different from an early prospect saying that something looks interesting.
Customer discovery remains central. What has changed is the quality of the evidence: paying users can describe how an addition would fit into an existing workflow and why they would use more of the product.
The Future of SaaS: Fewer Interfaces, More Connected Capabilities
Looking ahead, Rehman expects substantial disruption in SaaS rather than its disappearance. His view is that people will increasingly complete their work through a smaller number of interfaces, whether those are terminals, AI assistants, or workflow platforms.
Under that scenario, software products need to work effectively within the environments customers already prefer. Strong tool calling and integrations may become as important as the application’s own interface.
Saber’s experience offers one example of that possibility. Customers did not necessarily need another place to manage their work. They needed useful data available inside the tools they were already adopting.
Rehman’s optimism extends beyond business software. He hopes AI will contribute to medical research and a deeper understanding of the universe. These are aspirations rather than predictions with a defined timeline, but they reflect his excitement about increasingly accessible intelligence.
That accessibility has already changed his own work. Despite having no coding background before the previous Christmas, he describes using AI tools to build projects he would not previously have considered possible. Andre shares a similar experience of moving from copying code between applications to working directly in a terminal.
Rehman Abdur
Co-founder of Saber
