A Blade Tip Alone Is Not a Dagger

In the middle of 2025, we gave a new product to a group of beta users.

Before we released it, I already knew it was not good enough.

Its interface lacked polish, the interactions did not yet feel natural, and the functional flow was incomplete. We could see many of the problems without waiting for user feedback. More troublingly, these problems could not be separated from one another. The interface, user experience, functional completeness, reliability, and maintainability all had to work at the same time before they could form a complete product.

But we had just spent months absorbing a set of startup methods: meet customers early, move in small steps, and iterate quickly. So even though we were dissatisfied with the product, we still believed we should release it first.

Users quickly raised many issues. We had known about a substantial number of them before the release. Their feedback became the starting point for the change we made in the second half of the year.

Looking back, that beta test divided 2025 into two halves. During the first half, we continued building MagicGourd, hoping to make its magic finally appear. In the middle of the year, we extracted one idea into Sayso, built it quickly, and put it in front of users. In the second half, instead of continuing to chase release speed, we turned to building our product capabilities. The starting point for all of this came at the beginning of the year, when we received investment from MiraclePlus and joined its accelerator.

By the end of the year, we still had not made that dagger. But we had begun to understand: a blade tip alone is not a dagger.

An Interview I Had Not Planned to Attend

At the beginning of 2025, I had no plan to raise money.

In 2024, we had spent most of our time building MagicGourd and released 27 versions. Our limited fundraising attempts had led nowhere, and the product was still far from the “true second brain” we envisioned. But I deeply enjoyed the process of building it.

I thought we could continue at a very small scale, moving forward one step at a time without rushing to take investment.

Kehan changed my mind. He told me that fundraising was not necessarily only about money. The MiraclePlus accelerator, its mentors, and its alumni could also help us over a much longer period.

By then, the application deadline had already passed. But I did not want to let Kehan’s recommendation go to waste, so I submitted an application anyway, briefly describing how I thought about a true second brain.

This interview took place at the MiraclePlus office in Beijing. While I waited, I saw several interview suggestions on a screen: answers should be simple, direct, and truthful.

In the interview a year earlier, I had unconsciously searched for the answers investors wanted to hear. When they repeatedly challenged our ideas, I worried that my answers were not good enough. Because I respected the people across the table, I could even begin to doubt my own judgment.

This time, I was not in such a hurry.

After a full year of development in 2024, we were still in the water, but no longer struggling as we had just after jumping in. I did not try to prove that I must be right, and I had not prepared heavily polished answers. I simply said what I genuinely thought.

Dr. Lu Qi asked what I thought of SenseTime. I said that, first of all, I was deeply grateful to the company, because I had gone through a crucial period of growth and transformation there. Around the arrival of ChatGPT, SenseTime may have been slightly slow to respond because a large ship is difficult to turn. But by 2025, I could see it changing quickly, and I believed a better era for SenseTime was arriving.

He then asked what I thought of DeepSeek. My answer was one word: cost. I did not elaborate at the time. I simply believed that cost would directly affect the scale at which a technology could enter the real world.

The interview went more smoothly than I had expected. Perhaps because I was no longer desperate for a particular outcome, it became easier to speak simply.

Later, MiraclePlus invested in us, and we joined the accelerator.

We Wanted the Magic to Finally Appear

If the goal in 2024 had been to make the gourd first, then at the beginning of 2025 we wanted its magic to finally appear.

In 2024, we had stayed sharply focused and completed MagicGourd version 0.27. It helped people mark what moved them on webpages, online PDFs, and videos, record the thoughts that arose, and preserve all of it over time.

But it was still closer to a container. It could collect and manage a person’s records, but it could not truly understand them, much less help someone discover thoughts that remained unfinished.

So when we planned for 2025, we set ourselves a much larger goal. We would no longer be satisfied with adding features. We wanted to take a real step toward the true second brain we had imagined.

We wanted to understand a person’s long-term records, find connections scattered across different times and different pieces of content, understand what the user was thinking at that moment, and recognize intentions they had not yet clearly expressed.

The goal was exciting. It was also far beyond the scope we could manage at the time.

During the first half of the year, we devoted enormous effort to development. The problem was not a lack of hard work, but the number of things that had to be solved at once. Every step forward exposed more questions. The scope kept expanding, while our development pace kept slowing. Half a year passed, and we still had not put the most important value in front of users.

After entering the MiraclePlus accelerator, we kept hearing one word: sharp.

My mentor in the accelerator, Peter, repeatedly told us that a startup should make a dagger, not a Swiss Army knife.

As the first half of the year drew to a close, we began to think the problem was that the product had become too large. If we could not build a true second brain all at once, we should extract its most important element and turn that into a product that was small, fast, and cool.

At the time, we thought that was what a dagger meant.

