While in a normal sector, a wrong idea costs a few months of effort in code, in healthcare, it costs a clinic, doctor contracts, and trust that takes months to compound. So 2070 does the idea search in-house before the founder even joins.

How it works

W Health is the fund. Its Fund I backed existing companies like BeatO, Wysa and BabyMD. The ₹700 Cr Fund II is earmarked for 8–10 companies, focussing on single-specialty care (exploring longevity, geriatrics and chronic pain) and AI-enabled B2B services across the US and India.

2070 is the studio. It builds companies in white spaces, such as Everhope (oncology, with Narayana), Nivaan (chronic pain), Elevate Now (weight loss) and Reveal (AI services for US healthcare). The fund finds and the studio builds. Both run the same filter: a clinical problem where care varies wildly and a protocol can narrow the gap.

The flywheel

1. Find a gap: Hundreds of ideas are screened for clinical validation, scalability and willingness to pay.
2. Test before committing: A team of clinicians and builders experiments first, before building out the team and the platform.
3. Launch on a shared platform: About 40 people cover engineering, regulatory, clinical partnerships and talent. The first patient comes in about 53 days (as per podcasts I found online).
4. The team runs the clinic and the learnings flow back to the studio.

My two cents The product here is the protocol, not the app. In oncology, pain and paediatrics, the gap between doctors is the problem. Software's job is to make the protocol survive the average doctor in the tenth city.

The idea validation and initial building journey are done more by the studio's network and the brand, while the founder inherits the result when they are immersed in the idea. Does it hold without them? At Favcy Venture Builders I saw that studio-seeded ideas rarely pivot and have a harder fight than a normal startup to prove themselves once they've invested sizeable time building it out. In healthcare this can lead to a lot of sunk cost, so I believe stop rules have to be built in much earlier in the journey.

While most of the information and learning flow is from the studio to the startup, ideally it should also flow back to close the loop, so that one company can learn from the mistakes of its predecessor and the flywheel improves over time.

Outcome data is the compounding asset. Every clinic can double as a data source that tells the next pick what works and gives payers something to pay against. At Visit Health we launched close to a dozen healthcare products ranging from cashless OPD, medicine delivery, diagnostics, vision care, dental care, geriatrics, women's care, physiotherapy, dermatology, minor procedures, reimbursement, annual health checkups, policy underwriting, and more. Each product manager owned multiple such products, with the information being shared each week with the entire product team so that the learnings compound and success in a particular service can be utilised or improved further, or tested out in another.

———

My thesis and areas I'm bullish on

• Personalised, specialised care: Healthcare designed around a person's specific conditions and custom-made according to their health markers. This will only accelerate with the rise of personal agents and the democratisation of compute.
• AI on repetitive, low-judgement work: Workflows around care that have a certain element of repetition or structured care, like notes, scribes, and follow-ups, will get automated. In the US, Epic already ships its own, and I expect Indian EMRs to follow. The value is inside a care model.
• Specialty chains, especially outside the metros: Healthcare is disaggregating and, with PE money moving into the hospital platforms, operators that standardise care will be able to keep margins. A beautiful example is the new outcome-based model for doctors' pay at Even Healthcare.

🟡I played around with Claude, trying to map the Indian healthcare industry, and here is what it gave me. Map 1: today. Columns are who adopts and pays first, rows are how deep AI goes into care, colour is how crowded it is. Map 2: the next 3–5 years. Where value moves, and the ranked bets.

Near the end of our Software Product Management course, our professor asked the class to vote: is product management a shrinking profession? Eight or nine hands said yes. Ten to fifteen said it has a long shelf life.

Then he told us why he sits in the second camp, and it has stuck with me for weeks. When building gets cheap, everything around building gets expensive: deciding what to build, specifying it, checking it, convincing people, and getting it in front of customers.

That sentence is the spine of this post. Most product management takes right now come with a prediction: PM is dead, building is easy, deciding is hard, plus ten more. I want to sort them through one idea and one person who has watched several product cycles up close, Prof. Chandrashekhar Vattikuti, who co-taught the course and whom everyone calls Chandra.

It is a long one. Most of it comes from our class recordings and my office hours with him, plus his public interviews and this year's Lenny and Friends Summit talks.

Who was teaching us

Chandrashekhar Vattikuti co-taught the course this term across the Mohali and Hyderabad campuses. He is an ISB alum who spent most of his career in internet products: Yahoo, Microsoft, the property portal CommonFloor, and then InMobi, where he became Chief Product Officer and later ran its Telco Cloud business. Today he is building Gruha.ai, an AI-first take on how Indians buy homes, and he used it in class as a live case.

