Project Kabootar: "Madam, OTP?"

Team Colossus · KEN Case Competition 2026 ("The Great Rewiring") · Track: Product Strategy · Agent: kabootar · Autonomy: L3 · Company: Flipkart (through Ekart) Rails: Delhivery (logistics) · Gnani (voice) · Pine Labs (payments)

info · If you read only this file you get the whole project: the problem, our insight, the design, the evidence, the business case and the risks. Every section ends with a link to the detailed file where your original wording, tables and diagrams live. Quoted text is the team's own wording. Plain text between quotes is a signpost. Index of all files: 00 README Index

0 · The project on one page

→ Details: 11 Strategy Narrative How To Explain It

1 · The problem

1.1 The opening, as the organisers framed it

"Packages come home all day, everyday. But the person standing at the door isn't the one whom the delivery person trusts." Deliveries and pickups "unfailingly" drag in the whole household. The OTP arrives "on the phone of the person in a meeting at the office while the delivery agent waits in front of their mother at home." Couriers "call a dozen times to ask for the location, which must then be shared on WhatsApp even though the app has always known it." People wait all day "only for the pickup to be marked 'unavailable'." Returns are worse: people "describe replying to three separate chatbots to reschedule one pickup."

The organisers' guidance on what wins: the weakest solutions "swap the OTP for an agentic handshake and relocate the friction"; the strongest "start from the emotional pain" and "grant trust to the household as a unit, since the buyer and the receiver are so rarely the same person", while accounting "for why platforms injected OTPs into their processes in the first place." Returns pickup "adds the layer that makes this opening a genuine test": "one flow that must connect logistics, voice and payments to work at all."

→ 01 Problem Statement

