Day 6 · Designing for a busy expert's eyes

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

A late-night co-founder working session turned into a playbook for designing a first product and demo for a busy professional: separate buyer from user, build for their own practice, send signals into existing systems, and show the core in five screens.

Saturday had no big stage session. The real work of Day 6 happened late at night, at a table, between my co-founder Piyush and me, in the mix of Hindi and English that we actually think in. By the end of it we had thrown out a large part of what I had been planning to demo and replaced it with five screens that a doctor would understand in ten seconds.

I am writing it up as a general chapter, because the questions we argued through are the ones every founder faces when the user is a busy professional: a doctor, a lawyer, a chartered accountant, a school principal, a site engineer. These people are expert, time-poor, sceptical of new tools, and often not the person who signs the cheque. Our user happened to be a doctor, so the examples are clinical, but I have tried to state each lesson so you can swap in your own profession. The lines quoted below are translated from Hindi and cleaned up.

Separate the buyer from the user

The conversation started where a lot of founders' confusion lives: are we B2B or B2C?

I had been using those labels loosely, and Piyush stopped me. His point, once we untangled it, was that a product for professionals is often both, in two different directions:

• You sell B2B. The product reaches users in bulk through an organisation: an employer, a network of practices, a partner that already reaches thousands of professionals. One idea we talked through was a gifting model, where a company that already works with the users hands them the product in good packaging with a QR code inside, and the user sets it up alone.
• You build B2C. Whoever pays, the person who opens the box and decides whether to use it again tomorrow is a single professional. So the experience has to be designed like a consumer product.

"Selling to doctors one by one is not easy," Piyush said. "But if I sell to one company that has ten thousand doctors, that's a B2B deal where the user is a doctor." That sentence sorted out weeks of muddled slides for me.

It connects to something he had told a panel earlier in the week about why some industries are hard to fix: the decision maker, the builder and the user sit very far apart. In healthcare the owner decides, a software company builds, and the doctor uses, and each optimises for their own piece. The same split exists in law firms, schools, factories and government offices. His version late on Saturday: "The problem we are solving isn't difficult. If it were easy to see from outside, someone would have solved it five or ten years ago." It stays hidden because those three people rarely sit at the same table.

What this means for design

Once you name the two faces, a surprising number of product arguments resolve themselves. When I pictured an administrator, I designed consoles, logins, role management and reports. When Piyush pictured a doctor with a queue outside, he removed boxes. Neither of us was wrong about the business, but only one of those faces decides whether the product is opened a second time.

A useful habit: at the top of every design discussion, say out loud which face you are designing for. A hypothetical example: an edtech founder selling to school chains might discover that the principal wants dashboards, while the teacher, who actually opens the app at 8 a.m., wants one button that marks attendance. Build the teacher's button first. The dashboard can be a report the chain receives.

Build for the practice they own

Piyush had spent part of the day with a surgeon who does robotic surgery, and one line from that meeting kept coming back.

However much a doctor works in a hospital, every doctor has his own clinic.

• a surgeon, as Piyush retold it

The implication is big. Inside a large institution, IT, procurement and existing software all have a say in whether a professional can use your tool. In their own practice, the professional decides alone. So design for the professional in their own practice first, where adoption is a personal decision, not a committee's.

Many professions have this shape. A consultant at a big firm often has private clients. A lawyer at a firm may run a small independent practice. A teacher tutors in the evening. The smallest setting in which your user controls their own tools is where your first product should work beautifully.

Map the real workflow, not the imagined one

Then Piyush described what a typical small clinic actually looks like, and no product document I have read captures it better:

• A patient walks in. Someone at the front types the name, date, complaint and fee into an Excel sheet. Many clinics in smaller cities still run entirely on Excel.
• A paper bill is printed. The slip goes inside to the doctor.
• The doctor writes the prescription by hand. The patient walks out to the medicine counter.
• Someone draws blood outside, and the patient leaves.

"That's how simple the doctor's work is," he said. "Why make it complex?" A big institution needs a full management system with dozens of modules. The owner of a small practice mostly cares about two things: is my data being saved, and is it safe? For them the first product needs a front end, a database, storage and proper security. Everything else can come later.

That is a much smaller product than the one I had in my head. It is also a much more honest one. The general lesson: before designing anything, write down the actual steps of a working day in your user's smallest setting, including the Excel sheet and the paper slip. Your product has to fit into that day, not replace it.

Send signals into the systems they already use