He also turns up in places that turned out to be useful homework. In October 2024 he was a guest on The Ken's Two by Two podcast, in an episode titled "Do we even need product managers?", opposite Paytm's product chief. Last year The Ken had him back to look at the free AI subscription bundles from OpenAI, Google and Perplexity with Indian telcos, and they re-ran that episode in August because Perplexity's free year with Airtel had started to expire. His job in that conversation was to sanity check whether those user numbers would stay once the free period ended.

That last point connects to something he said in class. He credited cheap, subsidised data for rescuing a generation of Indian consumer apps whose retention curves would otherwise never have paid back. Hold on to that, because it shows up again when he talks about what AI products will cost to run.

The funnel is moving inside the conversation

Funnels, activation and cohorts were the metrics block of the course, and Chandra's version came with warnings the usual textbook leaves out.

The first is that a funnel tells you where to start digging and never what you will find. At Visit I broke the pre-policy medical exam funnel into four drop-off points and built a fix for each, so this one landed. His rule for the digging: check that the instrumentation did not break, then segment, then find the smallest group with the worst retention and call them.

The second is about activation. Onboarding is the account, the login and the bank details. Activation is the first moment of real value, like the first cab showing up without a phone call. When marketing is paid per activation the definition gets gamed, so product has to define it from retention. His illustration was a payments app handing out ₹100 on sign up, where "sent more than ₹100 within 72 hours" became the activation event because that cohort retained at 42%, far better than people who only came for the cash.

Now the AI part, which came in the last session. Most software, he said, is an edifice: filters on the left, categories on top, and the user bends to the builder's mental model. For a lot of people that is already gone. It is a box and you type what you want. If a product is built agent-first, that box is the UI and there is no edifice. He explained why the big marketplaces are slow to get there. Someone sitting on 360 billion in GMV (his number, from memory) will not casually test a bot that might stretch search to purchase from three days to five. The upstarts have no funnel to protect.

If the edifice goes, the funnel does not disappear. My read is that it moves inside the conversation. Search, filter, view and add to cart collapse into one request, and the signals shift to task success, whether the user kept rephrasing, whether they asked for a human, and whether they gave up and retried. Those were the signals he listed for AI products, along with thumbs up or down and how far a prompt gets edited. Activation for a chat product then becomes the first answer that actually solved the problem.

The interface itself is also changing shape. He thinks the compute will always sit behind a piece of glass or plastic, whether that is a phone, a pair of spectacles or a pendant. He thinks the real prize is the next 800 million Indian users, who today are asked to learn English to use a product and who will arrive through voice in their own language. His own startup is voice-first, with a small set of grounded question families so the user always knows where the conversation is going, and the ability to start a call, hang up and come back. This further resonated in the recent Lenny and Friends Summit, wherein folks leaned on voice as the next big thing in 2027, and in big tech's product roadmaps.

Cohorts got the sharpest line. Users who tried you once, he said, take you to bankruptcy. His examples were AI toys: sunglasses on your cat's photo, virtual try-ons, the party trick that is over after one use. The same test applies to the free AI subscriptions bundled with Indian telcos that I mentioned earlier. The number that matters is the cohort curve after the free period ends. One caution from him: cohorts only work above some scale. A 2 to 3 percent move on ten million users is 100,000 people. On 5,000 users it is noise.

Prioritisation loses its denominator and keeps its politics

RICE is in every PM course, so I will skip the formula. What Chandra added was where it breaks.

Effort is estimated by whoever wants the feature, so two weeks quietly becomes eight. Reach gets nudged from 18,000 to 26,000 because nobody has the patience to disprove it. A flat 75% does not sound credible, so people write 75.85%. And confidence, in his words, is where politics hides. Any organisation where access to resources depends on something will be political, he said, which makes all of them political.

I heard the same warning from the other side at the Lenny and Friends Summit. Marty Cagan listed being naive about politics among his ten regrets. He says good product work does not win by default, and incentives and influence decide a lot of what happens.

AI changes one part of this, the denominator. Effort used to ration engineering time. Claire Vo's argument is that roadmaps were built for scarce engineering, and once far more ideas are buildable, buildability stops being a useful filter. Take effort out and what is left is reach, impact and confidence, which is judgment and politics in a table.

Chandra also added the human side to this conversation. When anyone can prototype, everyone in the room believes they can choose better than the PM: the head of engineering, the head of ops, the neighbouring PM. And the most dangerous person in that room, he warned, understands cognitive biases and uses them on you. Spot a recency bias, drop a few nuggets days before the meeting, reinforce them in the room, and you are aligned before anyone argues. His advice was to be wary of those people and to build your own defences by being self-aware or maybe use these to your advantage, depends on the situation you're in I guess :D

