I received the following question and want to answer it here:
Please tell me about your failures after founding the company — especially in the period before Stailer, if possible. Since your mindset is about running experiments and removing uncertainty, I imagine you're accumulating small failures constantly. What I'd like to hear about are the higher-level, more impactful failures — and what you learned and changed as a result. For reference, I'm hoping for something with the specificity of LayerX Fukushima-san's piece in this Diamond Signal article.
On Failures After Founding
"Failure" is hard to define, but here are my top three in terms of how much I learned from them.
- One valuable release > many fast releases
- Monetization validation should happen sooner (especially in Japan)
- There's no time to bet on anything but the biggest theme
1. One Valuable Release > Many Fast Releases
With Tabery, we did extensive validation before launching and built something genuinely novel. But that novelty meant we weren't sure what to validate next. Should we push on retention and funnel optimization? Or first get to a UX that's good enough to be worth optimizing? We were unsure.
Then a press release went viral and tens of thousands of users flooded in within a single day, which made the signal-to-noise problem worse.
Influenced by that momentum, we deprioritized sharp validation in favor of riding the wave and growing users. Specifically: we were iOS-only and decided to build Android early to get wider distribution. I think this was a mistake — and I told the team so afterward.
What building Android quickly got us was 2x user acquisition at a retention level that wasn't good enough to matter. When we refocused on funnel and retention analysis, we ran an enormous number of experiments — but only two had genuinely large effects: simplifying onboarding, and tuning the recipe recommendation algorithm. In hindsight, if we'd just done those two things early, we would have made more meaningful UX progress, faster.
2. Monetization Validation Should Happen Earlier (Especially in Japan)
Consumer products often come with the logic: "If you get lots of users, you can monetize through ads or subscriptions." This logic relies on Google and Facebook as the reference point. But I was skeptical of it before starting, and experience made me more skeptical.
The "lots of users = can monetize" logic works at global scale. The math breaks down when you're capped at a Japanese audience. Japan's total addressable audience for any consumer product is at most tens of millions of MAU. Compare that to products with hundreds of millions of DAU globally — the ceiling is just much lower.
For Japan-focused products, advertising and content subscription ARPUs are extremely hard to raise, and the TAM quickly becomes small. To find non-linear monetization as a startup, you need to develop a clear, specific thesis about which money flows you're entering — and validate that thesis early.
With Tabery, we ran ads and a paid plan for about a month after launch. What we learned was entirely expected: "this won't scale." Realizing it let us quickly cut both. But in retrospect, this was validation I didn't need to run — and skipping it would have let us launch weeks earlier.
That said: the experience crystallized a commitment. I decided to pursue the largest wallet possible — food spending — which ultimately led to where we are. Early monetization validation has no downside.
3. There's No Time to Bet on Anything But the Biggest Theme
The above two points imply this one. Every hypothesis — small and large — requires the same basic validation cost. The difference is only in the upside, not the floor. Both take real resources; both require energy, time, and motivation.
Since resources are finite, you can only afford to look at the biggest theme you're capable of tackling.
At 10X, we've worked on a lot of things: Screenshotke-shi (a playful consumer app), Tabery Concierge (an unreleased product), a refrigerator prototype project. But all of these were either smaller than the core issue — "10x the retail experience" — or sub-issues contained within it. A resource-constrained startup has no business spending bandwidth on anything other than the main issue. If I were starting over, I'd full-swing at the main issue from day one.
That said, Tabekuru (our own-delivery experiment that we ultimately shut down) was a large-scale bet on exactly the right issue. The project closed, but the learning was enormous and the challenge was worth making. If you're going to bet, bet big.
