Day 4 · Clear every floor before you build

By Karthik Nagapuri · 2026-09-17 · Draper Founder Program #2

Praveen Dorna's lean-validation method for any founder: clear every floor (you, customer, problem, because, pitch, product), sell the promise before the product and read PMF as repeatability, then what one customer conversation, a partner playbook and a talk on sleep add.

Day 4 was the longest day so far, and it was long in the good way. It began with a two-hour workshop that took every startup in the room apart floor by floor, and it ended past ten at night in a crowded living-room office with Diet Cokes and a deck of cards. In between, Piyush and I did the thing the workshop told us to do all morning: we left the room and went to talk to the people who would actually use and pay for what we are building. By evening our pitch had changed shape twice.

These notes are organised as a method you can run on your own startup, whatever the sector. The workshop gave the framework; the afternoon showed what happens when you take it into the field.

The day's programme

The theme on the agenda was three words long: test the route.

• 9:45 AM–12:00 PM · Workshop: Validation and Product-Market Fit, led by Praveen Dorna (Founders First)
• 12:00–3:00 PM · One-to-one mentoring with Praveen Dorna and SK
• 3:00–6:00 PM · One-to-one mentoring with Rathnakar
• 6:00–7:30 PM · Fireside: Building a consumer brand from zero, with Indraneel Gupta
• 9:00 PM · An evening at Communitie HQ Hyderabad, the community founded by Sathwik

A note on coverage: the fireside with Indraneel Gupta fell exactly when Piyush and I were out at a customer meeting (more on that below), and none of our recordings captured it. I have not tried to reconstruct it. If you were in the room for it, that is the session to ask a fellow founder about.

Clear every floor before you build

The morning workshop was led by Praveen Dorna, founder of Founders First, a Hyderabad company that works with founders on validation and scaling. The name is the philosophy: "every decision we take inside the company, we think whether it's good for the founder or not." He called his method a science and taught it like one: a building with floors, and a rule that you do not get to climb to the next floor until you have proven the one you are standing on.

He asked the room, again and again, "what comes next?", and the room kept jumping to "solution" and "product". He kept pushing us back down the stairs.

When something breaks later (sales stall, pilots do not convert, users churn), this building is your diagnostic tool. Walk back down and find the floor you skipped.

Floor zero: are you the right person for this war?

The first floor is not even on the diagram. It is you. Before anything else, look at yourself and ask whether you are the right person for this war, or whether you have a team behind you that is. Do you have background in this industry, knowledge of it, a network in it? If you do not, find co-founders or advisors who do. Call it founder-market fit, founding-team-market fit, whatever you like; the question is the same.

The reason it matters is the line I wrote in capitals in my notebook:

Most of you think they're trying to reject you. No. They're trying hard to trust you. So just help them trust you. That is what sales is.

• Praveen Dorna, Founders First

Investors, mentors, customers: most early startups do not have great products yet, they have great ideas. So everyone across the table is looking for some reason to trust you. You can borrow credibility: advisors, a family business in the industry, a pilot with someone known. "I might not be good myself, but I have ten other people blended together, and this is why we are good."

He added that founder-market fit deepens with time. The more you learn your market, the clearer it gets, which is exactly why early-stage investors bet on the founder rather than the idea. The solution will change. They are betting you will figure out the next one.

Your customer is the person who pays

"Customers are like second-rate citizens in India," he said. "We talk about my idea, my money, my funding, my team, but we will not talk about customers at all."

He told a story from his final-round interviews at Amazon in Seattle: an employee who drove four hours on a postal holiday in London to deliver a single book. And a story of multiple rounds of negotiation, each manager negotiating again, so that Amazon stays the cheapest. The point was not that Amazon is nice. The point was that obsession is structural. If it is real, it shows up in every decision, until customers stop checking prices elsewhere and just buy.

Three rules for defining your ICP

The definitions were sharper than I expected:

• Your ICP is the person who gives you money. Not the user. "Don't come and tell me the student is your ICP. Tell me who is giving the money." The user comes back later, at the product level.
• Never put non-living things in your ICP. Not "corporates", not "enterprises", not "defence". A living person with a role: the chief security officer at a mid-size company.
• Segment until it hurts. Not "students" but final-year students from the top colleges in Hyderabad who scored under a certain mark.