The skill that comes out of this is saying no to something that is cheap to build and defending the no in a room full of prototypes. Lenny put the day's lesson in one line: it has never been easier to build something nobody wants.

Specs are written for agents now

Specs used to be written for human consumption. The good PMs wrote them carefully, kicked off the meeting and walked everyone through. At Amazon, Chandra pointed out, people read together in silence for the first fifteen minutes. The point of a spec was to get a room of people to understand the same thing.

That is changing, and he put it bluntly. Everyone is throwing AI slop grenades at each other. Hand ChatGPT a template, get a seven-page document, forward it. The engineer pastes it into his own ChatGPT, the designer pastes it into a Figma generator, and the old question of whether you are persuading a person or feeding that person's agent is up in the air. The cost of this, as Chandra described it, is that the person who generates the material skips the thinking, and the reviewer pays for it.

So write a good spec and hope a person reads it, while accepting that more and more specs are written so an agent can do its job. An agent punishes vagueness faster than a colleague does, which makes being articulate a PM skill with a price tag.

Two of his examples show what articulate looks like. "Checkout should be fast and reliable" is a real line he has seen, and people have survived on lines like it. The version that works says the 95th percentile transaction should finish in under four seconds on a 4G connection, because then you know what good and bad look like. The other was "fix the checkout", also real. A PM wrote it and left for a wedding. By the end of the week design had spent two full days in workshops redesigning the flow and borrowing from Stripe, because nobody had said which class of problem needed solving.

Before any of that, he wants us to write a pre-mortem of what we're building. Before you launch anything, write down the ways it might fail, then go and reduce those chances. It belongs in a good spec next to the problem, the persona, the goals and the non-goals, and an agent can use it as a checklist as readily as a person can.

Then came the sentence. Whether you like it or not, he said, and he is not comfortable with it himself, a lot of our competency will boil down to the ability to articulate instructions, guardrails and evaluation criteria for AI agents to do their job. He called that the new definition of work and told the room to get comfortable being well-paid AI agent orchestrators.

The eval is the spec

The last session took that idea into AI products. His framing was that you are not shipping a behaviour, you are shipping a distribution of behaviours. Same prompt, three runs, three different answers. A normal product has a checklist and a list of severity-one bugs. An AI product has a spread, and someone has to draw a line and say that everything to the right of it is good enough to ship.

Hence the sentence he asked us to take away:

If you cannot write the eval, you have not specified the requirement.

What I liked is how unglamorous an eval is. You pull a few hundred, or if you are patient a couple of thousand, real user messages. You read each response and mark it yes or no on whether it solved the problem, because he said most teams have moved from 1 to 5 scales to simple yes or no. You set a launch threshold and run it again after every change. People at the big AI labs, he said, sit on anonymised traces doing exactly this, and many of them are junior.

His credit card example makes it concrete. One user asks for last month's bill and the bot answers, so that is a yes. Another asks whether the purchase she made thirty minutes ago has been charged. The bot is not grounded in recent transactions, so it makes something up, and that is a no. Do that across enough messages and you have a distribution. To do it at scale you let an LLM act as judge, which he compared to a nightly regression, and you keep humans in the loop for every major and minor release.

Two more stories from that session. In the first, one model gets 94 of 100 answers right but commits one stark false positive, calling a tumour that is not there. Another gets 92 right and never makes that mistake. You ship the second one every time, and the eval is how you write that choice down. In the second, you swap in a newer model that wins on every benchmark, and escalations to a human go from 18% to 42%. He gave that one as a hypothetical, but said it is entirely possible, because model changes shift the tone and tone decides whether a user feels helped.

He also reminded us about cost. For years the marginal cost of one more user was zero. Add a copilot and every user burns tokens. All of us, he said, are living on subsidised tokens, and at some point you realise two hundred ops people might have been cheaper. So you cache, route simple questions to smaller or open-source models, and land on his line for that section: the model is a component, and the product is everything around it.

Research is being automated from both ends

One of Chandra's demos was a persona document. He and his co-founder asked an LLM for about forty fictional home buyers with detailed journeys, including an NRI buying over a video call and a family expecting a child, and held their product up against them. He was clear that this is no substitute for the thirty or forty real customers they had actually spoken to. The synthetic set gave them breadth and speed. He also described voice bots, grounded well, that can run hundreds of customer surveys and turn the audio into insights, without the biases a human interviewer brings.

