S Anand · Talks
Day 4 · 10 Sep 2026 · SUTD 日本語 All five days Transcript
SUTD DAI Signature Master Class · Expert Industry Series · Day 4 of 5

From Prototype to Product

The shortest session of the week did the least explaining and asked for the most. Twelve students had already run overnight market research with sub-agents; today's optional clinic looked at what came back, then quietly changed what "done" means: stop testing with agents you control and people you know, and go find the strangers who'll actually use it.

Remote · optional query clinic · Thursday 10 September 2026
Anand S, Head of Innovation at Straive · read the full transcript

🎧
Listen to the full clinic
Recorded live · remote · SUTD
Day 4, in panels
A comic titled 'From Prototype to Product'. Anand shows a roadmap of idea, build, test, launch. Johan asks how many times you should iterate until it's done. Anand answers: run the automated test once, maybe twice, then keep it as a regression check; persona evaluation once, but real user testing never really ends. Four personas - subtitler, delivery coordinator, student, general user - report battery drain, missing feedback, rate limits and confusion. The big loop closes: idea, prototype, agent or human feedback, revision. Then the comic turns outward: publish the app, share it by email, social media, blogs and communities, and let unknown people try it. Add analytics so you can see how people use it, where they get stuck, and what to improve next. The final panel lists tomorrow's five deliverables - update the app, a two-minute product video, a two-to-three-minute learnings video, a shared session log, and links added to the same sheet - closing with 'full AI product development life cycle complete, add this to your portfolio.'

The whole clinic, drawn. A roadmap from idea to launch, the four personas who kept hitting the same four walls, and the pivot from testing with agents to shipping to strangers. Open it full size ↗

Scene one

"How many times is enough?"

Anand opened by saying almost nothing was planned: "today's session is mostly going to be just answering any questions you might have, plus maybe just one additional task beyond what we covered yesterday." Johan used the opening to ask the question every student iterating with an agent eventually runs into.

"You mentioned that we have to iterate and use AI to verify the products, but how many times should we do that until it's done?"

— Johan

The answer split cleanly into two different kinds of "enough," because the two kinds of verification from Wednesday's checkpoint don't share the same finish line:

The automated test suite
At least once. Probably no more than twice.
"I'd suggest you do it once to get a feel for how it works, and then once you've finished your product features mostly, then keep this as an automated test set so that later on when you change something, the test still works."
The persona / user evaluation
At least once. Genuinely no upper bound.
"The evaluation as different personas, that I'll leave entirely to you. At least once, but you can do it again, change features, do it again. There's no end to user testing."

A test suite is a fence you build once and reuse; user testing is a conversation that only ends when you stop shipping. Both were about to matter within the same hour, in reverse order.

Scene two

Thirteen entries, three agent-research reads

Anand pulled up the shared class spreadsheet — the same one every submission for the week lives in — and did a quick roll call before diving into any one entry.

"We have 13 — okay, well, 12 people submitting 13 entries. That's perfectly fine; each of you can submit multiple responses. And the agent research is available for many of you. I would encourage everyone to complete it, but let's take a look at any one of these to see what the agent research revealed."

— Anand

The roster, read straight from the sheet at the moment of the clinic:

12
students
13
app entries (Miku submitted two)
8
with agent research already linked
1
without an app yet — KK

KK's absence got a direct, gentle callout: "KK hasn't filled in the — oh, I thought KK — oh no, KK didn't have an app yesterday either. We might want to nudge if he wants to complete that." Then Anand cycled through whatever agent-research links were open in his tabs, reading the platform out loud as a kind of running commentary — "okay, that's a Claude artifact… that's a ChatGPT site as well… okay, that's a GitHub page" — before settling on three to actually read closely with the class.

Miku · Pocket Trails — agent market research
pocket-trails-user-perspectives.pswr2jmt2n.chatgpt.site

Three sub-agent personas walked Pocket Trails, a walk-and-discover app. Open in its own tab ↗