The paper test

He gave a test I loved for its simplicity. Write your segment on a piece of paper, hand it to a friend without explaining anything, and see who they go and find. If they come back with anyone other than exactly those people, your segment is still vague.

And vagueness is expensive. When a founder tells a salesperson "go target students", the salesperson invents their own ICP, fails, and gets blamed. "The problem is not with them. The problem is all of us. Lack of clarity."

Look big to investors, test small with customers

There is a tension here that he named honestly. To investors you want to look big, so you show the whole expansion path. But when you are testing, big is a trap.

If you're testing with everyone, you're not testing with anyone.

• Praveen Dorna

His traffic analogy stayed with me. Ask a room to solve traffic for all of Hyderabad and everyone struggles. Ask them to solve it for the one junction outside the building and they will count the vehicles, note the times, and fix it. Then you expand gully by gully. Bring the scope of the problem down and you can solve almost anything.

Validate the problem, not the idea

The second floor is the problem, and this is where he was hardest on the room. Most of us, he said, are solution-first without realising it. Your mother struggles with something in the kitchen and your brain has already built her an app. "Have you ever discussed your problem, or have you always pitched your idea?" From the day we think of something, most of us are collecting idea validation, not problem validation, and incubators cheer us on.

The knife in your hand

The moment you jump to a solution you create bias. He described it as a knife in your hand that you now have to use at any cost: kitchen, restaurant, surgery, you do not know, but you will use it. "I built a ring, so you have to use it as a ring." And then the line that got a laugh and a wince: "Once you start touching the product, you are gone in life."

The first line of code or the first piece of hardware is a hundred miles of effort committed in one direction. He separated two things we usually blur: deciding what to build, and building it. Most founders are fast at the second and barely spend time on the first.

Size and intensity

A well-defined problem has two dimensions:

• Size: how many people face it, and how many will pay. If not enough people face it, "you are building a nice hobby".
• Intensity: how often they face it, how much time or money it costs them, and what they are already doing about it.

Intensity is judged by actions, not statements. "Do you hate traffic? Yes. Do you hate pollution? Yes. Are you doing anything about it? Absolutely nothing. Then is it really a problem?" A parent who is calling friends, trying apps and juggling every day over childcare has an intense problem. A parent doing nothing does not, however loudly they complain.

The best interview questions are about the recent past: what have you done about this in the last three months, and how often? If someone already spends heavily on a clumsy workaround, a cheaper or faster version will make them switch. Existing spend on a workaround is the strongest evidence of pain.

Two things that hide or reveal problems

• Social conditioning hides problems. People accept broken things as "India is like this only". Nobody was begging for ten-minute delivery until someone offered it. Once a truly intense problem is solved (booking train tickets online, ride-hailing, UPI), nobody goes back. So listen for resignation as well as complaint.
• Knowing your customer is the superpower, not the product. If someone else solves today's problem, the founder who knows the customer deeply will find the next one. That is hard to compete with.

Write down your "because"

Between problem and solution sits the floor almost nobody names: assumptions. Customer and problem are reality, things you can observe. Assumptions are mental models. The word he told us to remember was because.

The format is simple: Customer X cannot achieve Y because Z. A student cannot find a job because they cannot clear aptitude tests. The because has to be specific. "Wrong environment" and "not enough effort" are not testable; he called them "corporate BS".

Then you test it with action, not opinion. Give the students an aptitude test and set a threshold in advance. If most of them pass, your because was wrong: aptitude is not the problem, so you do not get to climb, and you go test the next because (resumes, interviews). If most of them fail, your assumption holds, and only now do solutions appear.

And look how many appear: an adaptive test platform, a coaching centre, pre-recorded videos. One validated because opens many roads. A founder who started with "I am building an AI interview tool at any cost" would have been blind to all of it.