There is now an industry built on that idea. Simile, a Stanford spinout that builds AI digital twins of real people to predict how customers will behave, came out of stealth in February with a $100 million round and closed a $200 million Series B at a $2 billion valuation in July. Aaru, which simulates whole synthetic populations, has been reported at a $1 billion valuation. Others, like Listen Labs and Outset, use voice AI to interview real people at scale. TechCrunch reported in September that Listen Labs had signed a term sheet at a $1.5 billion valuation and then walked away to talk to Salesforce. The category is splitting into tools that simulate people and tools that interview them faster.

The other end of the pipe worries me more. Sean Westwood, a political scientist at Dartmouth, published a paper in PNAS describing an autonomous synthetic respondent that got past the standard bot checks in online surveys 99.8 percent of the time across more than 43,000 tests. He estimated that between 10 and 52 fake respondents could have flipped which candidate led in the major polls he examined. "We can no longer trust that survey responses are coming from real people," he said.

Put the two together and the research stack looks strange. Synthetic users can answer your questions, bots can answer your surveys, and an LLM can summarise both for your leadership. At that point nobody has spoken to a customer. Claire Vo's list of what becomes scarce starts with customer truth. Chandra's rule for funnels says the same thing: the numbers point, and then you go and talk to the smallest group where retention is worst.

My rule from this fits on a wall. Use synthetic users for breadth, to pressure-test your questions and screen a lot of ideas cheaply. Use real conversations for truth. And count how many real customers you spoke to this week, because that is the number a bot cannot inflate.

Building got cheap, so everything around it got expensive

In the last session he listed what got cheaper: documents, mockups, clickable prototypes, first drafts, summaries, meeting notes. He described people summarising a Granola summary against a Teams summary and running a meta-summary on top, with an agent turning all of it into a weekly update for the CPO. At Bing, he said, a 300-slide customer research deck once took an 80-person team a year, and something similar can now be produced for around a hundred dollars of tokens. You cannot tell which one is real.

A thorough document or a working prototype is therefore minimum hygiene, in his words not even a differentiator. When everyone is a kid in a candy store, the scarce skill is choosing which of the hundred things to build, and then landing that choice in a company where the VP of engineering, the head of ops and the neighbouring PM all think they could choose better. His rule for individual work was three hours thinking for every hour building. Convincing people and getting legal to bless your terms take as long as they ever did.

Three things became more valuable. Taste, which is picking the better of three mockups that were all easy to generate. Review, which is the last 20 to 30 percent between an AI draft and something usable. He told us about a batchmate who spent five times the effort making an AI-built interface stop looking AI-built. That, he said, is the extra mile. And ownership, because you cannot hold a model accountable. You still need what he called a throat to squeeze, and more often than not the person who sticks their neck out is the PM.

The Summit gave me a practice for the taste part. Linear runs an optional weekly feature roast where anyone can critique a new feature, nitpicks included, without it getting personal. A lead turns the raw feedback into issues, and the logic is that if people inside the company are confused, customers probably will be too. Karri Saarinen's argument was that automating execution can strip out the learning that used to come from struggling with the work, so teams need rituals that keep judgment shared. Linear's Quality Wednesday, where everyone fixes and shares one small defect a week, does the same job. Katie Dill of Stripe made a related point: built, done and good are three different states, and someone should be the named editor who decides which one a release is in.

Chandra was candid about the cost for people early in their careers. The entry rung is the risk, not the ladder. His own first year and a half at Yahoo was mundane work, pulling his own numbers, reading support tickets, grooming a backlog, work where you could make cheap mistakes. Now it is an MCP connection away. The judgment bar he once held for a senior PM he now holds for a PM. The way is harder, he said, and the door is still open.

He asked us to build our own conviction, since he has no skin in our decision. He also pointed to a data point from the day before, that only about 2.5% of households pay for AI, as a reminder that diffusion takes a long time. For his part he is slightly bullish. If writing code stops being the bottleneck, he argued, a PM who can straddle English, code and design sits in a very useful spot.

Build fast, shut faster

If building is cheap, so is being wrong, and the founders I have been reading and watching treat a product as an experiment with an expiry date.

Claire Vo made the case at the Summit. Her idea is durable convictions with disposable implementations: stay with an important problem, change the solution freely, and watch for the bad kind of stubbornness, which is moving the success criteria to justify more building. She asks teams to label every release a probe, an experiment or a promise, so customers know which one they are getting. Dan Shipper described a one or two person lab at Every that expects to discard roughly nine in ten of its experiments, with a path from lab to internal use to early customers to the product team. The Anthropic panel added a neat trick: when a project fails because the model is not ready yet, park it as an eval and rerun it when the next model arrives, since the failure may say more about the model than about the customer problem.