A Second Brain Should Understand Intentions Not Yet Spoken

We repeatedly asked what mattered most in a second brain.

The answer we eventually found was understanding intention.

An ordinary information tool usually begins with what the user has already entered. If a user writes a sentence, it can revise it. If the user asks a question, it can answer. If the user saves an article, it can summarize it.

But many human intentions are not clearly expressed at the beginning. Sometimes we have only a vague sense that something matters without knowing what we truly care about. Sometimes we are about to meet someone important and have a great deal of information in mind, but do not know what is most worth saying. Sometimes we know the feeling we want to express but cannot find the right words.

If a second brain could combine the user’s current context with these unspoken intentions, it would do more than process existing information. It would begin to participate in the process through which a person forms an expression or judgment.

Based on this idea, we conceived a product called Sayso in the middle of the year.

Using the person’s current context, it would help them see what they might say next. We did not want AI to decide a user’s true intention for them. We wanted it to offer possible directions from which the user could recognize what they actually wanted to express.

This need appears in many real situations. Before meeting an important person or beginning an important conversation, people are often not short of things to say. The problem is knowing which part of a large amount of information matters most at that moment.

Sayso tried to compress the large goal of understanding a person’s implicit intentions into one concrete task: use the person’s present context to uncover intentions they had not yet expressed.

We thought we had finally found a dagger inside the vast idea of a second brain.

We Mistook “Small” for “Sharp”

In the middle of the year, we moved from a large product to a small one, and our development speed increased noticeably.

But during this shift, our understanding of a dagger was still limited to its outward form.

We thought making the product smaller made it a dagger. We thought fewer features made it a dagger. Later, we also mistook novelty and development speed for sharpness: if a product felt new, could be built quickly, and could reach users quickly, it seemed closer to the right answer than the Swiss Army knife we had been building.

In the middle of the year, we built Sayso in a very short time and gave it to beta users.

Their feedback showed us that some people really did need help expressing themselves before an important meeting or conversation, and that they could understand the value of discovering intentions from context. This offered early evidence that the problem we were targeting was real, rather than merely an idea that sounded novel.

But the product itself did not work.

An AI demo about understanding intention might only need to produce a surprising result in a few carefully prepared examples. A real product had to show users what context to provide, help them understand why it offered particular suggestions, and let them naturally edit, choose, or reject those suggestions.

The interface had to inspire trust. The interactions could not create a new burden. The features had to support the user through the entire task. At the same time, the system had to be reliable and remain easy to maintain and improve.

None of these things, taken individually, was necessarily beyond us. The difficulty was making all of them good enough at the same time within a limited period.

Users could identify problems quickly, but we could not resolve them both quickly and well. Sometimes we completed a feature at the expense of the overall experience. Sometimes we improved one part of the experience while making the underlying system harder to maintain. Sometimes the core capability could already be demonstrated, but the user still could not complete a full journey smoothly.

The beta test was not meaningless. It at least allowed us to confirm that the need existed.

But the existence of a need does not mean that a product works. A working product does not mean that a market works.

Because the quality of the implementation stood between users and the core value, we had not truly tested whether Sayso could deliver that value consistently, much less whether enough people would want to use it over time.

We may have seen the problem the dagger should pierce, but we still lacked the ability to turn that insight into a dagger someone could actually use.

The Eye Could See, but the Hand Could Not Yet Make

After releasing Sayso, we initially attributed the problem to insufficient iteration speed. Users had given us feedback, so the answer seemed to be continuing to move in small steps and changing the product faster.

But we soon discovered that speed was not the only problem.

Before releasing the product, we had already known it was not good. Many of the problems in the user feedback had not exceeded our own judgment. What we lacked was not the eye to distinguish a good product from a bad one, but the hand that could quickly turn that judgment into a product.

The eye could already see. The hand could not yet make.

This did not mean that everything we had learned about products in 2024 was wrong.

Throughout 2025, MagicGourd remained online and maintained. New features arrived more slowly, but the existing service continued to run. By the end of the year, MagicGourd had around 3,000 users, and the feedback remained positive overall. We were not aware of any user data being lost or corrupted during the year.

In 2024, we had learned how to turn a demo into software that could operate over time: how to handle synchronization, privacy, compatibility, and failures; how to maintain a service that real users depended on; and how to take responsibility for data a person might accumulate over many years.

Those capabilities still mattered. They made MagicGourd more than a demonstration, and they allowed us to remain responsible to existing users even as the pace of new features slowed.

But 2025 exposed another layer of capability.

We were still not good at turning a need into a clear product definition. We were not good at creating a polished and natural interface and interaction flow in a short time. Nor could we reliably balance experience, functionality, reliability, and maintainability at once.