1.2 Evidence from real people (organisers' respondents)

• #462, Bengaluru: "my poor mother struggles with collecting otp and understanding delivery processes."
• #326, Mumbai: "often the delivery guys come during lectures, so they call me for OTP … I wish I had an assistant who can identify these call and coordinate the drop without disturbing me."
• #312, Indore: pickup "marked me as unavailable when I was home at all times, no call, no messages", then "reply to at least 3 chatbots."
• #399, Delhi: "Sharing my location with delivery partners, UC staff and the laptop repair guy despite giving it on the app."
• #85, Bhopal: a shoe return needing "find the order, check the return deadline, keep the original box … make sure someone would be home."
• #151, Hyderabad: ordering on a friend's account and "calling him regularly 4-5 days to ask him which parcel will come today."

→ 06 Your Thinking Log (full quotes, and how you tested each against the solution)

1.3 Our own research

We "talked to around 15+ people through a range of different suits": white-collar and blue-collar workers, delivery agents, students, household moms and dads, parents, house helps and security guards. Two of three delivery agents told us location is not shown 10 to 15% of the time. Field photos of a real rider's console (Delhivery tracking page, rider rating screen, "Contact consignee is pending", "Geofence not …") are on the final board.

→ 09 Final Round Whimsical Transcription §2.11 · assets in assets

1.4 The map of the problem (our whimsical)

The first-principles view: the OTP is a "metric for finished delivery to the right person" and "prevents against fraud". It has two touchpoints (shared on WhatsApp when the order is out for delivery, and used when the receiver collects the parcel). With multiple orders it becomes "a stack of delivery OTPs and not neccesarily in the numerical order of the deliveries."

Five branches of pain: 1. Buyer is not the receiver: friends, "mom and dad, who are not that well-versed in technology", maids, security guards, a friend ordering on a different account. "Usually, the buyer is pretty busy during this time." The buyer may also be unreachable. 2. Location issue: riders are local and "know many places by memory", yet "15% of the time" they don't know the buyer's location and "30% of addresses are properly structured." 3. Rider incentives: riders are paid on volume and the "penalty fees is just rupees 5" for an unsuccessful order, so marking "customer unavailable" and moving on is the rational move. Riders skip places they don't know and prefer "already known places > unkown places". 4. Refund and pickup: "in india people find it intimidating to search and raise refunds and talk to chat bots"; a wrong ticket type delays everything (the grey-versus-black blanket example); cash flow is stuck while the refund is due. 5. Channel: "lots of these conversation happen over wa. those who don't have WA face a lot of problem."

Emotion layer: younger people find it frustrating ("quick and instant gratification … even 1 day of reschudling"); middle-aged people find it repetitive ("more patience but less time").

→ 03 Whimsicals Mind Maps · 10 Updated OTP Map Final

2 · The insight, and why it changes the design

"Delivery riders are the forgotten stakeholder. OTP is not just customer friction, but a labor problem. Riders waste time obtaining codes, while a five rupee penalty for missed orders incentivizes marking customers unavailable and moving on. They are local experts navigating by memory, yet location data fails 10 to 15 percent of the time, making OTP counterproductive to its purpose."

Where it lands in the design: - The rider stops being the person who chases codes. A call to the buyer happens before he arrives, so he is not "stuck at a door waiting for someone to read out an OPT … a minute he is not delivering the other 40 stops." - The rider gets a single instruction on his screen (available, leave at door, not available), and his route is rerouted when the buyer is not available. - Location is saved once (the WhatsApp location, then "permanently added in the persons history") and "incentive the delivery agent - for good behaviour."

→ 04 Submitted Answers Q2 · 10 Updated OTP Map Final

3 · Design principles (the rules we kept coming back to)

1. The user does no work. "i dont want the user to do anything. he should not do any work. such feature don't work where the user needs to do any sort of work."
2. Do not trust the rider's own call as a trigger. "usually these delivery people don't even call, and sometimes they fake the call."
3. No live tracking. A rider does multiple pickups and deliveries, so "nothing is solved and proper eta can not be calculated", there is a privacy issue, and tracking 100 to 150 deliveries per rider live is a "huge infrastructure cost." GPS is only needed for ETA, not the physical scan.
4. India is a low-trust society. Every step has to assume fraud is possible, on the rider's side and the buyer's side.
5. Communication, not mapping. Treat delivery "as a communication problem rather than a mapping problem" (the IVR document).
6. Embed, do not build an app. "nobody is going to download a delivery otp app, thats basically a feature pretending to be a product."
7. Confidence-gated autonomy. The agent acts alone only when it is sure; otherwise a human (the rider) is the fallback.

→ 06 Your Thinking Log · 07 IVR Reference and Rail Facts

4 · The solution: kabootar

4.1 What it is accountable for (Q1)

• Voice agent: understanding the context of the end user: whether he is available, whether family members are picking up, whether he wants to reschedule, and passing that to the delivery agent.
• Logistic agent: "removing the friction caused by OTP" (and the same for returns).
• Payment agent: "Automatic payment for COD when the buyer is not available."

4.2 The three agents and what each contributes

Voice agent: calls beforehand for availability; analyses sentiment ("if he seems confused or not"); holds the data about his specific order; understands the state of the user (he or alternates available, leave at the door); decodes speech in "low connectivity and noise environment". The call shows caller ID as "delhivery agentt" in the story (a Flipkart/Ekart ID in the Flipkart version).

Logistic agent: generates one QR per waybill, sent as a picture on WhatsApp rather than a link; triggers the voice call; keeps the dynamic route optimised; saves the WhatsApp location to the user's history; for leave-at-door, takes "the picture of the parcel at the door"; for multiple orders for the same customer, combines them into one QR with each barcode in the metadata and the rider scans each box plus the QR; for returns, takes a picture of the surrounding.

Payment agent: UPI Reserve Pay hold placed at checkout (agentic COD), bound to the shipment AWB, captured when the handoff checks pass.

4.3 The QR design

• One QR per waybill, "like when the order is placed instead". Scanning shows which ticket is being scanned, the way "namma metro" handles several tickets bought on one app.
• "pure and black" QR with padding, Level H error correction, larger modules, so it still works on cracked screens, glare, or a phone with a green line.
• Sent "as a picture … and not a link that needs to be clicked", over WhatsApp, to the buyer or the registered alternate.
• The rider's camera cannot be "not working": "he has to scan the barcode of the parcel regardless."

4.4 Autonomy level: L3 (Q2)

"L3 - Acts on its own inside limits somebody set. The person deals with whatever falls outside those limits."

The most consequential thing kabootar does without asking: at 95 to 100% confidence that the buyer is not available, the logistic agent reroutes the rider and marks the buyer not available; and once the doorstep checks pass, the payment hold is captured. The limits somebody set: the 80% confidence line, two calls at most, a registered alternates list, the geofence. The person (the buyer) approves only three things: the alternates' numbers, the rider's geofence, and use of the order data for a personalised call.

→ 09 Final Round Whimsical Transcription §2.1, §2.9

4.5 The end-to-end flow (day by day)

Normal flow (today, without kabootar). Day 1 the user orders protein powder on Flipkart (delivery on the 4th day); day 2 shipped to the local warehouse; day 3 dispatch; day 4 morning out for delivery and a driver is assigned; the driver stacks orders on the optimised route and calls the user: (1) buyer available and picks up: "otp and done"; (2) buyer not available but picks up: reschedule, or someone else picks up (friction), or leave at the door/security and share the OTP; (3) buyer not available and does not pick up: NDR has to be filed.

With kabootar (Stages 0 to 3).

flowchart TD
    subgraph S0[Stage 0 - Payment Setup]
        A0[Buyer selects Agentic COD at Flipkart checkout] --> A1[UPI Reserve Pay - SBMD - hold placed]
        A1 --> A2[Hold token bound to shipment AWB]
    end
    subgraph S1[Stage 1 - Alternate Capture]
        B0[Order marked out for delivery - morning WhatsApp] --> B1[WhatsApp: any alternate numbers?]
        B1 --> B2[Buyer registers alternates - mom, security, maid, neighbour]
    end
    subgraph S2[Stage 2 - Contact and QR Issuance]
        C0[Stack reaches T-5, five stops out] --> C1[Voice agent Call 1 to buyer]
        C1 --> C2{Buyer answers and confirms?}
        C2 -- Yes --> Q1[Logistic agent generates QR tagged to buyer]
        C2 -- No pickup, or unclear audio --> C3[Hold - stack keeps advancing]
        C3 --> C4[Stack reaches T-3, three stops out]
        C4 --> C5[Voice agent Call 2 - status check]
        C5 --> C6{Confirmed now?}
        C6 -- Yes --> Q1
        C6 -- No --> C7{Confidence buyer unavailable >= 70-80%?}
        C7 -- Yes --> C8[Driver app nudges DA to call - route not paused]
        C8 --> C9{DA confirms recipient present?}
        C9 -- Yes --> Q1
        C7 -- No --> D1
        C9 -- No --> D1[Voice agent calls alternates from Stage 1 list]
        D1 --> D2{Alternate answers and accepts?}
        D2 -- Yes --> Q2[QR generated, tagged to that alternate]
        D2 -- No --> E[Escalate - unhappy flow]
        Q1 --> QS[QR sent as WhatsApp photo]
        Q2 --> QS
    end
    subgraph S3[Stage 3 - Doorstep Handoff and Settlement]
        F0[DA enters 15m geofence - Agentic Safe Drop unlocks] --> F1[Scan order barcode]
        F1 --> F2[Scan recipient QR]
        F2 --> F3{Metadata matches authorised recipient?}
        F3 -- No --> F4[Reject and flag as fraud]
        F3 -- Yes --> F5[Camera PoD photo + GPS proximity confirmed]
        F5 --> F6[Pine Labs capture fires on UPI Reserve hold]
        F6 --> F7[Payment cleared - DA app flashes Safe to Leave]
        F7 --> F8[Order logged as delivered - buyer gets receipt push]
    end
    S0 --> S1 --> S2 --> S3

The story (Raj, Arjun, the shoes). Raj ordered shoes expected on day 3; Arjun is the rider. Raj gets a WhatsApp message from the logistic agent asking if he is available or if anyone else will be, and gives his mom's contact. A voice call is placed (caller ID shown as the delivery brand). The rider sees whether Raj is available, with a confidence score. Below 80%, the rider calls again and confirms. At 95 to 100% "not available", the logistic agent reroutes Arjun's route, marks Raj not available, and moves to the next address.

The voice script (draft): "hey vardhan, your order for shoes is scheduled today and the agent will come to your door in an hour, are you available or any one else is available on behalf of you, should we leave it at the door?, reschedule it some other time you are available today or tomorrow?"

→ 09 Final Round Whimsical Transcription §2.6, §2.9, §2.10 · 05 Voice First Solution

4.6 ETA without live tracking

Live tracking gives "a false perception to the end user that the rider is nearby" and is expensive. Instead: - Trigger on the previous stop: after the last delivery is recorded (success or failure), the next buyer gets the message or call "hey our delivery agent is near, will come in 10-15 mins". Limitation we named: "we are just giving a max 15-20 min prior update. is that enough?????" - Stack-position trigger (final design): calls at T-5 (five stops out) and T-3 (three stops out). - Longer lead time: "calculate the t-10 order … 10 more orders and each order takes 10mins on avg then we just do 10*10 which is 100mins" and give a time estimate, "simply based on logic system." The voice-first idea of calling "an hour ago or like a km ago" fits here.

→ 09 Final Round Whimsical Transcription §2.4

4.7 The three availability states (voice-first design)

After the automated call (IVR or conversational voice agent), the buyer's answer is classified as available, not available, or leave it at the doorstep: - Available: "np", delivery proceeds. - Not available: reschedule; if the call goes unanswered twice, reschedule: "its a advantage for us because the delivery guy wont go to his location and will know before hand." - Leave at the door: no QR for this: activate GPS and take a photo ("that picture with cryptographic agent solution") or a proof video, since "taking accountabilty usually decreases fraud and theft".

Simulation fix we wanted for the final version: when the buyer says "i am not available leave at the door", the agent should not refuse; it "should tell okay and send a confirmation of leaving it at the door with a picture."

→ 05 Voice First Solution · 09 Final Round Whimsical Transcription §1.2

4.8 Returns

Return reasons: size, colour, wrong item, broken, not happy; the policy can be "no return". Today: schedule on the Flipkart app, answer a lot of questions, a return is scheduled; if the rider doesn't come, the buyer either raises a new ticket and "talk to all the chat bots", or reschedules on WhatsApp; if the rider comes, he may refuse (mismatch, wrong item, used item) or collect, photograph and inspect. With kabootar: voice and WhatsApp replace the chatbot loop; the logistic agent sends the QR and the pickup availability message; the rider takes a picture of the surroundings, or "a 3-5 second video of the premises" through the app (not saved on the rider's phone, sent to the buyer on WhatsApp) as proof; the voice agent helps the buyer raise the right ticket (return policy, how to raise the correct ticket, steps) instead of "multiple chat bot interaction".

