I post about four tweets a day on average, but 70% of the time I don’t even open Twitter.
This episode talks about my current posting workflow—
**Input:** I carry a voice recorder with me. When inspiration strikes, I record. Press the iPhone Action button and it saves straight to iCloud.
**Processing:** I bring the recordings back to my computer. Claude Code automatically transcribes and categorizes them, then pushes them into Obsidian as a daily note. If something feels suitable to share publicly, I add a Share tag.
**Publishing:** After some simple editing, Claude Code bulk-saves everything into Buffer. Buffer uses a queue to send them out one by one. Replying to comments is handled inside Buffer’s app as well.
All without actually opening Twitter itself.
For me, the most important part of this process isn’t “efficiency”—it’s **isolation**: separating “producing content” from “being consumed by social media.” Scrolling Twitter is way too easy to steal people’s attention, but I still want to maintain consistent output, so I just physically isolate the two.
This episode also covers another interesting question: when hiring a designer, do you prioritize matching their style or hiring someone with strong skills? A client asked me this, and my answer might be different from what you’d expect.
Go listen 👇 https://redcircle.com/shows/936a3212-92e5-41c7-b6f9-39e3596adeb8/episodes/366470bc-7502-4e02-8597-60b2843d73ea
Share a piece of advice with startup teams: real user testing is unavoidable, and the more, the better.
If you want to find real users, going to their meetup groups is a great approach. For example, if your target customers are technical professionals, you can attend hackathons, Builder Meetups, or industry conferences.
Have each person spend 5 minutes doing the test—validate the problem, create a scorecard, and whenever you find issues, use AI to tweak your prototype on the spot, then run the next round of tests. Do a few rounds, and the results will be very clear.
It’s fast, effective, and free. You don’t need to use those ridiculously expensive services on http://UserTesting.com.
The biggest advantage of in-person testing is the amount of information you get. When people use your product on-site, the feedback you receive is much stronger than what you’d get online.
After I finished sharing CUBE today, two entrepreneurs came to talk with me. They both said they want to use this tool to create marketing visual content for product promotion, and one even said they’re willing to pay.
Right now, I’m not treating paid users as a hard metric, but this observation is quite interesting.
For product founders, promotion definitely needs visual support. It’s a matter of overall packaging—an area brand designers have been working in for decades.
When I made CUBE, I just meant it as a small visual toy. I didn’t expect to find a real application scenario like this.
It’s worth putting more effort into this direction.
Today I saw a former colleague of mine from Les Mills sharing his entrepreneurial journey on LinkedIn.
He built an AI product. At first things went pretty smoothly—he attracted investors and also had a technical co-founder. Later, the co-founder and the investors wanted to set up the physical entity in Australia, and he wanted to stay in New Zealand, so they eventually parted ways.
Finding VCs and investors in New Milford (纽村) is already not easy, and most of the people you meet aren’t very reliable. Later on, he took his family on a camper van trip—working during the day and spending evenings with his family. While waiting in line at a fish and chip shop, he casually chatted with an elderly man behind him. As it turned out, that old guy was a VC. After talking a few times, the man directly invested $50,000.
Run into a VC at a fish and chip shop—you believe it?
A specific version of the same question—one of those details I’ve repeatedly explained to other people.
It starts with a body-weight data point from a Withings body fat scale, then gets written into Apple Health. From there, it’s read out through Google Health.
Three layers—Google is on the third. It doesn’t measure this value, nor does it own the repository where it came from. Instead, it performs inference on top of upstream decisions that it can neither see nor modify. If Apple changes a permission, or the scale changes what it writes, the coach’s understanding of you changes—and no one will notify it.
Most product diagrams don’t draw this layer. They show a data source plus an arrow, so every input looks equally solid.
**Draw your data flow by layers. Don’t just draw arrows. Any value that your product uses for inference—but that you did not collect—must be marked as a dependency.**
Do just this one exercise, and it will change how much confidence you’re willing to give the frontend.
Just after Molly got out of school, she asked if she could play at the Playground for a little while. I said she could.
Her classmate next to her told her mom: “Can she play for a little while? Just five minutes.” That mom was busy walking back home: “No, I can’t—I have to work, I have to work!”
I suddenly felt really grateful. These days I only need to work—I don’t have to go to the office anymore.
Behind our home’s balcony there’s a big tree, and there are often lots of birds. I would feed the birds—one would come, then two, and eventually they formed a little community. They often come and wait in the tree to eat, and sometimes they even loiter on top of the garage. Then gradually, cats started showing up. There were two cats that would lie in ambush near my home’s deck to catch birds. They never actually caught any, but they still kept coming.
Then every once in a while I could pet the cats :)
I think getting users and customers is similar to attracting cats.
Either you post things that customers themselves are already interested in. Or you post things that people your customers want to attract are interested in—things like those birds.
Small teams building products are a lot like sailing races.
You build a new feature, find a new route, and pretty quickly other products follow. Since they’re all small teams, they move fast, and it’s easy for them to gain an edge in certain areas.
For example, video recording: Screen Studio came out first. At the time, it was quite astonishing—it opened up that lane, and then similar products quickly came along. For users, at that point, unless a particular feature or requirement is something only you can satisfy, there’s still switching cost.
I was an early user of Screen Studio, and later I also tried many competitors, including ones built by friends and ones sent in for testing. But honestly, I still found Screen Studio more convenient, and I wasn’t really willing to switch—there’s some psychological learning cost.
It’s like a sailing race: a tiny difference at the front or back may come down to wind conditions or how you operate the boat. Sometimes, if you tack around a corner, you’ll pull ahead; and sometimes you’ll fall behind.
This is a structural weakness I didn’t expect to find.
Google Health handles three types of data that look very similar on screens but differ greatly underneath. Fitbit data is collected by Google using its own hardware. Apple Health data comes from a platform that Google can’t control. Medical records need to be imported through external systems.
On the interface, they appear in the same list with the same styling. But in terms of control, they’re completely incomparable. For the first category, Google can guarantee its form, freshness, and continuity. For the second and third categories, it’s a guest—it depends on another company’s permissions model and export behavior.
For a product with ambitions to be “the layer of intelligence on top of your health data,” this is a very real constraint. A coach can only reason about what it’s permitted to see, and a substantial portion of the records are behind someone else’s doors.
**Before believing any platform narrative, separate “data a company owns” from “data a company is only reading.” The promises these two support are entirely different.**
Little gadgets made for fun, but with a serious mindset about publishing. We’re preparing all kinds of materials—this Thursday (expected) we’ll release it.
It’s been a year since leaving a big tech company—what has life actually become?
A new Chinese newsletter issue is out, and this one covers a pretty wide range of topics—
Starting with the "feudal metaphor of the financial system," then moving on to the real feelings after a year of leaving a job. This isn’t the kind of clickbait post about "quitting feels amazing, freedom forever"—it’s a real record with some uncertainty.
Then we also talked about:
📚 Hard sci-fi reading experience — how many people missed an entire universe because of the science-vs.-liberal-arts tracking system?
🎤 Hackathon presentation tips — there are actually many things you can deliberately practice when speaking on stage
💸 Real estate investment, immigration life, and... making a will
Yes, making a will. It sounds heavy, but it doesn’t feel that gloomy when you talk about it. At a certain stage in life, these "practical topics" may actually deserve more serious attention than grand narratives.
If you’re also going through some kind of "major turning point," or just want to see a genuine slice of someone else’s life, this issue should resonate with you.
Most AI features are being judged by “answer quality.” That is the middle of the interaction, and also the part that gets commoditized the fastest.
A complete AI conversation has three parts. Before: where the user came from, what the product already knows, and how it opens. During: the conversation itself. After: what happens once the conversation ends, whether anything is remembered, and whether the product should speak again when it’s time to follow up.
Google Health does the first two parts quite well. It opens with context, asks reasonable questions, and keeps reply costs low.
The third part is where it falls short. After a coaching conversation about sleep ends, it basically ceases to exist. Nothing durable is left behind that can change how the product behaves toward you next week.
**Model capability lives in the middle of the conversation, while product advantage lives at both ends, and far fewer teams are competing at those ends.**
If you’re building an AI product, the underrated work is not writing prompts. It is deciding what the system should still remember tomorrow, and what events should make it speak again.
Weekend project: working on CUBE, day 10. Actually, I can’t even remember which day it is anymore lol
Last week, I got some requests about adding emoji at the co-working space, and now it’s implemented. Handling emoji across different platforms turned out to be more complicated than I expected, but now it runs smoothly on both desktop and mobile.
Planning to release it next week. There are still two key features left to handle.