He also said something reassuring for the many engineers in the room. People with ten or twenty years in big tech often arrive saying "I want to build a voice agent, where should I use it?" One such founder had built voice agents for months with no buyers. After a month on this method he had stopped thinking about the solution entirely and was chasing the problem instead. If you are a technologist looking for a use case, this is your permission to stop building for a while.

Sell the promise before the product

Solution, he insisted, is not a feature list. At this stage it is a marketing pitch: "I built an AI assistant for founders" is a solution, not features. You test the pitch before you touch the product.

The protein shake that did not exist

His worked example was a protein shake:

1. Go to the nearby gym and talk to twenty people. Learn their words and what they care about.
2. Put up a poster with a claim and a call to action: call or WhatsApp to order.
3. If nobody calls, the pitch is wrong, not necessarily the idea. Change one line and see if the phone starts ringing. That line is your value proposition.
4. Listen to what callers ask. If most ask for vanilla, you know your first flavour.
5. Quote different prices to different batches of callers and compare order rates.
6. Test a version with a testimonial and one without, one with a celebrity face and one without.
7. Buy flavours off the shelf, pour them into plain bottles, and run a taste test. Then try packaging colours and logo sizes on a shelf and watch what people pick up.

All of this happens before any money goes into formulation.

The B2B version

For B2B, the equivalent is to walk in with a deck and exemplar data, not a product. If they are interested, ask for a letter of intent while you finish trials. That letter is evidence. If they object ("I don't see other customers"), the objection tells you the gap. For a founder selling into a closed industry, he suggested getting credible people from that industry to publicly back the claims. "It's not 'trust me'. Trust my five other people in the industry."

Two warnings

First, the promise on the poster becomes the product's obligation. Great marketing that oversells creates one-time buyers who never return. Second, validation is not about proving you are right. Validation is about minimising risk. Startups start with a hundred percent failure rate, not a hundred percent success rate. Each floor you clear shaves some risk off. Execution still decides the rest, which is also why he was relaxed about ideas being copied: give the same idea to a whole room and no two people will build the same company.

Product-market fit lives at the product level

The last stretch was on PMF, compressed because we were running into lunch.

• PMF is per product, not per startup. With three product lines you might have PMF on one and not on the other two.
• The signal is repeatability. The same ICP buying again and again. Sales that go up, then down, then up with no explanation are "some revenue", not PMF. Referrals and retention are the secondary signals, and unit economics has to work.
• Founder-led versus system-led. "If your sales team can't sell, you haven't figured out your product-market fit." A great founder can sell water once. Nobody can make a customer buy it twice.
• The disappearing test. Take a week off. Wherever things break (marketing, sales, delivery) is where the work is.
• Right product, wrong channel still fails. "It's like asking tortoises to climb trees."
• Build one of each first: one segment, one problem, one solution, one product, one price, one channel, bought repeatedly. The answer to a struggling product is not more products. Fix it or shut it.

Two more ideas matter for anyone designing a product. Features fall out of jobs to be done: map what the user is trying to get done in their day, and each unfulfilled job becomes a feature. And the product ICP (the user) and the buyer ICP (the payer) must be kept strictly separate. His edtech example: build the product for the student or teacher who uses it every day, but build the deck for the principal, who only cares about "how nicely you put X to Y".

Praveen closed with his own company's pitch as a live example (he wants to be the "family doctor" for founders, routing them to specialists), and with the fact that he took about a year and a half before touching his product at all. By the time he built the tech, "it was a cakewalk".

Reflection: running the floors on ourselves

At lunch, Piyush and I ran the floors on WearSynapse, and it was uncomfortable in a useful way. Our user was obvious. Our buyer was not: depending on the setting it could be the same person as the user, an owner above them, or a software platform that would distribute us. That is three buyer ICPs, and we had been pitching all of them the same story. Our problem we could state well. Our because was less tested than we would like to admit, and each candidate because pointed to a different product. We had been living on the upper floors (demos, features, hardware) with part of the third floor unproven.

I suspect this is the most common shape of an early startup: strong conviction on floors one and two, a lot of work on floors five and six, and a gap in the middle nobody has written down. If that sounds like you, the fix is not more building. It is one afternoon writing your because sentences and designing tests for them.

How to hear "you can be explained in too many ways"