This was the "walking application" Anand read out first, and its three invented personas — a freelance subtitler, a municipal records clerk, and an engineering student — landed exactly the friction points he called out live:

"This used a freelance subtitler, a municipal records clerk, and a mechanical engineering student. […] 'If the phone is locked but the page is visible, that can be demanding on battery life.' Yes. 'Hesitations because of [sharing your] corner [location].' Yes. 'Inter-application coordination can be an important friction.' Yes, that's a good set of items."

— Anand, reading the report live

The full report names them: Hana Cho (34, a freelance subtitler who explores on foot in the evenings) flagged that keeping the phone unlocked to view the page drains the battery; Darnell Price (58, a municipal records clerk) hesitated the moment the app sent his coordinates to an outside place-search service; Lucía Ferretti (21, an engineering student who already lives inside Google Maps) found that copying a link out to Google Maps broke the spontaneous feel of the discovery itself. The report's own one-line synthesis is the kind of finding no single human tester would likely have named so cleanly: "Curiosity is easy. Confidence takes more work." People explore readily; they hesitate the moment the app asks them to record, share, or trust it with something.

The second read was RouteDraw, dora's routing dashboard, and this time each persona found a genuinely distinct defect rather than three shades of the same one:

"Route Draw takes a batch delivery coordinator and finds that, okay, the earlier route gets deleted. A retired Google Maps user finds that clicking gives no feedback. Good point. And a gig bike courier finds that the routing calls go from the browser to OpenStreetMap with no backend — ah, okay, but it might get limited upon high use. That's a fair point."

— Anand, reading the report live

Three personas, three different jobs, three unrelated failure modes — a spread a single human tester working alone would have needed three separate sessions to surface.

Yuri · Study Walker — agent market research
yuriciv.github.io/study-walker/research.html

The GitHub-page report: a university student, a professional restarting English, and someone restarting bookkeeping. Open in its own tab ↗

The third — and the one Anand called out for what it revealed about studying, not just about the app — was Yuri's own overnight follow-up research on Study Walker, the same app three of Anand's own sub-agents had surveyed on Wednesday. This round used three new personas: an inexperienced student building a personal website, a young professional restarting everyday English, and a university student restarting Bookkeeping Level 3.

"And this is from a university student, as well as a professional studying English and someone restarting bookkeeping, exploring their study habits. Great. Now this is exactly the kind of research that we want people to do. So that is useful; do complete it."

— Anand
The same bug, found twice, independently

The bookkeeping persona's session hit an odd defect: the app kept surfacing a leftover "build a website" suggestion instead of a bookkeeping one. The report didn't lead with "goal-classification broken." It traced the cause — saved state from an earlier test run bleeding across a shared browser session between agents — and correctly filed it as a test-harness artifact, not a product bug, while still flagging the underlying need: make it obvious to a real user which saved goal they're resuming.

It is almost exactly the same shape of near-miss Day 3's own consolidated report caught: a "critical bug" two personas independently hit that turned out to be shared test-storage colliding, not a real defect. Verify the alarming finding before it reshapes your priority list is turning out to be a skill the students are picking up on their own, not just something Anand demonstrated once.

The report's own top-line finding, in plain language: the app's core idea already works. What breaks is the moment right after — "guidance became insufficient once an external tool or existing learning material was opened." The suggestion says what to do; it doesn't yet say exactly where to click once you get there. That's a smaller, cheaper fix than a redesign, and precisely the kind of specific, actionable finding Wednesday's exercise was built to produce.

Scene three

Watch yourself, mistakes included

Before turning to the day's real pivot, Anand checked in on the peer-feedback assignment from Wednesday — the video walkthroughs students owed each other. Nobody was empty-handed, though not everyone was finished.