Chandra lives this way himself. He was candid that he is building with the next year or two in mind, and that he knows the solution may not be viable until then. If it does not work, he said, he may close it and move on to the next opportunity.

The constraint, then, is not the cost of building. It is the discipline of deciding in advance what would make you stop, and then actually stopping.

Gruha.ai up close

What makes Chandra's views credible is that he is running the experiment himself. In an earlier class he opened his Google Drive and walked us through Gruha.ai, the startup he is building.

The hypothesis goes like this. In the US a buyer's agent and a seller's agent each take a commission and sit behind a wall, so the buyer's agent only works for the buyer. Indian real estate has no such split. His bet is AI agents on the buy side and human agents on the sell side. Price negotiation and what someone plans to build next door cannot be turned into a model prompt. Plot size, orientation and how much traffic a road gets can, and he thinks a well-trained buy-side agent can get to roughly the quality of the best one you could find in the country.

The part I appreciated most was how honest he was about maturity. He set the company up to be agent-first, where the humans curate context and the agents run marketing, reports and the rest. On a scale of zero to ten, he put them at 1.5 or 2. Without AI, he guessed, they would have been a 70 or 80 person shop. In a post-AI version it might be 15 humans and 25 or 30 specialised agents. His own days, he said, are now spent cleaning folders and writing crisp markdown files so the model knows what to remember and what to forget, and he calls that a new definition of work.

Where it has worked is product discovery. From hypothesis to a design took three weeks, and he said it would have taken six months before. He also noted that code writing, which used to be about 60 percent of the time on a project, has shrunk to 20 or 25 percent. He added the caveat that you could be building in a vacuum, which is why the forty fictional personas sit next to thirty or forty real conversations.

Two warnings from him that I have in my own notes now. Hallucination is the smaller problem, he said, and sycophancy is the bigger one. You say something strongly and the model tells you it is a great point, so you have to know whether it is acting as your mirror or pushing you out of your comfort zone. The second is about the name. They went with .ai partly because they could not get the .com and it felt odd to be a post-AI startup without it, and he used that story to warn us about adding AI to a product because it helps a career or a valuation. Ask what the user is trying to solve first, he said, and if AI fits, go ahead.

In office hours the same instinct showed up in a smaller way. As I understood it, he is wary of forcing buyers into a new behaviour. If someone is comfortable with the familiar way of looking at a plot, make that better, for example by generating renders from open map data so they can picture a house, and leave the new paradigm for later.

My read, as someone who has not built in this space, is that the model may be the easiest part of Gruha. The hard parts sit around it: who pays, who carries the liability, and who a buyer trusts with a token advance. That is his own line, the model is a component and the product is everything around it, applied to his own company.

One more line from the same class stays with me. Most of a PM's day, he said, is rituals: the Monday meeting, the Wednesday metrics review, the stakeholder updates. The valuable work sits on top of that. You do not rise to the height of your ambitions, he said, you rise to the height of your rituals.

Where this leaves me

So, is product management shrinking? The version of the job that is mostly artifacts is, and quickly. Specs, decks, summaries, prototypes and survey reports are cheap now. The version that is mostly judgment is growing. Someone has to choose the problem, say precisely what good looks like, check it against real customers, and stand behind the result.

That is my working definition of a PM now: the person who owns the decision about what is worth building, and the proof that it worked. The eval is the proof. The pre-mortem is the doubt you write down first. The customer calls are the part a bot cannot fake. And shutting a product down when the evidence says so is part of the job.

I am holding myself to a short list:

• Write the pre-mortem before the spec and the eval before the feature.
• Talk to real customers every week.
• Keep a notebook of when AI output was wrong and why.
• Decide in advance what would make you stop.
• Build a portfolio where every line survives three follow-up questions.

The Summit speakers disagreed on almost everything else: whether PMs should code, whether roadmaps survive, whether the role grows into general management. I find that reassuring. If the vote were today, I would raise my hand with the second group, on one condition: that the job is the judgment half.

That's what happened when I traveled to Sikkim as part of ISB's SEED program - a rural immersion where you spend a week with a state's stakeholders, identify a real problem they're facing, and pitch a technology-driven solution directly to the government. This year, Prof. Chhatre and Prof. Vishal picked Sikkim. The context: over the last 20 years, Sikkim has turned its entire agricultural sector organic - a total ban on chemical fertilizers and pesticides, across the whole state.

