How to go from $0 to $1M in ARR

Bringing a startup idea to life is rarely a linear journey. Instead, it’s an iterative process of discovery, validation, and refinement—less like following a neat roadmap and more like trying to find your way to the center of a tornado. 

The wide outer rings represent the early stages of problem discovery, where you begin with a high-level hypothesis. As you gather data and feedback from the market, you keep circling inwards, continually honing and narrowing your hypothesis. Eventually, you reach the eye of the storm: the specific, urgent problem that your target users need solved, along with the unique technical insight that enables you to solve it.

In this month’s newsletter, I’ll explore the topic that I introduced in February—the three phases of reaching the ultimate milestone of startup success: $100M in ARR. Last time, I outlined three stages—$0 to $1M, $1M to $10M, and $10M to $100M—each requiring distinct strategies tailored to its level of scale. Today, I’ll focus on the first phase: going from $0 to $1M. To do so, I’ll draw on both my own learnings as an early-stage investor and knowledge shared by 50 founders, CEOs, and operators on my podcast.

Step 1: Crisply define the problem you’re solving

Discerning what the “true” problem is often starts with a founder’s intuition: a hunch, born from personal experience or deep domain expertise, about an unmet need or acute pain point in the market. This intuition is essential because, as Henry Ford once said, “If I’d asked customers what they wanted, they would have told me, ‘A faster horse!'” 

But as powerful as founder intuition can be, it’s not infallible. The startup graveyard is littered with companies that built products no one actually needed, chasing problems that weren’t truly painful or offering solutions customers didn’t value enough to pay for. 

That’s why it’s essential to rigorously stress-test your intuition with real-world data. For early-stage startups, the best source of that data is in-depth customer discovery. You need to get out of the metaphorical building (or perhaps just hop on Zoom) and pressure-test your assumptions with prospective users.

Christian Owens, founder of the payments startup Paddle, learned this the hard way. As he shared on my podcast: “There’s this tendency of founders, and it’s reinforced through the Steve Jobs quotes that are like, nobody actually knows what they want until they’re shown to them, and you don’t need to go and talk to anybody…I think I was definitely subconsciously of that mindset.” By engaging customers upfront and really understanding their needs, Christian believes Paddle could have avoided a year of pivots and tweaks. 

His advice? Talk to as many potential customers as you can, and really listen. You don’t have to act on everything you hear, but immersing yourself in your customers’ world will help you validate or invalidate core assumptions, uncover “unknown unknowns,” and potentially save you from going down the wrong path.

In these discovery conversations, ask open-ended questions that get the customer talking about their day-to-day challenges and goals in their own words. Don’t pitch your preconceived solution and fish for validation. Your goal at this stage is learning, not selling. Concrete, measurable benefits like saving substantial money or time are strong positive indicators. Mere “nice to haves” are usually a red flag.

As Cohesity founder Mohit Aron put it: “You need to have the CIO tell you what the problem is…and the CIO needs to also tell you that he’s willing to pay you a lot of money to solve that problem.”

Founders need to be ruthlessly honest in assessing this feedback, even (and especially!) when it contradicts their original vision. Guard against what Mohit calls “drinking your own Kool-Aid”: stubbornly clinging to a solution in search of a problem. In Mohit’s words, “You don’t want to enforce what you think is a ‘good to have’ on the CIO and then go start a company.”

Consider the early journey of Databricks. As co-founder and CEO Ali Ghodsi shared on my podcast, the company initially devoted all its energy to driving adoption of Apache Spark, the open-source distributed computing framework its founders created at UC Berkeley’s RISE Lab. While Spark gained early traction with Silicon Valley startups, most traditional enterprises found it too hard to set up and manage. The team soon realized that technical superiority alone was insufficient to meet the needs of the enterprise customers that would enable them to build a business at scale.

As Ali put it: “It turns out the Ubers, the Twitters, the Facebooks of the world, they have a different level of sophistication. So that’s when the journey started on how do we really democratize it for enterprise? How do we simplify this? How do we make it even easier?”

This insight—that they needed to shift focus from the technology itself to the adoption challenges that enterprises were facing—proved essential to Databricks’ success. By listening closely to customers and zeroing in on the obstacles that mattered most to them, the company was able to build a platform that made large-scale data analytics and ML more accessible for businesses of all types, not just those with elite engineering teams.

For founders, this means: fall deeply in love with the problem you’re aiming to solve, not the specifics of your proposed solution. Even the most innovative technology is only as valuable as the user needs it fulfills.

Step 2: Establish your ICP

Your ideal customer profile (ICP) is the user who stands to benefit the most from what you’re building—and is therefore the most likely to not only adopt but also actively champion it. Your ICP should guide virtually every product and GTM decision you make as a founder, from how you prioritize your product roadmap, what features you build (and just as importantly, what you choose not to build), how you position and message your offering, and what channels you use to bring it to market. 

For example, a scrappy dev tool startup selling to solo developers will have a radically different ICP than an enterprise SaaS startup targeting CTOs. The former’s ICP might prioritize ease of use, affordable pricing, and self-service onboarding, while the latter’s ICP may care more about enterprise-grade security, scalability, and white-glove support.

To define your ICP, start by segmenting your total addressable market into subgroups based on shared characteristics and needs, such as company size (startup, SMB, Fortune 500), industry vertical (tech, finance, retail), geography (domestic, regional, international), and technological maturity (early adopters, early majority, laggards). Then pinpoint the segment that will derive the most value from your product. The more specific this segment is, the more effective your efforts will be.