"Johan, you have — okay, one feedback from Noah, not yet from Kosei; you might want to ping. […] Hinata has at least one feedback as well. So does Nanami on both the applications. […] So does Noah. Okay, and Mio. Fair. So everybody has in some shape or form at least one feedback that they can incorporate."

— Anand

Then he watched two of the submitted videos live, cold, and the gap between them made an unplanned point about what makes feedback useful.

Watched first · no audio
A silent screen-recording
"Is it my audio that needs fixing? No, there is no audio. […] This is a walkthrough just showing what they did, where they clicked, without a voiceover. Probably should have made that more explicit; it always helps when people hear what you're thinking. But fair enough, at least there is a walkthrough of how we did it." Watch it ↗
Watched second · narrated in Japanese
"Impressions after working up to this point…"
A student picks a store to add a loyalty card for — "ユニクロを選択します" (I'll select Uniqlo) — then narrates: "ここまで作業してみての感想…" (Impressions after working up to this point…). Anand: "Fair enough, and five minutes is a reasonably good duration to get a sense of the inputs." Watch it ↗

Neither video was a polished pitch — one had no voice at all, the other was an unscripted five minutes of a real person clicking through someone else's app. That was itself the point Anand was quietly reinforcing before naming it outright a few minutes later: a narrated, honest, in-the-moment reaction beats a clean one, every time.

Scene four

Now go find strangers

With the check-ins done, Anand named the shift in one line, summarizing the entire week so far before pointing past it:

"What we've done so far is taken an idea, which can be agent-generated, implemented a prototype, which again was agent-assisted, gotten feedback from agents and people, and now are using agents' help to create a revised version of it. The last stage is to then — for lack of a better word, I'm going to say — market it."

— Anand

He was careful to defuse the word immediately — "market it" doesn't mean charge money, or chase a follower count:

"When I say product, it doesn't have to be paid; a free product is perfectly fine. See if you can find out who is using it and how, and learn and improve from the process."

— Anand

The reframe underneath it is the real content of the scene. Every tester so far — Wednesday's three Haiku sub-agents playing personas, this week's own classmates giving feedback — was chosen by the student, briefed by the student, and to some degree already sympathetic. The next tester is not:

"Right now, we asked people to record a video; we asked an agent to try it out. Now we're going to ask unknown people to try it out. And therefore, your application needs to have some mechanism to figure out who's coming in, or even if not who's coming in, what are they doing? What's working well for them? What's not working well for them?"

— Anand

And true to the pattern set on Wednesday, the "how" was deliberately left open rather than prescribed: "How do you do that? Ask the agent. There are several tools out there. The 'how to do it' is not the important question anymore; it's the 'what to do' that starts becoming important." The deliverable this created was concrete and, notably, the first one this week framed entirely around a metric nobody could fake:

The verification method flips

Monday through Wednesday asked: can an agent build it, break it, test it, survey it? Thursday asks a different question entirely — will a stranger who owes you nothing bother to use it, and can you tell? "I'll visit the application, you'll all be visiting the application, and as we use the apps, you should get some feedback that the application has been used in this way, and you should be able to learn from that and improve as the next iteration."

Two more deliverables followed the same publish-and-observe logic, both aimed squarely at Friday's portfolio-ready close: a two-minute walkthrough video of the finished application — "just a walkthrough of: 'here's what my application does'" — meant explicitly for publishing, not just grading; and a second, shorter video reflecting on the process itself.

"I'd also like you to share a short, two-max-three-minute video on what you learned from the usage of this. Meaning how you went about using the agents, what it did well, what it didn't do well, and what you are taking away from that."

— Anand

When Johan later asked whether he'd correctly understood the ask, Anand's answer doubled as the whole rubric in one breath: "What you did, what it did well, what it didn't do well, and what you learned from that. That mainly."

Scene five

Ship your chat logs too

There was a fourth, quieter deliverable, and it came with the same "learn from the gap" logic that closed Wednesday's black-box argument. Anand wanted a record of the actual back-and-forth with the agent, not just the finished result — because the correction is the curriculum, and a chat log is where the corrections are visible.

"I'd like you to support this with the shared transcript of one of the sessions where you were interacting with the agent for a long time. […] If you were having a discussion directly on ChatGPT or Claude, you can just click on the share button. […] Make sure that you select 'Anyone with the link,' save it. That will give us a link when you click on 'Copy public link.'"

— Anand

For Claude Code and Codex sessions — trickier to share by design — he punted the problem back to the tool itself, in keeping with the week's running theme of not pre-solving what the agent can just be asked: "you can just tell the agent to export the session and it'll export the session. Frankly, that's easy enough to do." Then Johan caught something the plan had missed, live:

Johan: "And all of them, besides the transcript of the chat, are sent through the email?"
Anand: "Ah, no, good point. Let's just add it to the same sheet. That is actually an excellent idea."

— live exchange

Anand restructured the shared spreadsheet on the spot, adding three new columns next to each student's row: Product Video Link, Learnings Video Link, and Chat Log Link — turning what had been a loose set of emailed deliverables into one running, publicly-comparable ledger of the whole class's proof-of-work. "Thanks for flagging that, Johan."

Deliverables before Friday

Anand recapped the list twice — once from memory, tripping over the order, and once with Johan's help finishing it — which is itself a small, honest demonstration of exactly the kind of imperfect-but-clear communication the videos are supposed to model.

  1. Update your application based on all the feedback gathered so far, to the point where you think it's better.
  2. A two-minute product video — a walkthrough of what your application does, suitable for actually publishing (blog, social media, email to family).
  3. A two-to-three-minute learnings video — what you did, what the agent did well, what it didn't do well, and what you're taking away from the process.
  4. Integrate analytics into the application, so that when a stranger uses it, you know how they used it and can improve from that signal.
  5. Share a chat-log link — a public share link from one long session with the agent, or an exported transcript — in the same class spreadsheet, alongside the two video links.

The framing for all of it, stated once and left to stand: "With that, we would have perhaps in tomorrow's class, if not at least by end of day tomorrow, wrapped an entire AI product development life cycle. And you should absolutely publish this on your portfolio." Questions in the meantime go to [email protected]. The class meets again in person on Friday, same room, same time.

Things from Day 4

Thursday 10 September 2026 · SUTD · optional query clinic, remote

01
A test suite is a fence; user testing is a conversation.
"At least once, but probably no more than twice" for the automated suite — then keep it as a regression check. "There's no end to user testing." The two kinds of "enough" aren't the same question.
02
Three sub-agent personas can out-triangulate one human tester.
Pocket Trails' three invented users each hit a different friction point — battery, privacy, workflow — in one overnight run. "Curiosity is easy. Confidence takes more work."
03
The same "verify the alarming finding" bug, found independently by a student.
Yuri's Study Walker research hit a shared-storage collision between test agents — and correctly filed it as a harness artifact, not a product bug. The skill from Day 3 is spreading on its own.
04
A narrated, honest five minutes beats a silent, polished one.
One feedback video had no audio at all. "It always helps when people hear what you're thinking" — reaction, not just clicks, is the useful signal.
05
The verification method flips: from agents and friends to strangers.
"We asked people to record a video; we asked an agent to try it out. Now we're going to ask unknown people to try it out." That changes what the app itself needs to be able to tell you.
06
"How to do it" stopped being the interesting question.
Instrumenting an app to see real strangers use it is a solved, googleable problem. "It's the 'what to do' that starts becoming important" — deciding what's worth measuring is the actual skill.
07
Ship the chat log, not just the app.
A shared, long agent session is where the corrections — and therefore the learning — are visible. Publish the transcript alongside the product.
08
One sheet, one ledger, no email chase.
A student's live catch — "aren't we emailing these?" — turned three scattered deliverables into three columns on one spreadsheet everyone could see. Good process gets fixed the moment someone notices it's missing.