The afternoon was given over to one-to-one mentoring: Praveen Dorna and SK from midday, then Rathnakar until six, each seeing founders in turn. On top of that, we had a feedback session with an investor. The people and specifics stay private, but the lessons generalise to almost any early pitch.

The core note was about narrative. The investor said the product could be explained in too many ways, and that a listener leaves unsure what the company actually is. If you ever hear a version of this, it is not a comment on your slides. It means you have not chosen. The fix is structural:

• Problem, then solution, then value proposition, then next steps, in that order.
• Answer "why can't someone else do this?" explicitly, not by implication.
• Show a before and after. What actually changes in your customer's day, operationally, once you are there?
• Name the obvious concern first. Every category has one (privacy, safety, cost, switching). Address it before it is raised, with a design choice rather than a reassurance.
• Depth before breadth. Nail the core job to a high standard before going wide into adjacent markets, and move fast toward product-market fit rather than over-engineering.

Afterwards Piyush reframed our own company in one deliberately plain line, and it was more useful than any tagline: describe yourself as simply as a sceptic would, and then be very clear about the one thing you solve that the plain description misses. Undersell the object, oversell the outcome.

What one customer conversation can teach you

From the investor we went straight to a real customer, which is why we missed the evening fireside: a senior professional who owns and runs their own practice, plus a colleague from their business side. Before we said much, we walked through how our thinking had evolved, from a front-desk tool, to something in the working room, to a pitch aimed one level above the user at the owner, to integration with the software they already run. Saying the journey out loud helped the customer see which turns made sense.

Then they told us what we actually needed to hear. The lessons below came from one conversation in one sector, but I have since found each of them true almost everywhere.

Output that does not land in their system does not exist

The clearest directive of the day: without integration into the software the business already runs, the product has no practical use. The output must land in the right fields, not arrive as a nice summary somewhere else. And it must be reviewable immediately, by the person accountable for it, before the moment passes. For any B2B founder the rule is the same: integration is the product. Nobody wants a second screen.

They also told us what not to build. Several things we had half-planned already exist inside the customer's current software. "If they already have it, integrate with that." Ask this question early; it can save months.

Keep it small: templates, not encyclopaedias

The customer described their actual workflow in their own professional language, and one detail stood out: in practice, each professional uses a small, repeated set of options, not the full universe. What a pilot needs is trigger words and a small template per common case, not a system that covers everything. That is true of most workflows. Find the ten things your user does ninety percent of the time and do those perfectly.

Intent leaks at the door

When we asked what an owner actually cares about, the answer was blunt: that the customer completes the next step with them, not elsewhere. Out of that came the most useful operational insight of the day. The longer someone is outside the door after deciding, the lower the chance they convert. They described a large institution in the city that put a counter on every floor so people act before they reach the lift.

This applies to almost any business with a gap between a decision and a purchase: a showroom visit and a booking, a demo and a signed order, a quote and a payment. If your product shortens that gap, lead with it.

Buyers buy numbers, users buy ease

The customer also said something every founder selling into businesses should tape above their desk: the owner never sees the user's comfort. Quote them any monthly fee and the only question is what it does to revenue. Show the number, or they will not even pay a small amount. Your enthusiasm about features does nothing here.

So stop using industry averages. Ask each prospect for their own numbers (how many opportunities, how many converted) and show what a small uplift means in rupees for them.

Sort ideas into must-have and nice-to-have, with the customer

We threw some of our more "entrepreneurial" ideas at them and they sorted them in seconds. A mood-scoring feature: nice to have, not must have. Daily reminders sent in the customer's name: no, "too much into a personal space". Periodic follow-up reminders: yes. And a coaching tool for their sales team, one that listens to calls, sorts leads by likelihood and tells each caller what they missed, lit them up: "Everybody will buy that." It needed no hardware at all. Sometimes the customer's excitement points at a product you have not built yet. Write it down.

The colleague also pushed on the question every hardware founder hears: phones and laptops already record, so why a device? The general lesson is to find the setting your alternatives do not serve well and make it your wedge, and to treat visible, obvious design as a trust feature, not a limitation.