The second half of the untangling was about incumbents. Most professionals already work inside some system of record: practice software, an ERP, a case management tool, a school ERP. I had started designing our own admin console, organisation logins, role management, a whole back office.

Piyush's view was blunt: don't. If you build that, you are building the incumbent's product, badly, and giving them every reason to keep you out. They already have the full system: every user has an ID, every role is defined. What they usually lack is the signal your product captures in the moment of work.

So the architecture we agreed on is send signals, not a platform:

• Your product derives signals from the work itself. For us that meant things like who spoke, which medicines were mentioned, the tone of the conversation, and whether there was an intent to take a next step.
• You pass those signals to the existing system through a clean interface.
• Their software does what it already does well: routes the signal to the right person, triggers a workflow, shows it on their dashboard.

What I liked is that the story stays the same across audiences; only the language changes. To an owner, you say you can lift an outcome they care about. To the software partner, you say you will hand them, per case, a signal they can act on. Everybody cares about outcomes: they want to understand input and output from the top, not what happens in the middle.

There is also a quieter strategic logic. If a hundred professionals go to their software vendor and say "ten of our colleagues use this, we want it connected", the vendor comes to you. Demand pulled by users is a far better position than an integration you have pushed onto a partner.

Pitch the expert with their eyes

This was the part of the evening I needed most.

The day before, I had shown our work to a technical person at a hospital, and walked through the back end: the pipeline, the signals, the APIs. The response was polite and blank. My instinct was that the audience had not understood. Piyush's was that I had shown the wrong thing.

When you go to a doctor, he sees the demo with his eyes. He will not look at the metadata, he will look at the demo.

• Piyush Malik

His argument went like this. An investor who is not from the field will usually bring an expert along, or send you to one. That expert does not know what a REST API is and does not care. They see the demo. If the demo is a diagram of your architecture, you have handed them a new problem (understanding you) instead of a solution to their old one.

We have to show them the problem and the solution. Not a solution that gives them one more problem.

• Piyush Malik

The architecture pitch is a perfectly good pitch, for the right room. A technical partner will happily hear how your pipeline works. A professional user will not. And an investor with a background in your user's field should be treated exactly like a user during the demo. Know which room you are in before you open the laptop.

Why you need someone who has been the user

There was a line in the middle of this that explains a lot about building for closed professions.

"A doctor's assistant can sit in the cabin for years and never fully understand the doctor," Piyush said. "Another doctor understands in two seconds." Many professional communities are tight and hard to penetrate from outside. You cannot really do deep user research unless someone from inside the circle stands beside you.

For founders building for experts, this suggests a simple rule of thumb for splitting product decisions: what the user sees (every screen, every button, the order things appear in) should be decided by whoever has the user's eyes, ideally someone who has done the job. How it works underneath (models, architecture, which tool is better this month) goes to whoever has the technical judgement. Piyush described it as a picture: someone stands in the centre, where they can see what the customer sees, and the rest of the team builds the circle around it and makes it as big as they can. That is not a hierarchy. It is a map of who has the relevant eyes for which decision.

If you do not have that insider on the team, borrow one: an advisor from the profession who will sit with you through a screen-by-screen review every week.

Show the core, narrate the future

One more subtle point. Some features are better imagined than shown. Piyush's example: a patient who needs a follow-up in two weeks. You do not need to build and demo an automated reminder on screen. You say it, and the doctor imagines it, because every doctor has wished for it. What must be on screen, and must be accurate, is the core thing happening live.

This is a gift for early founders with limited time. You do not have to build the whole vision to demo it. Build the part that has to be seen to be believed, get it right, and narrate the rest in one sentence each. A hypothetical legal-tech founder might show a contract being marked up live and simply say "and next week, it reminds you before the renewal date". Every lawyer in the room will picture it.

A five-screen skeleton for a first product

Then Piyush did what I had been hoping for all evening. He walked through the product screen by screen, the way a doctor would use it, and said he would draw it with a pencil if needed. What came out is, I think, a reusable skeleton for any tool that captures an expert's work and turns it into an output.

Screen 1: Capture

For us, a single microphone screen, like the voice recorder people already know from their phones. The user taps, works, and sees that it is listening. Nothing else on the screen. Whatever your capture step is (a photo, an upload, a recording, a form), make it look like something the user already knows how to use.

Screen 2: Review

When capture ends, the expert does not want a wall of raw material. They want it broken down sensibly, so they can trim it quickly. The principles Piyush laid out apply to almost any review screen:

• Break it into short pointers by context, not long paragraphs.
• Label who or what each piece belongs to, infer it automatically, and give a small dropdown to correct it. In our case: doctor, patient, or someone else (an attendant, a parent who spoke up).
• Flag what might not belong. If the context changes mid-way (the doctor takes a call from another ward), that line appears with a question mark. The expert decides.
• Make deleting the easiest action. One press of backspace and a line is gone. Editing is possible, but removal should cost nothing.
• Let them move things. If a piece has landed in the wrong place, they should be able to drag it back.

"We have to give the doctor convenience, not inconvenience," he said. The goal is to pre-filter as much irrelevant material as you can yourself, so that the review is a quick trim, not a proofreading job.

Between review and output there should be a clear "generating" state, so the user knows something is happening. Busy professionals are impatient in the best way: they press enter and want their result.

Screen 3: Output

The reviewed material becomes the artefact the professional actually needs. For a doctor, that is a structured note in a standard format (Subjective, Objective, Assessment, Plan). Only bullet points, no clutter, no paragraphs, and the same one-key delete for any line that is wrong. Use the format your profession already trusts; do not invent a new one.

Screen 4: Insights

This is where the signals you pass to partners become visible to the user, as simple visual graphs rather than tables. How many cases did I handle today? How did they go? How many ended well, and how many left with a question mark? Every professional wants to know this about their own day, even if no employer ever asked them to track it. Insights are what make a tool feel like it is working for the user, not just for their organisation.

Screen 5: History

A place where every piece of work is saved and the user can look back. For the small-practice owner, this answers the one question they really ask: is my data being kept, and kept safely?

Defaults beat features

One detail from the session will matter more than anything clever in the model. Our prescription screen had become, in Piyush's words, "so many boxes in the name of a prescription". He wanted it as simple as possible, and he used something a senior doctor had told us earlier: most doctors regularly prescribe a small set of maybe ten to fifteen medicines, and the doses barely change. Paracetamol comes as 500 or 650, not 400.

So the design became:

• Preload a default list of the most common choices with their standard values.
• The user says or types the short form ("paracetamol 500") and the rest fills itself.
• Show them how to add their own, but do not make them do it first.

"If the doctor only has to say that, and everything else happens on its own, the doctor is happy." Every profession has its version of the ten medicines: the fifteen clauses a lawyer reuses, the twenty ledger heads an accountant touches daily, the handful of templates a recruiter sends. Find the defaults and preload them. It is the kind of small thing that decides whether a tool gets used on day two.

Be honest about demo scope

We were both clear that what we build for a demo is not what we will ship at scale. Some parts will run on heavier cloud models for now so the demo is fast and accurate, and we will optimise, move work on-device and harden it afterwards. That is fine, as long as you are honest about it when asked. Investors and experienced customers know the difference between a demo and a product; what they punish is pretending.

Piyush's last ask reorganised my week, and I think it is the right ask for any technical team before a demo: be willing to delete a lot of what the current front end shows and rebuild it from the user backwards. Not because the back end is wrong, but because the front end is the only part anyone will see.

Watch the build bill before it watches you

One short, unglamorous exchange late in the evening is worth passing on, because almost every team building with AI models trips over it. While racing towards a demo, it is easy to run a lot of metered API calls on a pay-as-you-go or trial account without looking at the running total. We discovered that our usage over just a few days had added up far faster than either of us expected.

The fix we agreed on was simple. For the building phase, a flat monthly plan with a known cost is usually better than open-ended metered calls; keep pay-per-call APIs for the specific paths that need them, and put spending limits and alerts on every account. The second half was about habits between co-founders: say before you spend, not after. A small expense flagged in advance is a conversation; the same expense discovered later is a surprise.

The broader principle we landed on fits in one line: as the product matures, output should grow while costs shrink. If every new feature makes your running cost climb faster than your usefulness, something in the architecture or the tooling is wrong, and it is far cheaper to notice that during a demo sprint than after launch.

Reflection: the mistake technical founders make

This section is my own reflection after the session.

The mistake I had been making is common among technical founders, so it is worth naming. I was demonstrating what was hard to build rather than what was easy to use. The back end is where most of my hours went, so it felt like the most impressive thing to show. But effort is not value to the person watching. A professional measures a tool by how few seconds it takes them to trust it.

The second thing I noticed: our argument about B2B versus B2C was never really about business models. It was about which person we were picturing when we made a decision. Every product decision gets easier once you agree which face you are designing for.