→ 09 Final Round Whimsical Transcription §2.7 · 05 Voice First Solution · 03 Whimsicals Mind Maps Map D

4.9 Unhappy flows (what we planned for)

5 · Rails: what exists and what we need

5.1 Gnani (voice)

What exists: STT (REST up to 60 seconds; realtime WebSocket with PCM), TTS (timbre-v2.5; REST, SSE streaming, realtime), voice cloning (vachana-vc-v1), language code e.g. hi-IN. What we layer on top: dialog logic (barge-in, silence handling, graceful degradation), a confidence score on "available / not available", sentiment signal (the Gnani quick start documents none), and telephony through a cloud-telephony partner (the IVR document names Twilio, Exotel, Knowlarity).

5.2 Pine Labs (payments)

Role: "a release role, not a collection role": dormant until the doorstep checks pass, then captures the pre-placed hold (UPI Reserve Pay) and releases refunds or payouts for low order value. Assumption we recorded: COD "can't be solved using payment agent, because if it were then the user would had pre paid"; the final design resolves this by agentic COD, where a hold is placed at checkout and captured on a verified handoff.

5.3 Delhivery / Ekart (logistics)

Owns the QR, the dynamic route, the stack order, the ETA by sequence, the address-pin memory, NDR with reasons ("cross referenced to the call logs and location logs"; a rider who "did not spend enough time at a location or did not place a call … is flagged as fraud"), and the rider app.

