The most useful product review we have had this year was not a roadmap meeting. It was a deletion meeting.
The product was Yarrow Yi, a new reflection app operated by MyMemo AI LLC and built with our product and engineering help. The app could have absorbed a hundred plausible features: more casting methods, more AI rituals, more social sharing, more dashboards, more historical commentary, more settings. Every one of those ideas could be made to sound reasonable in isolation.
But the question in the room was smaller and harder:
If we keep this feature, who is going to operate it twelve weeks from now?
That question killed more ideas than any design critique did.
It also produced a better product. Yarrow shipped with a clearer line: daily I Ching reflection, question framing, a reading journal, and a strict promise that AI explains the hexagram but never chooses it. The product does not ask the user to believe in our cleverness. It asks the team to keep a small number of promises and make them hold up under real use.
This is the argument I want to make plainly: our standard is not to make many products. It is to make products we can keep improving after the first clean screenshot.
The cheap part is adding one more surface
The economics of modern software make excess feel harmless. A new tab is cheap. A new AI mode is cheap. A new onboarding branch is cheap. A new pricing experiment is cheap. A new “power user” setting is cheap.
What is not cheap is carrying it.
Every surface needs copy that stays true after the product changes. It needs support answers. It needs instrumentation. It needs edge cases in Chinese and English. It needs privacy language. It needs a path through App Store review, Google Play review, billing, restore purchases, deletion, refunds, reporting, and whatever the user does at 1:17 a.m. when they are not reading the happy path.
This is why I distrust product plans that are large before they are lived in. They confuse implementation cost with ownership cost. A team can build ten things quickly and then spend the next year discovering that only three of them deserved to exist.
We prefer to learn that before the user has to.
The rule: finish the loop before adding another one
The product loop matters more than the feature list.
For mymemo.ai, the loop is capture, recall, return. A user puts something in, forgets the exact wording, and later finds it again at the moment it matters. If that loop is weak, no amount of decorative AI tooling saves the product.
For Yarrow Yi, the loop is question, cast, reading, reflection. The cast is not the product by itself. The AI answer is not the product by itself. The product becomes useful only when the user returns later and asks, “What actually happened? What did I learn about the way I framed that question?”
That is why we care so much about the journal and the return path. It is also why some attractive ideas wait. A feature that creates a new loop before the existing loop is proven is not expansion. It is dilution.
In our internal product notes, the rule looks almost boring:
const productStandard = {
promise: 'one clear job',
loop: 'closed before expanded',
ai: 'used only where it earns trust',
operations: 'owned after launch',
subtraction: 'available every week',
};The boring shape is intentional. A product team that cannot write the product standard in plain language usually cannot operate the product either.
AI has to carry a boundary, not just an answer
Most AI products still behave as if more output is the point. Longer answers. More modes. More personality. More confidence.
We do not think that is a serious standard.
In Yarrow, the most important AI decision is a boundary: AI does not cast. The hexagram comes from a deterministic or user-directed method. The AI layer can help the user phrase the question, explain the image, suggest things to observe, and make the reading easier to review later. It cannot change the result to make the answer feel better.
That boundary is not marketing language. It affects the architecture, the prompt, the UI copy, and the safety path. It makes the product less magical. That is the point. A tool for reflection should make the user’s own reasoning more visible, not hide the mechanism inside a confident paragraph.
The same principle applies outside Yarrow. In MyMemo, AI has to make memory retrieval better; it is not allowed to turn a personal archive into a chat toy. In client work, an LLM has to earn its weight against deterministic code, search indexes, rules, and boring workflows that often work better.
Our position is not anti-AI. It is anti-theater.
A better product is often the one with fewer explanations
One signal I watch closely: how much explaining does a product need before a normal person can use it?
If the answer is “a lot,” there are only two honest possibilities. Either the product is serving a domain that is truly complex, or the team has outsourced its confusion to the user.
Product quality, for us, is partly the refusal to outsource that confusion. We would rather remove a feature than explain it forever. We would rather make one path good than create three paths and hope a tooltip saves them. We would rather delay a mode than make support carry a fragile design decision for the next six months.
This is not minimalism as a taste preference. It is an operating preference. Fewer surfaces mean the team can inspect the ones that remain. Fewer promises mean support can answer truthfully. Fewer modes mean the product can be tested with actual attention instead of a checklist.
There is a particular kind of product that looks impressive in a demo and starts decaying the week after launch because the team cannot keep all of its promises alive. We try not to build those.
What “精品” means to us
The Chinese word “精品” can become a slogan very quickly. I do not mean it that way.
For us, a better product is not a luxury object. It is a product where the team has accepted the cost of staying with it. The edges are not smooth because a designer made a beautiful first pass. They are smooth because support, engineering, product, legal, and operations kept meeting the real product after it left the mockup.
That standard changes what we choose to build.
It makes us slower to add features that do not have an owner. It makes us more willing to write unglamorous privacy copy before launch. It makes us care whether an App Store subscription can be restored, whether an English user can complete the first meaningful action, whether a Chinese sentence sounds like a person wrote it, whether the product still makes sense after the first month of usage.
Those details are not polish after the work. They are the work.
The kind of company this forces us to be
If we wanted to maximize output, we would run the company differently. We would split strategy, design, engineering, and operations into cleaner handoffs. We would build more v1s and keep fewer warm products on the table. We would make the portfolio page bigger and the operating burden lighter.
We have tried versions of that. It produces impressive motion and weak memory.
The company we are building has to remember what it ships. That means fewer products, fewer promises, more ownership, and a higher tolerance for the unglamorous work that happens after launch.
MyMemo and Yarrow are sibling products in that sense. They are not proof that we can make another app. They are proof that we are willing to keep carrying the consequences of the product decisions we made.
That is the product principle underneath the public work: do less than we could, so the parts we do choose can become real.