I didn't fully believe that until I saw it.

The 20-year bet

Sikkim didn't get here overnight. The government spent the first decade convincing farmers to abandon fertilizers and pesticides they'd used for generations. It spent the second decade helping them sustain that shift - building the support systems that let organic farming actually pay.

Going organic isn't free. Yield drops. Pests and insects that used to be controlled chemically come back. Farmers we spoke to were candid about this - and equally candid that they'd rather take the hit than go back. When one of us asked why not just reintroduce pesticides, the reaction was closer to offense than debate. They wanted to leave healthier land for their kids, even at a cost to themselves today.

Over four or five days, we sat with the agriculture department, the Krishi Vigyan Kendra (the state's agricultural research and extension body), Farmer Producer Organizations (FPOs), Farmer Interest Groups (FIGs), and farmers themselves, across wildly different terrain - Sikkim's climate shifts fast enough that farmers a few valleys apart grow completely different crops: paddy, wheat, chili, tea, maize, soybean, papaya, kiwi, cucumber, tomato.

How the system actually works

The structure is more sophisticated than "farmers plus government":

• Farmers range from tenant farmers working someone else's land, to smallholders running 8–10 crops on 0.3–0.4 hectares through integrated cropping, to larger landholders growing for export.
• FIGs (Farmer Interest Groups) are geography-based clusters of farmers who coordinate with local officials on shared concerns.
• FPOs (Farmer Producer Organizations) sit above several FIGs - registered societies of 200–300 farmers, run by an elected board and president.
• The agriculture department runs schemes through this structure: one-family-one-entrepreneur, one-family-one-government-job, free seeds, free tools, custom hiring centers, and more, with dedicated department staff assigned to each FPO and district.

What surprised me most: the benefits actually reach individual farmers. Almost everyone we spoke to was genuinely grateful for what the government had done for them - a reaction I didn't expect going in. And the FPO boards run entirely without salary. Directors work full days for their community's benefit, for nothing.

The people behind the numbers

Sikkim is full of individuals who look nothing like the farmer stereotype most of us carry from north Indian agriculture.

Dr. Chewang Bhutia, a veterinarian by training, built Crafted Fibers - a business reviving a nearly lost craft, weaving textiles from local wool to support Sikkim's traditional artisans. He's since been recognized by the President of India and has presented the work at international conferences in the US and UK.

We also met the women who run local produce markets near Gangtok - not just selling their own crops, but their neighbors' too, and pushing to build an actual brand around it: packaging, labels, honey, wine, baked goods, handicrafts. One of them had traveled to Hong Kong to study how markets work, then came home and started running Facebook ads to bring buyers to her village market.

And there was an FPO president, 80 years old, who has been organizing her village around organic farming since 1999 - two decades before the state made it official policy. She's still running market research, negotiating better prices for off-season crops like cabbage, and pushing for better seed varieties. Her energy at 80 put most of us to shame.

What's actually broken

The gap in Sikkim's model isn't charity or more advanced technology. It's two specific, fixable problems.

First, labor. Sikkim has limited arable land to begin with, and a meaningful share of it sits unsown for lack of hands to work it.

Second, and less obvious: farmers often skip FPOs and sell independently, even at worse prices, because FPOs pay them less than the open market. Two reasons drive this:

1. FPOs take roughly 20–30% off the top to cover administration, logistics, and branding.

2. Selling in small quantities directly to buyers sometimes fetches better prices than the bulk rates FPOs negotiate.

Our read on why: FPO boards are elected from within the farming community, so they're farmers first - not necessarily people with the commercial instincts to negotiate hard with corporate buyers. Sikkim clearly has outliers who can do both, like Dr. Bhutia and the 80-year-old FPO president. But building a state-wide model around outliers doesn't scale.

What we proposed

Our suggestion to the government: give every FPO a hired position - an entrepreneur-in-residence with the business background to negotiate corporate pricing and build the FPO's brand, rather than relying on elected farmer-directors to do it themselves. It's a role that could pay for itself many times over given how much margin currently leaks out of the system.

One thing that made this idea more urgent than it might sound: younger generations in Sikkim aren't rushing back into farming, a trend that's not unique to the state. But where farming visibly generates real income and dignity - as it increasingly does in Sikkim - that trend seems to bend. A well-run EIR-backed FPO could be the difference between farming, staying a fallback and becoming a career someone chooses.

To support this role, our team prototyped FPO Sahayak - a dashboard meant to sit on top of the communication channel FPOs and farmers already use. That channel, worth noting, is WhatsApp voice notes: farmers message FIGs, FIGs message FPOs, FPOs message the department, almost entirely by voice. With a board of 10–15 people managing decisions for 300+ farmers, that's a lot of voice notes to triage manually - and a genuinely good use case for the voice AI tools now available.

We were one of eight teams presenting to the Sikkim government that week, each with a different angle on the same underlying opportunity.

The bigger picture

Sikkim isn't a perfect system. It can't yet grow enough to fully sustain itself, and the FPO pricing problem is real money left on the table for farmers who already took the harder path. But the mission itself - a state government and its farmers holding a 20-year commitment to healthier land, together, without either side flinching - is rare enough to study closely.

If India is serious about scaling organic agriculture, Sikkim isn't a curiosity. It's the working model, and one worth learning from before deciding it's out of reach for anywhere else.

Thank you to the Indian School of Business, the professors who ran SEED, and every stakeholder in Sikkim who gave us their time. More reflections from my time at ISB soon.

I was charged with shipping Cashless Physiotherapy end-to-end from a blank slate to production as soon as possible and this is the story of how that happened.

The directive

It started in June 2025 with a call from our MD. The message was clear: some of our largest insurance and corporate partners had been asking for cashless physiotherapy as a value-added service for their users. We already had a reimbursement flow for physio sessions, which gave us a decent proof-of-concept that demand existed. The ask was simple — build the cashless module and go live as soon as possible.

Simple ask. Not a simple build.

Why this was different from anything we'd built before

Before I get into the journey, it's worth understanding why this wasn't a standard feature launch. Visit Health isn't a simple consumer app - it's a multi-sided platform. Every service line we ship touches at least five different user types, each with their own interface:

The end user booking and attending sessions through our consumer app. The physiotherapist partners managing orders, uploading session plans, and raising invoices through our partner dashboard (Kea). The in-house doctor team verifying and digitising prescriptions through their own panel. The operations and support team managing the entire order lifecycle through an internal dashboard. And the insurer or corporate sponsor who's paying for the service and needs documented proof of every session before they release coverage.

Each of these functions has different needs, different interfaces, and different definitions of "done." My job as the PM was to hold all of these in my head simultaneously and make sure the end-to-end flow was seamless - not just for the user, but for everyone who touches the order behind the scenes.

Scoping: the long game of alignment

We set up a cross-functional call — operations, network, support, the doctor team, tech, product, and design — all department heads in one room. The goal was to map out what the journey could look like.

Multiple rounds of discussion followed. Our MD walked us through what clients were expecting. The in-house doctor team, explained how physiotherapy bookings typically work and what the clinical flow should look like. The network team, who had already been exploring partnerships, helped us understand the provider landscape - who we could partner with, what the market looked like from a physiotherapist's perspective.

On the basis of all this, I went deep into designing how the journey should work - finding the right sync between what the physiotherapist wants, what the doctor needs, what the user expects, and what the sponsor requires for compliance. We mapped the entire flow in Lucidchart and floated it across leadership and all stakeholders.

This alignment phase took a couple of months. Different versions, different iterations, constant pushback. That's normal. What I learned is that the scoping phase for a multi-stakeholder service line isn't a single meeting with a whiteboard - it's a sustained campaign of getting everyone to agree on what "the journey" even means.

Designing without a playbook

Once the flow was finalised on paper, we moved to the design team. I sat with our designer daily for close to a week. We looked at inspiration, studied how other players were approaching digital physiotherapy, and found something interesting — there was no aggregator in the market offering cashless physiotherapy as a benefit to sponsors or insurers. We were essentially a first mover.

A couple of standalone physiotherapy apps had a digital play, so we studied their UIs and flows. But their context was different — they were single-sided consumer apps, not multi-stakeholder platforms. We had to design from first principles.

The first iteration of the consumer app designs went through the same gauntlet — back to every stakeholder for review and approval. This cycle took another couple of months, with multiple iterations. Then came a demo with the MD & CEO, who liked the overall journey but wanted the UI to be more salesy — he wanted the interface itself to nudge users toward booking more sessions, rather than relying on the ops team to drive utilization.

So we went back to the drawing board. Full design revamp. New screens from scratch. A journey that was more inviting, easier for the customer, with simpler operational flows. This was painful but it was the right call — the second version was meaningfully better.

The multi-interface build

Once designs were locked, we moved to engineering. Backend developers, Android developers, iOS developers, web developers - each needed to understand the full journey, not just their slice of it.

The build order mattered. Backend had to go first - APIs, database architecture, the session model, pricing logic, OTP verification for consultations. Only then could the mobile and web teams start building against real endpoints.

Meanwhile, I was simultaneously working on:

The partner dashboard (Kea) - where physiotherapy centres would accept orders, upload session plans, manage appointments, and raise invoices. This needed its own set of designs, its own set of stakeholder reviews, and its own onboarding guide.

The operations dashboard - where our internal team manages every order lifecycle, handles exceptions, and coordinates between users and partners.

The doctor panel - where our in-house doctors verify prescriptions and digitise them before the user can proceed to booking.

Network onboarding - working with the network team to map physiotherapy centres, their session pricing, available packages, and service areas. This involved a master price mapping sheet, partner-specific billing headers, and a phased onboarding plan.

Communication templates & amplitude events - every touchpoint in the user journey needed templated communications across email, SMS, and push notifications along with tracking events setup for us to analyse user behaviour.

The messy middle

Here's the part that doesn't make it into case studies: the messy middle.

We encountered bugs while testing the journey. Calls got cancelled. Timelines slipped. There were days when the entire team was debugging auth token issues on iOS while simultaneously trying to finalise the pricing logic for a partner who needed to go live that week.

The ops team tested the journey and came back with a list of detailed feedback — everything from "the logo of the centre should appear alongside the name" to "the disclaimer on cancellation is not mentioned" to "during the centre selection stage, the amount to be paid was shown as zero." Each of these was a real usability issue that would have broken the experience if it shipped.

This is the phase where the PM's job shifts from designing the system to defending the quality bar. You're triaging bugs, prioritising what blocks launch versus what can ship in v1.1, coordinating across four engineering pods, and writing Amplitude event specs so that you can actually measure what's happening once users start flowing through.

Going live

Cashless Physiotherapy went live on production for Android and iOS across several large corporate and insurance sponsors in early 2026. The web app followed shortly after once the remaining bug fixes were resolved.

What I took away

Alignment is the actual product work. The most time-intensive phase wasn't design or development — it was getting a dozen stakeholders to agree on what the journey should look like. That's not overhead; that is the job.

Multi-stakeholder products are a different sport. Designing for one user type is hard enough. Designing for five — each with competing priorities — requires you to hold the entire system in your head at all times. The user wants simplicity; the insurer wants documentation; the partner wants flexibility; the ops team wants control. Your job is to find the design that serves all of them without being a compromise for any of them.

Ship the ugly version. The first design we built was fine. The CEO's feedback to make it more engaging felt like a setback at the time, but the second version was better in every way. Sometimes going back to the drawing board isn't a failure — it's the process working as intended.

The messy middle is where the product gets made. The Slack channel for this project had hundreds of messages — session plan discussions, pricing debates, bug reports, partner onboarding questions, Figma links, meeting minutes. None of it was glamorous. All of it was necessary.

I'm proud of this one. Not because it was smooth — it was anything but. But because we built something that didn't exist in the market, across five interfaces, with a team that figured it out as we went.

This is that corner.

What you'll find here

Notes on building products at Visit Health, lessons from shipping side projects like Fitin Club and Reccos, the occasional rant about design systems, and a lot of thinking in public about what it means to be a non-technical founder in 2026.

How this is built

Every post you read here started as a markdown file in my Obsidian vault. I write. I hit save. A tiny script notices the new file and my website rebuilds itself overnight.

No CMS. No editor UI. Just text → git → live.

That's the kind of plumbing that makes writing feel lightweight again.

More soon.

You had ideas. Someone else had the keys to the kingdom. You waited, negotiated equity, wrote specs that got half-understood, and shipped things that looked nothing like what lived in your head.

That era is over.

Taste is the new moat

When anyone can generate a React component in thirty seconds, the bottleneck stops being "who can build it" and becomes "who knows what's worth building." That's a taste problem. A systems-thinking problem. A customer-empathy problem.

Those are exactly the muscles a good PM has been training for years without realising they were training for this moment.

What I actually do now

I think in flows. I sketch in Figma. I write specs in plain English. Claude turns them into code. I read the code, push back where it feels wrong, and ship.

The work isn't coding. The work is having a clear opinion about what the thing should feel like — and being able to hold that opinion steady through every step of implementation.

The catch

You still have to understand enough to smell when something is off. A URL in a query string. A database without indexes. A component re-rendering on every keystroke. You don't need to write the fix — you need to notice it exists.

That's not technical debt. That's technical literacy. And it's cheap to acquire if you're paying attention.

What this means

If you've been sitting on an idea waiting for a co-founder, stop. The co-founder is already in your laptop. Your job is to bring the taste.