When you work at a startup, building out a new product isn't the same job as managing one at an established company. You've got tighter constraints, thinner data, and almost no room for error.

To help you navigate that, we pulled together three talks delivered at Product-Led Alliance Summits from people who've actually done it, each from a different angle.

  • Sirisha Machiraju, Director of Product at Uber, laid out a full framework for zero-to-one product building, from finding product-market fit to building the right team. 
  • Dan Olsen, consultant and author of The Lean Product Playbook (2015), gave a structured method for figuring out which customer problems are actually worth solving. 
  • Harneet Kalra, Senior Director at Ethos Life, focused on the reality of shipping products under serious time and resource pressure.

Between them, you get the full arc: what to build, where to focus, and how to execute fast enough to survive.

Start with the problem, stay with the problem

All three speakers discussed different topics, but spoke about the startup experience for PMs in their own way. Eventually landing on the same principle, even if they say it differently: understand the problem before you touch a solution.

Lead with clarity

Sirisha calls this the "what, who, and why" playbook. Before you write a single line of code, make sure you’re crystal clear on what pain point you're solving, who feels that pain, and whether it's severe enough to justify a new product.

She points to Yelp's in-app restaurant reservations as an example. Users were already coming to Yelp to decide where to eat, then had to leave the app to book through a third party like OpenTable. That gap between deciding and booking was the pain point worth solving.

So what does this mean for you? 

Before you scope any new feature or product, write down the gap in the user's journey in one sentence. If you can't point to a specific moment where the user gets stuck or drops off, you don't have a problem yet; you have an idea.

Problems vs. solution-based thinking

Dan takes it further with a split between "problem space" and "solution space." In his view, problem-space thinking is the product manager's unique job. Developers work in the solution space writing code. Designers work in the solution space making mockups. If you're not spending time understanding customer needs, chances are nobody on your team is.

During his talk at Product-Led Summit San Francisco 2024, Dan demonstrated this with a live TurboTax exercise and asked the audience to explain why the product matters to them without naming a single feature. The answers – things like "maximize my refund," "save me time," "help me not anger the IRS,"  – were all problem-space statements.

Dan groups these into benefit ladders: clusters of related needs that roll up into bigger benefits like confidence, time saved, or money saved. That map becomes the foundation for every prioritization call you make afterward.

Try Dan's exercise yourself: pick your product and ask five customers to describe its value without naming a feature. If most answers name a feature anyway, you're probably deep in the solution space and need to pull back.

Harneet’s session didn’t spend much time on discovery frameworks, but his focus on speed reinforces the same point. When he describes shipping a life insurance product in eight weeks under board pressure, that speed only worked because the team already knew exactly what they were building and why.

Speed without direction is just chaos.

Finding product-market fit is a process, not a moment

One of the most useful parts of Sirisha's talk is her phased framework for product-market fit, adapted from SVPG's published work. She breaks it into four stages, each with its own bar to clear.

Stage 1: Stickiness

Find one sticky customer. Stickiness means the customer genuinely needs your product and would notice if it disappeared. "If you have an outage, the customer is actually gonna pick up the phone and ask you what happened," she explains. 

At this stage, collect testimonials too. Third-party validation carries more weight than anything you can say about your own product.

Stage 2: Conversion

Turn that sticky customer into a paying one. Most startups stall here, because there's a real gap between someone willing to use a product for free and someone willing to pay for it. Even a small payment proves real business value exists.

Stage 3: Scaling

Go from one paying customer to several. This proves the problem exists at scale, not just for one customer with an unusual need.

Stage 4: Organic growth

Customers start coming to you instead of you chasing them.

Sirisha is clear that product-market fit is never "done and dusted." It keeps evolving as you scale from one customer to a hundred.

So what does this mean for you? Figure out which of the four stages you're in right now, not which one you wish you were in. If you're still chasing your first sticky customer, prioritizing scale work is premature. Match your effort to your stage.

An alternate framework

Dan offers another way to check product-market fit: plot how important a need is to the customer against how satisfied they are with their current solution. The sweet spot, high importance and low satisfaction, is where real opportunity lives.

He uses Uber versus Segway to make the point. Before Uber, getting driven somewhere without your own car was high-importance and low-satisfaction, since taxis were unreliable, unfriendly, and a pain to pay. Uber landed right in that opportunity zone.

Segway was solving a different problem: getting around short distances, but most people were already satisfied with walking. As Dan puts it, the founder was "in love with the solution."

Before you commit resources to build anything, plot your target problem on this grid. If you can't place it confidently in the high-importance, low-satisfaction zone, you're likely building something nobody asked for.

Prototypes before perfection, and monetization from day one

Sirisha pushes for a prototype as one of your very first deliverables, before engineering even starts in earnest. It doesn't need to work. A clickable prototype in a design tool, or wireframes drawn by the product manager, is enough.

The value is alignment. Customers can see what they're getting, engineers understand what to build, and leadership can see why the product deserves funding.

She also warns against scaling too early. Engineers will raise valid concerns about scalability and technical debt during zero-to-one work, but those belong in the backlog, not the current sprint. 