Go narrow on purpose

On competition, they did not soften anything. With a spec in hand, a manufacturer can produce a similar device in a day. So speed matters, and so does focus:

Don't try to keep on expanding and solve everything. Whatever you solve is also a significant thing. Stick on to that and keep improving the same thing.

• a customer, at the end of a long working day

Their practical version: pick one niche. Win one specialty, and its professional association becomes your channel, because one trusted endorsement travels to a hundred peers. And on product design, a line I loved:

It's always the end user who's going to design the thing. What you think is excellent might not be useful for me.

• the same customer

How to walk into a bigger partner

The last part of the meeting was about approaching a software platform the customer could introduce us to. This playbook works for any startup hoping to partner with or sell through a larger company:

• You get one shot. Their leadership is very busy. Do not ask for the meeting until your demo is accurate on the hard cases, live.
• Understand their product before you meet. Take a demo of it first, as a prospective buyer would, so you know every screen and field you would plug into.
• Be a collaborator, not a threat. If you look like a threat, "they'll just swallow you". Every platform has an R&D team already asking its users about pain points.
• Start small. Your core job plus clean integration. Do not promise analytics or a roadmap. Add version two and three after you are in.
• Take their headache. Whatever they do not want to do themselves (hardware, a hard data problem, a new channel) is exactly what you take off their hands.
• Small platforms first. The largest players often build in-house and guard their data closely. Smaller platforms move faster, and later that track record makes you credible to the big ones.

We left with a to-do list any founder could copy: sit with a busy customer and just watch; collect their real conversion numbers; get a demo of the partner's product; fix the pitch before asking for the introduction.

Negotiation is reverse engineering

The colleague, who comes from a consulting and deal-advisory background, gave us a lift afterwards and kept teaching in traffic. It was a short conversation but a dense one, about structuring a commercial deal with a larger partner:

• Tie your price to the right unit. Your partner bills on their unit (seats, beds, locations, transactions). Find the unit that matches how your product is used and frame pricing around it.
• Pilot on simple terms. Offer the core product and an API for the pilot, and define full integration pricing once the pilot proves value.
• Do not try to sell them their own data. Partners rarely want you holding it. The data they care about is your quality. What you learn operationally stays your backbone for future use cases.
• Reverse-engineer their maths first. Spend a solid week understanding exactly how they bill and why it works for them. Then there are two ways in: embed yourself in their highest-margin area, or find what they are not billing for yet and become that add-on, which can grow their revenue and yours together.
• Get a quote, but do not rush to negotiate. Watch where they are willing to compromise. "That's where your margin lies." Negotiation, he said, is all about how good you are at reversing.
• Accept thin terms for the first two clients to get the foothold, then standardise.
• Move toward a subscription so revenue stabilises and the story for investors is a path to profitability.

He pointed to Whoop as a case study in hardware plus subscription done with discipline on cost and accuracy. Then he dropped us off, and we walked into the last event of the day.

Founders are cortisol addicts: protect your sleep

The evening took the whole cohort to Communitie HQ Hyderabad, home of a young community founded by Sathwik, which runs events around a single question:

When was the last time you did something for the very first time?

• our host at Communitie

Children learn so fast because everything is a first, the host said, and adults stop learning when we retreat into comfort. So they run poker nights, Beyblade tournaments where a fourteen-year-old and a forty-year-old are equally competitive, even a night about farming. (There was also a warning to never play chess with a five-year-old unless you want to be genuinely humbled.) The office was a home: a fridge, Diet Cokes, no staff, "clean up your own sofa". It was over capacity, with a promise of a bigger space next cohort, and a KitKat budget clearly planned for fewer people than turned up.

Before the cards came out, the host said the two things I most needed to hear that day. First, that entrepreneurship is glamorised but is simply labour. Their biggest team win had arrived in the most boring moment and felt like stress, not celebration. Founders, the host said, are not dopamine addicts, they are cortisol addicts, voluntarily choosing stress, and no one is going to throw a party for your hard work.

Second, bluntly: stop posting stories of working at two, three, four in the morning. Nothing beats your health. The host said they would change their mind the day someone can guarantee they will live until tomorrow. Given how little Piyush and I had slept the night before, I took this personally. You should too.