5.4 The missing capability we say we innovate on

Logistics: a reusable, person-bound, proximity-locked QR badge (Round 2 design: "issued once per household member and valid across all future orders and logistics partners", unlocks "only within a defined geofence"); in the final design, a QR per waybill tied to an authorised recipient list plus the predicted ETA by stack position.

5.5 Fourth rail

A consumer AI / personal assistant on the user's phone. The delivery issue is "a live data and context mismatch problem": the rider doesn't know if the buyer is busy or where he is. All of it (WhatsApp messages, GPS, DND, calendar) lives on the user's phone. This rail would send the buyer's live status, trusted people who can accept the parcel, and "a message from the other person saying that he received the order", confirming delivery and "no fraud case." Indian builders we named: Cred, Zerodha, Swiggy ("concierge agent"); no Indian company is currently building it ("muse, instinct, poke are all western"). Other fourth-rail ideas we considered: an edge-device camera on the rider that removes the OTP by computer vision; a dynamic location-aware delivery app; telecom spam detection.

→ 04 Submitted Answers Q4, Q5 · 09 Final Round Whimsical Transcription §2.1, §2.5 · 07 IVR Reference and Rail Facts

6 · Fraud and trust (the low-trust-society question)

• Rider fraud (faking the call or the arrival): do not use the rider's call as a trigger; NDR is cross-checked against call and location logs; QR scan plus barcode plus camera PoD plus GPS proximity.
• Buyer fraud ("takes the box and goes away"): payment hold on agentic COD bound to the AWB; leave-at-door requires a photo/video; return pickup uses proof of the premises; COD "is usually done when the user does not trust the website."
• Photo-of-a-QR fraud / one QR across many orders: QR per waybill, metadata matched against the authorised recipient; rotating QR (Cult.fit-style) considered as an optional high-value tier.
• Privacy: capture goes through the app interface, is not saved on the rider's phone, and is sent to the buyer over WhatsApp. We flagged this honestly as something the judges may cross-question.