We had algorithmic expertise and systems engineering ability. When an idea appeared, we could quickly implement its technical core. But working technology did not mean a working product. Real product strength meant compressing many judgments that constrained one another into something the user experienced as simple, clear, and complete.

As we entered the second half of the year, we finally admitted that our product capabilities could not yet support our ambition.

First Learn How to Sharpen the Blade

We defined the second half of the year as a period for building capabilities.

The decision was difficult. Late in the first half, we had just invested a great deal of effort in understanding why we should meet customers early. In the second half, however, we decided to stop rushing every unfinished product in front of users and first learn how to build products well.

On the surface, this looked like retreating from the market back inside the company. But the problem we wanted to solve was not one that only the market could answer.

Users could tell us whether a need was real, whether the product created value, and whether they wanted to keep using it. But if even we considered the interface unpolished, already knew that an interaction flow was incomplete, or knew that reliability problems would obscure the core value, giving the product to users would not produce more useful information about the central question.

The market should help us answer unknown questions, not repeat answers we already knew.

So we began repeatedly studying products we genuinely admired. We broke down their structure, visual design, and interactions, asking why every detail had been handled in a particular way. Through close studies and reimplementations, we turned judgments we could see into things we had made ourselves. We then compared the differences and tried again, until we understood why these excellent products felt simple, natural, and complete.

Close study was not about copying a product’s surface or searching for an answer we could carry away unchanged. It was more like the practice through which someone learns painting, music, or calligraphy: first train the eye to tell the difference, then let the hand gradually catch up, and only then apply that ability to a problem of one’s own.

Product capability contains a great deal of tacit knowledge like this. Understanding an idea, or even accurately evaluating someone else’s product, does not mean we possess the capability ourselves. Only by turning judgments into interfaces, interactions, and systems through repeated concrete choices could that capability truly become part of the team.

By the end of the year, we still could not prove that we were able to build excellent products consistently. But in the middle of the year, all we could do was vaguely feel that “this product is not good.” By the end, we could break that judgment into more specific questions: how information should be organized, how an interaction should progress, how visual details should support the whole, and how system constraints would affect the experience. We could then train these abilities one by one through decomposition, close study, reimplementation, and rebuilding.

These changes were still only the results of internal practice and could not replace the test of real users. What we could say was that we had begun to form a more concrete way to practice, and that the distance between our eyes and our hands had begun to narrow.

Fundraising Is Not Only About Money

Looking back, the point Kehan had made at the beginning of the year was being confirmed, slowly.

Receiving investment was important, but money was not all that MiraclePlus gave us. Guidance from mentors and conversations with peers would not necessarily turn immediately into users, revenue, or a successful product. By the end of the year, I could not say that these relationships had produced direct results. But Peter’s dagger metaphor had already entered the way we evaluated products every day.

It kept forcing us to reexamine our products. Whenever I thought I understood it, later practice showed me that I had understood only one part.

At first, I thought it meant breaking the vast second brain into something smaller. Later, I thought small, fast, and cool meant sharp. Later still, I realized that a real dagger did not work merely because it was small. It had to concentrate a complete product experience on one specific problem.

The accelerator did not make the dagger for us, but it helped us see sooner why the thing in our hands was not yet one.

That is what it means to say that fundraising is not only about money. It may not provide an immediate answer, but it can change how we ask questions, evaluate ourselves, and continue learning.

True Sharpness Also Requires Completeness

By the end of 2025, my understanding of a dagger was different from what it had been at the beginning of the year.

Insight into the user’s problem was the blade tip. Interaction, interface, and product experience formed the edge. Functional completeness was the body of the blade. Reliability and maintainability were like the handle, allowing someone to truly hold and use it.

A single sharp point could at most become an impressive demo. It was not yet a dagger someone could actually use.

Completeness did not mean putting everything into the product. A Swiss Army knife can solve many problems, but it may not go deeply enough into any one of them.

True completeness meant completing the entire journey the user needed around one core value. Every part of the product had to point toward the same problem and support the other parts, rather than using more features to hide the fact that the core problem remained unsolved.

In 2023, I left SenseTime and jumped into the next river. In 2024, we made the gourd and began to understand why a product had to work over time. In 2025, we wanted the magic to finally appear, and we also tried to break the vast second brain down into a dagger.

The magic had not yet appeared, and Sayso had not yet become a working product. Even though we could now see the need, we still lacked the ability to build it both quickly and well.

But over the course of the year, we at least came to see more accurately what we lacked.

Our pursuit of sharpness had not made us abandon completeness, reliability, or long-term responsibility. We were also beginning to understand that meeting customers early did not mean giving them a product we already knew was poor, and that rapid iteration did not mean pursuing development speed alone.

As of today, we have not yet made that fully formed dagger.

We have only begun learning how to sharpen it.

A blade tip alone is not a dagger.