Apply it to your startup

Here is the day turned into a half-day working session for any founding team.

Hour one: floors zero and one. Write down why your team is right for this market, and where you need borrowed credibility. Then write your buyer ICP as one living person with a role, and your user ICP separately. Run the paper test on both with someone outside the team.

Hour two: the problem. List the problem's size and intensity. For intensity, write only evidence of action: what your customers have done, spent or tried in the last three months. If that list is empty, you have a complaint, not a problem.

Hour three: the because. Write five "Customer X cannot achieve Y because Z" sentences. Circle the one you have never tested. Design an action-based test with a pass threshold set in advance.

Hour four: the promise. Write three versions of your pitch as posters or cold emails, each with one different core claim. Plan how you will put them in front of real buyers this week before touching the product.

Then, in the field: book one conversation with a real buyer, bring back their numbers, and ask them to sort your roadmap into must-have and nice-to-have. When we did this ourselves, one hour with one customer reshaped our pitch more than a week of internal debate.

Resources from the day

Frameworks

• The validation building, from Praveen Dorna's workshop: floor zero (founder-market fit), customer (ICP), problem (size and intensity), assumptions (the "because"), solution as a pitch, product, pricing and channel.
• The ICP rules: the person who pays, a living person with a role, segmented until it hurts, and the paper test.
• "Customer X cannot achieve Y because Z", tested with actions and thresholds set in advance.
• The poster-before-product sequence (the protein shake example) and letters of intent as B2B evidence.
• PMF as repeatability at the product level, founder-led versus system-led sales, the disappearing test, and jobs to be done for feature design.
• The lean startup idea of validating before building, which the whole workshop was built on.

People who taught

• Praveen Dorna, Founders First (Validation and PMF workshop, mentoring)
• SK, Draper University India (mentoring)
• Rathnakar (mentoring)
• Indraneel Gupta (fireside: Building a consumer brand from zero)
• Sathwik and the Communitie team (evening host)

Companies and tools used as examples

• Amazon's customer obsession, UPI, ride-hailing and ten-minute delivery as solved intense problems
• Whoop, as a case study in hardware plus subscription

What to take away

• Clear the floors in order: you, customer, problem, because, pitch, product, price, channel. When something breaks, walk back down.
• People are trying to trust you, not reject you. Make it easy with borrowed credibility.
• The ICP is a living person who pays. Keep user and buyer strictly separate.
• Test narrow. If you test with everyone, you test with no one.
• Validate the problem, not the idea. Judge intensity by what people already do and spend.
• Write your "because" down and test it with actions, with thresholds set in advance.
• Sell the promise before the product, and remember the promise becomes an obligation.
• PMF is repeatability at the product level, sold by a system, not just the founder.
• Integration is the product for business customers. Output that does not land in their system does not exist.
• Sell numbers to buyers, using their own figures, and ease to users.
• Enter partners as collaborators, after studying their product and their billing maths.
• Sleep. Nothing you build matters if you cannot turn up to build it.

Try this

1. The paper test. Write your buyer ICP on a sheet in one sentence, with a living person and a role. Hand it to a friend with no explanation and ask who they would go and find. If they name anyone outside your intended group, rewrite it. Repeat for your user.

2. Your "because" stack. Write five sentences in the form "Customer X cannot achieve Y because Z." For each one, design a test based on what people do, not what they say, and set the pass or fail threshold before you run it.

3. The three-month interview. In your next five customer conversations, ask only about the past: "What have you done about this in the last three months? How often? What did it cost you?" Count how many are already paying for a workaround.

4. The poster before the product. Write three versions of your pitch, each with a different core claim, and put them in front of the right people with one clear call to action. Change one line at a time and track which one gets responses.

5. Three stories, one product. Write a half-page each for your buyer (numbers), your user (ease) and your partner (outcomes and integration). If they all read the same, you have not written them yet.

6. The disappearing week. List what would break if you vanished for a week: sales, delivery, support, follow-ups. Pick the worst one and write down the process someone else would need to run it.