• A browser game where children aged 10 and above work out how Eratosthenes measured the Earth, by answering his questions.
• Play ↗

• Children learn great discoveries as facts: simplified, with the details left out.
• They miss the leap behind the idea, and the details that had to be worked out.
• I believe working through a discovery would change how children see the world and the problems in it.
• So I built a way for them to work through one discovery themselves.

• Defined the core:

  • a Socratic, question-and-answer chat
  • the stages of the problem for four age groups, with their props and hints
  • hand-written exchanges for every stage

• Refined it with the agents, playtesting as we built.

• Directed the build with two agents that shared one changelog:

  • a design agent: UI and UX, copy, dialogue, props, animation, simulated test sessions
  • a coding agent: the game, the server, the tests and the simulated test runs

• Had the code audited against the design.

• The aim: the game is a starting point, not a course. It builds the intuition to connect what a child already knows to a problem that seems unrelated.

• The issue: a language model writing replies from a script revealed answers and invented questions.

• The decision: given the narrow scope, I wrote every reply by hand.

  • Code settles clear answers ("shadow", "50").
  • A small model (Claude Haiku) judges the rest against 11 fixed verdicts.
  • Two low-cost models screen messages for prompt injection and off-topic requests.

• Quality first: quality set the design. Cost stayed low because a model is called only where code can't decide.

• The trade-off: replies vary less, with only minor variations.

• A 3D world with a chat, and stages set by the child's age.

• Interactive props let children test shapes and angles and see what changes.

• Hints that get more direct. Each wrong guess brings a more direct hint. The last is too obvious to miss. If it is missed anyway, Eratosthenes gives the answer and moves on.

• Recorded conversations. Every conversation is recorded for review, to improve the game.

• LinkedIn is good for finding jobs and gives a basic fit check, but it isn't enough.
• Looking for product roles from Bengaluru, open to anywhere, meant reading dozens of listings a week to find the few I'm aligned with.
• Most fall short somewhere:
  • the role isn't relevant
  • I'm not the right fit for it
  • I don't share the company's purpose
  • the cost of living is too high for the salary
• The few that pass need a couple of hours of research before I decide to pursue them.
• So I wanted a workflow that does the filtering and research for me, so that my hours go only where they're valuable.

• Defined the stages of the job hunt. Each stage decides one thing, by a rule of its own.

• Built them as n8n workflows:

  • Three ways in: LinkedIn alert emails, a screenshot of any listing I come across, and a daily automatic search.
  • The stages: a relevance check, fit analysis, company research, and a brief that combines the job, the fit and the research.
  • A cover-letter chat that works from my CV and matches the tone of letters I wrote by hand.

• Had the web app built: I wrote the requirements and had a coding agent (Claude Code) build it in 14 phases, with checks against my live job sheet along the way.

• Why a workflow: an AI assistant, in a chat, could have done most of this. Two things made it a workflow: LinkedIn alerts arrive automatically and should be processed without me, and I wanted to explore a no-code tool (n8n).

• Cheapest checks first, so the costlier ones only see the jobs that pass:

  • Before any model judges a job, keyword filters drop irrelevant postings, and a duplicate check drops any job already on my list.
  • A small model (Claude Haiku) checks relevance against my experience: my design years count toward total industry experience, not toward PM experience.
  • Only relevant jobs reach a larger model (Claude Sonnet). It looks up salary and cost of living where the job is and estimates what I'd save in a year. That number answers whether a move is financially viable.
  • Company research, the costliest step, runs only past a 75% fit gate, and once per company. It is reused for every job there.

• I decide at each step that matters: a held job waits for my approval, a cover letter is written only when I ask for one, and a rejection-feedback email is drafted, never sent.

• A web app with the strongest matches on top.

• From match to application: I review a job, move it to the cover letter, and mark it as applied.

• Replies: the inbox reader follows each applied job. A reply moves the job to interview or rejected. A rejection that invites questions gets a feedback email drafted for me to review.

• Jobs waiting for me: jobs that stopped at an earlier step wait in their own sections. One tap moves any of them forward.

• For scale: of the 12 jobs the pipeline has screened, 5 weren't relevant, 3 stopped at the fit gate, and 4 reached a brief.

• Company research: 30–40 minutes instead of a couple of hours, depending on the domain and how well I know it.

• Choosing between jobs: simpler, because the facts I compare are in one brief per job.

• Skimming irrelevant listings: close to zero time.

• Tracking: I can see each job's stage and decide its next step.

• Friends take photos of each other at trips and events, then the photos sit in one person's gallery.
• Sharing means picking, sending and asking, so most never get shared.
• PicSee found the friends in each photo with face detection on the phone and sent the photos to them automatically.

• Defined the vision with the CEO and scoped the MVP.
• Refined the designs into complete flows, within his design direction.
• Set up launch metrics with the data analyst.
• Used post-launch data to decide what to change and build next.

• Hypothesis: sharing should be the default, not a task, and photos should stay off the cloud, unlike other photo services.

• How it worked: once the app found the friends in a photo, it notified the sender and sent the photo 24 hours later, or sooner if the sender chose.

• Safeguards, because photos went out without a tap:

  • the 24-hour notice
  • sending only to connected friends
  • Recall, to take back any photo at any time

The launch date was fixed. To meet it, we made three decisions:

• Privacy with speed. Face embeddings were extracted on the phone, so photos never left it. That was hard to make fast, so we dropped support for some budget phones, chosen by market share.

• Parked: children under 14. The model was weaker on children's faces, and good training data wasn't available.

• Organic growth, no paid ads. A lesson the CEO, the growth lead and I brought from Koo.

• The plan. Photo exchange was meant to be the first step toward a private network for close friends and family to share everyday moments.

• No repeat use. That needed people to come back, and they didn't: the app was a vitamin, not a painkiller. People saw a photo once, then left.

• Growth fell short. The viral loop stayed below 1. A free tool for event photographers added a new channel, but it did not bring in as many new users as we expected.

• Delivery speed. Phone limits on background processing were also a constraint: we brought photo-to-notification time down to a few minutes on most phones, but near-instant delivery couldn't be guaranteed.

• The outcome. The app reached 10,000 users, but the network never formed, so the company chose to wind down in July 2026 while it still had ample funds.

• Launched in 2020 as an Indian alternative to Twitter, for people who wanted to post in their own language.
• Reached about 60 million downloads.
• Shut down in July 2024, after acquisition talks failed.

• New users chose a language during onboarding. This told us which creators to suggest, but the list was still too wide.
• People had to scroll a lot to find relevant content.
• Only 25% of new users followed anyone in their first session.
• Without follows, their feed had little that mattered to them.

• As a designer:

  • Added interest selection to onboarding, so that we could suggest creators and topics that matched what each person cared about.
  • Also designed Koo Rewards, multi-language posting and the design system.

• As a PM: led Bulk Follow, the Topics widget and the News widget from discovery to launch, with engineering, design and leadership.

• Before: Bulk Follow showed new users 50 to 100 accounts at once, and going through them was tiring.

• Proposal: show 5 to 10 at a time, with an option to uncheck accounts before following.

• The team's concern: follows drive retention and engagement, and fewer suggestions could mean fewer follows.

• Test: an A/B test with different batch sizes. Batches of 5 to 10 worked better than 10 to 15 or more.

• Result: accounts followed in the first week went from 3 to 5, and monthly retention improved by about 10%.

• Topics had been a separate page behind a banner.
• I added a compact version in the feed, where people could follow a few topics, with a link to the full page.

• Koo Rewards paid users in Koo coins, which they could exchange for cash.
• Users earned coins for spending a set number of minutes in the app, taking a set number of actions and opening the app every day.
• I designed it as part of the team.

• People did these things for the reward, not because the app was useful to them.
• When the rewards stopped, they left, and the programme had cost a lot of money.
• Paid growth had the same problem at company level: in its 2022 financial year, Koo spent about $16.5 million on advertising and earned about $650,000 in revenue.
• From this, I learned to pay for growth only when customer lifetime value (CLV) is above acquisition cost (CAC), a lesson I took to PicSee.

Koo struggled for two linked reasons:

1. 1

   The content was not diverse enough, which kept engagement low.

   • Few top-tier creators. There was less popular content to draw people in.
   • A political image. Koo was promoted during the government's Aatmanirbhar (self-reliant India) campaign, so many people saw it as linked to the ruling party and stayed away.
   • Limited reach by language. A post in one language reached only people who read that language, so creators had little reason to move from Twitter.
   • With less varied content and fewer strong creators, helping new users find people to follow was harder.
2. 2

   It ran out of time. It had to focus on earning money before its network was stable.

• Exchange Data International (EDI) is a London financial data company, founded in 1994.
• It sells financial data through APIs as subscriptions, to hedge funds, asset managers, banks and software companies.
• Buyers could start a trial and subscribe through a checkout on EDI's website.

• Only 35% of people who reached checkout completed it.
• Many asked questions on EDI's support channel instead of buying.

• We grouped the support enquiries by reason.
• EDI's team wanted to speak to buyers themselves, so we gave them our questions, and they called people who had enquired but not bought.

The calls and enquiries showed that the checkout page did not answer the questions buyers had when they were about to pay:

• How the trial worked. There was no summary of the trial period.

• Why EDI. The key benefits and differentiators were in one long page.

• How to cancel. The cancellation policy was only on the product detail page.

• EDI was a Strakin client. My senior was EDI's point of contact.
• I worked with him on design and analysis:
  • grouped the enquiries
  • wrote the questions for the calls
  • analysed the answers
  • redesigned the landing page, product pages and checkout

The details existed, but on the product detail page, away from the point of payment. We put them on the checkout page itself:

• A short summary of how the trial period works.
• The key benefits and differentiators as a few short points, not a long page.
• The cancellation policy, visible at checkout.

• Strakin's own app for people with long-term conditions such as diabetes.
• It kept their health records in one place: users added their reports and readings by hand, tracked them over time and got reminders for medicines and tests.
• Labs could also send reports directly through the app. All data was encrypted in the cloud.
• The product was already in testing when I joined. I designed the profile, report upload and report viewing flows.

Glukoin stayed in beta and did not find product-market fit:

• Too much work for older users. Most users were older people. Adding reports by hand, with little automation, felt like work, and the app was hard for them to use.

• The need was real but not urgent. People already kept paper copies of their reports.

• Labs had no reason to join. Sending reports through the app was extra work that did not fit their workflow, and many labs already used apps such as Practo, or their own flows, that did the same job. Glukoin was not a clear improvement for them. People also went to different labs at different times, so many labs had to join before a person's records were complete.