→ 06 Your Thinking Log §5, §10, §11 · 05 Voice First Solution

7 · Why Flipkart through Ekart (and why not Delhivery)

Why Flipkart: "you need three things working together at once, delivery infra with live location, a payments rail that can hold and release money on its own, and a voice layer that can actually talk to someone in their language. flipkart is the only one in india with all three right now. ekart has delivery, super.money has the upi reserve pay stuff, and their SLAP team already has the voice muscle and they have patnered with RING ai."

Why they haven't built it: "its more of an internal structure problem." Ekart's north star is "cost per delivery or RTO numbers, not otp friction"; super.money's is "transaction volume and app ranking"; SLAP's is "shopping engagement, not what happens after checkout." "this idea just falls into the gap between all of them where nobodys job depends on building it." Also: Flipkart may be focused on an IPO and quick commerce; "no one in the org would bonus in building this"; or "they are actually building this but deploying at low scale", maybe the top 20 to 30 pincodes.

Why Delhivery was our Round 2 answer to "who should have built this already": the system "works 70% of the time"; OTP issues "don't cause user churn"; "low intent problem"; public companies prioritise revenue and market share; and not wanting "to disrupt a critical and a functional component which also has high adoption." (The same reasoning applies to Shadowfax.)

→ 08 Final Round Written Answers · 04 Submitted Answers Q9 · 10 Updated OTP Map Final

8 · Business case

8.1 Who pays and how

The buyer should not pay "at the moment, the second it costs them anything the whole point falls apart." Three ways it makes money: 1. Internal savings: RTO on COD in India is 15 to 20%; every failed delivery costs reattempts, reverse logistics, lost sales; every minute at a door is a minute not delivering the other 40 stops. We measure the win as lower RTO and more deliveries per rider per day: throughput, operational efficiency, unit economics. Second-order effect: "this will drive more orders per place on flipkart therefore increasing their GMV". 2. Sell to D2C brands: Ekart has opened its network to outside brands through a franchise setup; a "verified delivery" tier as a small premium on regular COD, for brands losing money to RTO. 3. License the stack (voice, geofence, payment capture) to other logistics companies: "aws model". Other monetisation ideas on the board: premium for Flipkart Black / VIP / Plus Gold; a small extra payment like the "extra 15-25 ruppes" for COD.

8.2 What people do today and what it costs

Someone reads an OTP "out loud under pressure at the door"; for COD the buyer pays cash or UPI, or, if unavailable, "calls someone to pay" or reschedules, which costs time. The cost shows up as RTO and wasted driver time. For non-tech-savvy receivers (house help, security guard) the process is "intimidating, tedious and Repetitive."

8.3 Where it lives (three embed points, two existing apps and one channel)