"Time to market is the most important thing in a zero-to-one," she says. You can fix scale later. You can't get back months lost over-engineering something that hasn't proven it has a market yet.

On monetization, Sirisha makes a point a lot of PMs skip: pricing is part of the product experience, and you should think about it from day one. You won't land on the final pricing model immediately, but having a working idea of whether the product is an add-on, a standalone offering, or a churn-prevention tool shapes how you build and position it from the start. 

If you're working inside a larger company, check how the rest of the portfolio is priced first. You can't price something new in isolation from everything else the company sells.

So what does this mean for you? Sketch pricing options in week one, not month six. Even a rough guess (add-on vs standalone) changes how you scope the build.

Speed as a survival mechanism

Harneet's talk is built around one core belief: how fast you execute often matters more than the product itself.

He tells a story from a past startup where the board demanded a new life insurance product ship in eight weeks. The team hit the deadline, the company raised its Series C, and nine months later the product was shelved because it underperformed. His takeaway: speed of execution, not the product, saved the company.

His advice for moving faster is specific. Push teams to commit to 120% of capacity during OKR planning. Teams that plan for 90% typically deliver around 65%. Teams stretched to 120% land closer to 90%. 

He also pushes for playbooks that standardize repeatable work like launches, partner integrations, and analytics setup, so the team spends its energy building instead of reinventing the same process every cycle.

On experimentation, Harneet warns against what he calls the "self-fulfilling prophecy" of small A/B test wins, where teams celebrate a 2% gain without ever asking if the feature adds real value. Push for a deeper read on whether experiments move the bottom line, not just a metric.

Next time you plan OKRs, try setting the target at 120% of what feels comfortable and see what actually ships. And before you celebrate your next A/B test win, ask whether it moved revenue or retention, not just the metric you were testing.

The PM archetype for startup environments

Sirisha lists the traits that separate strong zero-to-one PMs from PMs in more established environments.

Product sense comes first: the ability to make prioritization calls with limited data, guided by conviction and a nose for where to look for insight.

Communication comes next, written and verbal, because a startup PM is constantly selling the vision to their team, to leadership, to customers, and to cross-functional partners who may question whether the new product deserves resources.

She also calls out "bias to action," the ability to move from strategy into execution without getting stuck planning. "They might have put together a great strategy deck, but if you cannot build it, it means nothing at the end of the day," she says.

Her most distinctive point: the ability to thrive in chaos. Zero-to-one environments are noisy by nature, with disagreeing stakeholders, challenged assumptions, and constant uncertainty. PMs who take pushback personally or get attached to their product tend to struggle. The ones who do well treat skepticism as useful input and keep moving.

Harneet echoes this from the culture side. He names trust, alignment, communication, and accountability as the four pillars of a healthy startup culture, and he's blunt about what happens when you get culture wrong: a bad culture can kill a startup faster than a bad product. 

He pushes for zero tolerance on negativity, and for leaders to deal with toxic behavior immediately instead of letting it spread.

If you're hiring for a zero-to-one role, test for "thrives in chaos" directly. Ask candidates to describe a time stakeholders disagreed with their plan and how they responded. Their answer tells you more than a portfolio review will.

Building an organization that supports zero-to-one work

Sirisha ends her talk with a point that's easy to miss: the organization itself has to be built to support zero-to-one work.

She recommends creating channels for ideas to surface from anywhere in the company, and points to hackathons as an especially effective tool. During the early wave of LLM adoption, her org ran multiple hackathons over six months and found three viable zero-to-one opportunities directly from those events.

She also stresses treating failure as acceptable. If people get penalized for shutting down a product that lacks product-market fit, they'll stop taking the risks zero-to-one work demands. 

And when a new product does succeed, the whole organization needs to be ready for what follows: changes to brand positioning, go-to-market messaging, and the product portfolio.

Consider running a hackathon this quarter. It's a low-cost way to surface your next zero-to-one bet before you need one.

Team structure

Sirisha and Harneet land in the same place here, from different directions.

Sirisha recommends a core team of no more than two engineers, a PM, and maybe a designer, dedicated fully to the zero-to-one effort. Splitting attention across multiple projects kills velocity and blocks the deep thinking early-stage products need.

Harneet backs this up by pushing single-threaded leadership: one person accountable for shipping, even when several PMs are contributing.

If your team is currently spread across three or more projects, that's worth flagging to leadership directly. Both speakers agree it's the fastest way to stall a zero-to-one effort.

Preserving culture

Harneet adds a note on preserving culture as startups scale. New hires from larger companies can unintentionally dilute the urgency and ownership that made the startup work in the first place. 

His fix: make the first four to eight weeks deliberately intense for new leaders, so they calibrate fast to the pace and expectations of the environment.

The common thread

Sirisha, Dan, and Harneet are telling the same story from 3 different angles.

Startup product management means making smart bets with incomplete information, validating those bets as fast as possible, and building a team and culture that can sustain that pace without burning out or losing sight of the customer.

Use their frameworks together, and you've got a practical system for the whole journey, from an idea on a whiteboard to a product customers are willing to pay for and tell their friends about.