Third, the partner question. It is tempting to build everything yourself, because owning the whole stack feels safer. On Saturday I came round to the opposite view. The incumbent already has the IDs, the roles and the workflows. You have the one thing they cannot get without being in the room. Being the best at that one thing, and easy to plug in, is a stronger position than being a second-rate copy of a system your customers already run.

Finally, clarity between co-founders is part of the product. Saturday was the first time the two of us wrote down, in one sentence each, which decisions sit with whom. Customers and investors can feel that clarity in a demo, even if they never hear the conversation that produced it.

Apply it to your startup

Here is the checklist I now run on every screen, built from the session's principles. It should work for any product aimed at a busy professional:

• Can a user tell what this screen is for within ten seconds, without me talking?
• Is the most common action (capture, delete a line, generate the output) also the easiest action?
• Is anything on this screen here because it was hard to build, rather than because the user needs it?
• Could this feature be narrated instead of shown?
• If a senior practitioner watched over my shoulder, what would they remove?
• Does the screen assume a large institution, or does it work just as well in a two-room practice?
• Am I rebuilding something the user's existing system already does?

And three decisions to make this week:

1. Write your two faces (buyer and user) on a card and stick it above your desk.
2. Pick your smallest setting: the practice, clinic, studio or classroom where one professional decides alone, and design for that first.
3. Decide your demo's core: the one thing that must happen live and accurately. Everything else gets one narrated sentence.

Resources from the day

Who taught

• This was a working session between co-founders rather than a programme talk. The ideas came from my co-founder Dr. Piyush Malik and from earlier conversations that week with a robotic surgeon and a senior doctor (anonymised here).

Frameworks and ideas named

• Two faces: sell B2B, build the experience B2C.
• Decision maker, builder, user: the three-way split that keeps some industries' problems hidden.
• Build for the practice the professional owns, where adoption is a personal decision.
• Map the real working day, Excel sheet and paper slip included.
• Send signals, not a platform: feed the systems users already have through a clean interface, and let user demand bring partners to you.
• Pitch with the expert's eyes: outcomes for users, architecture for engineers.
• Whoever has the user's eyes decides what the user sees.
• Show the core live and accurate, narrate the future.
• The five-screen skeleton: capture, review, output, insights, history.
• Defaults beat features: preload the ten to fifteen choices users make every day.
• Flat plans and spending caps during the build phase; say before you spend.

Formats and tools mentioned

• The SOAP note (Subjective, Objective, Assessment, Plan), the standard format clinicians already trust.
• The phone voice recorder as the model for a capture screen people already know how to use.
• Excel, still the system of record in many small practices.
• REST APIs as the interface for passing signals to a partner's software.
• QR codes inside packaging for a gifting-style rollout where the user sets up alone.

What to take away

• Sell B2B if you must, but build the experience B2C. One professional decides whether it gets opened tomorrow.
• Build for the practice they own, where adoption is a personal choice, not a committee's.
• Map the real working day, Excel sheet and paper slip included, before you design anything.
• Send clean signals into the systems users already have; let user demand bring partners to you.
• Experts judge a demo with their eyes. Show outcomes to users, architecture to engineers, and know which room you are in.
• Whoever has the user's eyes should decide what the user sees.
• Show the core live and accurate; narrate the future.
• Capture, review, output, insights, history is a solid first skeleton for many expert tools.
• Defaults beat features: preload the ten choices your user makes every day.
• Be honest about demo scope, and be willing to rebuild the front end from the user backwards.
• Cap your build costs early: flat plans, spending alerts, and a habit of saying before you spend.

Try this

1. Name both faces. Write down who pays for your product and who uses it every day. If they differ, list three product decisions you made this month and mark which face you were picturing for each.
2. Shadow a working day. Spend two hours in your user's smallest setting (or on a call while they work) and write every step, tool and piece of paper they touch. Circle the one step your product replaces.
3. The ten-second test. Show each of your main screens to someone from your user group for ten seconds without explaining anything. Ask what it is for. Redesign any screen where the answer is wrong.
4. Strip your demo. List everything your demo currently shows. Split it into "hard to build" and "valuable to the user". Cut anything only in the first column, or move it to a technical appendix for partners.
5. Find your defaults. Ask five users what they choose most often (items, templates, settings, whatever your equivalent is). Preload the top ten and make the common path a single step.
6. Rehearse two pitches. Prepare the same product for a user-expert and for a technical partner. Keep the outcome identical and change only the language. Notice how much of your usual pitch belongs to only one of them.