Another important consideration is the relationship between your product’s user and buyer. In a startup, they may be the same person: the scrappy founder who wants to move fast. But in a large enterprise, the buyer might be a C-suite executive while the day-to-day user is several levels down the org chart. Each of these stakeholders has different priorities, pain points, and success metrics that your product needs to address. Users focus on tactical considerations like intuitive UX, time savings, and how well your product integrates with their existing workflows. Buyers, on the other hand, prioritize strategic outcomes, ROI, and risk mitigation.

In the case of Databricks, the team soon realized that early adopters of the open source project (Spark) provided valuable feedback, but were unlikely to pay for the offering. So they set out to build a managed service to address the needs of less technical users who prioritized ease of use and turnkey operations over raw functionality. Even within this segment, the company first targeted rapidly scaling startups over traditional enterprises, as the former were more likely to bet on a newcomer.

Next up, you need to figure out your product’s “insertion point”: a way for it to plug seamlessly into customers’ existing tech stacks and workflows and start delivering value with as little friction as possible. 

Databricks again provides an instructive example. The company’s insertion strategy was not to replace customers’ entire data infrastructure, but rather to offer a managed service on top of existing cloud storage providers like Amazon S3. While this narrowed their initial market to early cloud adopters (which, in 2014, was only a handful of companies), it allowed Databricks to piggyback on customers’ prior investments rather than asking them to start from scratch. This made it much easier for customers to say “yes” and realize value quickly. Databricks’ bet was that cloud adoption would outpace their own growth—which, as we now know, proved to be resoundingly true.

Step 3: Build an MSP

With a sharp problem definition and clear ICP, it’s time to start building. Most founders think about launching a minimum viable product (MVP). I advise aiming higher: for a minimum sellable product (MSP).

Your initial product should be relentlessly focused on your “wedge”: the specific use case and customer segment where your value proposition is most compelling. By channeling your resources here, you can establish a user base, validate your core hypotheses, and gather the learnings needed to eventually expand into other markets and use cases. This is what most people call the MVP. 

When scoping your MVP, resist the temptation to cram in features. Instead, include only the capabilities that directly address your wedge audience’s most pressing needs. Cut anything that doesn’t contribute to nailing your wedge opportunity. As Rob Bernshteyn, founder of Coupa Software, explained on my podcast: “The best businesses have the least lines of code with the maximum amount of value and the highest amount of willingness to pay for that value.” Chasing bespoke requests and edge cases will only bog down your development cycles and risk transforming your startup into a glorified consulting shop.

As a founder who cares deeply about your product, it’s easy to get caught up in premature optimization—endlessly tweaking your MVP before putting it in front of real users. Avoid this. At this early stage, the insights you’ll gain from real user feedback will be far more valuable than any amount of internal polishing.

While an MVP is typically enough to let customers get a sense for your product, often within a sandbox environment, it’s rarely sufficient for customers to deploy in production. For that you need to build an MSP: a more complete version of your solution that’s polished enough to start generating revenue. It incorporates the lessons and iterations from your MVP, while layering on all the additional elements needed to make the product production-ready.

The exact scope and feature set of your MSP will depend heavily on your ICP. What it takes to be “enterprise-ready” for a highly regulated Fortune 500 company is vastly different from what’s needed to land a deal with an early-adopter startup. Successfully selling to large enterprises requires a host of capabilities around security (SOC-2, pen testing), privacy (GDPR, CCPA/CPRA), reliability, customer support, integrations, and onboarding. Deeply understanding your ICP’s specific needs, expectations, and buying process is key to designing your MSP.

Whether you’re pursuing top-down sales or bottoms-up growth, your MSP needs to minimize friction and time to value for your users. The underlying principle here is that the value your MSP delivers must significantly outweigh the costs—not just in dollars, but also in time, effort, and organizational capital—of adopting it. Many founders fall into the trap of thinking they can win enterprise deals by offering steep discounts or even giving their product away for free. But in reality, if you’re solving a truly burning problem, price is rarely the real obstacle. More often, it’s the friction of implementing a new solution that gives enterprise buyers pause. 

Consider all the hurdles in a typical enterprise software purchase: securing budget and buy-in from multiple stakeholders, getting sign-off from legal and IT, integrating with existing systems and data sources, training users, and so on. The cumulative costs of navigating these organizational complexities can easily dwarf the sticker price of your product.

As a founder, your job is to proactively identify and remove these barriers to adoption. Depending on your ICP and use case, this could mean investing in integrations with popular tools, robust APIs and SDKs, and high-touch onboarding services. Whatever the specific tactics, the goal is to make it as easy as possible for customers to say “yes” and start seeing value.

In parallel to building your MSP, you’ll need to start honing in on your value proposition. This is the unique benefit you’ll deliver that will make your product indispensable to its users. Your value prop should flow logically from the pain points you’ve uncovered in your conversations with potential customers. It should communicate, in their own language, how your offering solves their problem in a way that’s meaningfully better than any alternative.

Importantly, this isn’t about listing out features and functionalities. Instead, it’s about capturing the ultimate value and benefit those features will unlock for the user. What’s the core promise you’re making to customers? How will you make their lives dramatically easier, cheaper, faster or just plain better? What will you uniquely deliver that existing solutions can’t?

If you’re struggling to articulate a clear value prop, don’t hand-wave it with jargon or hyperbole. Instead, revisit your discovery process and really zero in on what customers are telling you, in their own words. What specific outcomes are they looking to achieve? The more your value prop can reflect their language and motivations back to them, the more impactful it will be.

Prioritize learning above all

Just as no experiment can definitively prove a hypothesis, only fail to disprove it, your goal should be to collect as much contradictory data as you can. Continually ask yourself: what would I expect to see in the data if my core assumptions were wrong? Actively seek out evidence that could falsify or complicate your original hypothesis. Then capitalize on this as an opportunity to refine your thinking. At this stage, the biggest risk isn’t being wrong: it’s failing to learn.