• Buyer: no app. A WhatsApp number (Flipkart Saathi, Flipkart's own WhatsApp business chat) and a phone call.
• Rider: a screen inside the Ekart driver app he opens "like 50 times a day."
• COD: an "agentic cod" toggle at Flipkart checkout next to normal COD.

→ 08 Final Round Written Answers · 09 Final Round Whimsical Transcription §1.5, §1.6

9 · Go-to-market: the first 1,000 users

1. Teach the rider first. The new behaviour (QR plus the agentic call that reschedules the route) should first be taught to Ekart riders, who will initially help buyers: "manually doing this is much more effective than the voice agent calling and telling 'we are sending you a QR'."
2. One dense hub. Pick one Ekart dispatch centre in a single Bangalore pincode cluster that drives a high share of GMV. Route the first 1,000 orders through 15 to 20 riders there so the team can "sit and watch every call transcript and every geofence miss by hand." (Board version: first pick the 20% of pincodes that drive 60 to 70% of Flipkart's GMV; ten high-density pincodes such as Indiranagar, Koramangala, Bandra.)
3. Agentic COD on invite, for cohorts with high COD frequency and a known high RTO rate. They are core users and this pushes them toward power users.
4. Why people try it: nothing; "theres no opt in. its just the new default. the otp step is gone", and since it removes a chore, "close to 90% adoption on day one without spending a rupee on marketing." Trigger idea: an order not delivered and the rider marked the customer available.
5. Why they stay after three weeks: buyers: "a few deliveries quietly going right, especially that moment where mom picks it up because the whatsapp message caught it early." Riders: "money and time, less standing around at doors, fewer failed drops."

→ 08 Final Round Written Answers · 09 Final Round Whimsical Transcription §1.7

10 · Risks, open questions and how we answer them

10.1 What could kill it in year one (our list)

1. Regulation. RBI wants an extra factor of authentication for digital payments; "geofence plus a photo equals approval" may not meet that bar, which would force a manual tap and "kill the whole point." (The delivery-OTP and payment-authentication rules were explored in the OTP history.)
2. Quiet false negatives. If confidence scoring is off, "it starts marking people as unavailable who were actually home, which pushes rto up instead of down." Mitigation built in: the 80% gate and the rider's manual call.
3. Internal politics. "whoever owns this thing across teams can easily get deprioritized the moment theres a reorg", leaving "a good pilot with no clear long term owner." Also the risk that the gap versus plain OTP is not big enough.
4. Token cost. Voice STT, TTS and the LLM are charged per minute or token; "two calls per order minimum, sometimes three if it escalates"; a small price rise multiplied over millions of calls could exceed the savings. Counter: swap to open-source models behind the API endpoints. Assumption: onboarding of the rider through marketing and training "is done properly."

10.2 Open questions we are keeping visible

• "what makes you think we will have the history of who" picks up? Nobody logs it.
• The buyer is "in a very important meeting" and there are no alternative numbers.
• Does recording or sharing a photo/video "invade the privacy"? Is "not saved on the delivery agents phone … sent to the buyers' phone over WhatsApp" enough?
• Is a 15 to 20 minute prior update enough? (The T-5 and T-3 design is our answer.)
• Operator checks to confirm with Delhivery/Ekart people: route optimisation (our board says "they are dynamically route optimised"), whether COD needs OTP ("yes if the aov is high … or open box delivery"), NDR reasons, and why ETA tracking hasn't rolled out.

→ 09 Final Round Whimsical Transcription §2.2 · 05 Voice First Solution §C · 06 Your Thinking Log §13

11 · Round 3 deliverables checklist (so nothing is missing)

12 · Evolution of the solution (how we got here)

1. Round 2, version 1: the Delivery Concierge Agent. Household QR badge, 2 to 3 m geofence, voice priority list, payment release; builder named Delhivery for the "should have built" question. → 04 Submitted Answers
2. Voice-first rethink. Call about 1 hour or 1 km before; three availability states; photo or video proof; recognised that this "breaks the qr" when nobody is home. → 05 Voice First Solution
3. Rail research and operator questions. IVR practice in India, Gnani quick start, Delhivery docs. → 07 IVR Reference and Rail Facts
4. Round 3 final: kabootar at Flipkart/Ekart. QR per waybill, agentic COD, T-5 and T-3 triggers, confidence gate, alternates captured the same morning. → 08 Final Round Written Answers, 09 Final Round Whimsical Transcription

13 · Why this team (Q1)

"Colossus." Viraj: "Mom struggles with deliveries; Dad travels constantly and is unreachable." Vardhan: "Grandmother struggles with technology and awareness." "We excel at second order effects analysis." Part of the GrowthX community, which will validate feasibility with industry leaders. Plus 15+ conversations with the people who live this problem. We chose Product Strategy over Product Build, because the task is to "present their solutions and test them against what each rail can actually do today". → 04 Submitted Answers Q1 · 02 Round2 Brief and Questions

14 · The sub-documents

The boards

Whimsical: the Madam OTP mapWhimsical: the insightWhimsical: the first OTP mapFinal board 1: simulation and businessFinal board 2: questions and flowsFinal board 3: the updated OTP map

Submitted answers (PDF) ↗ · IVR research (PDF) ↗