This is an essay about how my career as a product manager began.

Fujiko F. Fujio (the creator of Doraemon) once said that using your own experience as raw material for creativity is "the final destination of creative work." I think he was absolutely right.

When a person tries to create a story from nothing, they open the "refrigerator of memories" — trying to digest as a manga what they've experienced and preserved in life. Some people are fine with that. But I see it as the final destination of creative work. Look in your home refrigerator. Is there lobster? A variety of herbs? What you'll find in most refrigerators is the same: meat, vegetables, cheese, milk — bought at the nearby supermarket. Every refrigerator is basically the same. — Fujiko F. Fujio

In addition to being "refrigerator-style," this is a rambling, disorganized piece running well over 9,000 characters, sadly lacking in coherence.

Almost all of it is about my experience at smarby — a startup I co-founded and spent 2.5 years building from nothing. If that doesn't interest you, I'd recommend closing this browser tab now.

At the end of this post I've added a reflection written 1.5 years after the original (June 2018).

0 / Where I am now

On October 31, 2016 — about two and a half years after founding it from absolutely nothing — smarby joined the STRIPE INTERNATIONAL group. At the same time, I left smarby. I now build products at Mercari, the flea market app company.

Update, June 2018: Since that writing, I left Mercari after 9 months and have now founded a company called 10X, where I'm building a product called Tabery. We're a company that aims to invent.

Since the beginning of 2016, I've been blogging seriously. At its peak, my posts have been read by more than ten thousand people. That's exactly why I've tried to write things that are meaningful to product managers and startup people, rather than personal stories.

I always thought personal origin stories wouldn't be useful to anyone. I still think that. But just this once, I ask for your indulgence.

1 / Product management is "I want to die"

smarby launched at the end of November 2014 as an e-commerce site and app for moms buying and selling children's clothes. The listing period was one week, which was distinctive — otherwise it was a pretty standard e-commerce experience. But despite the simplicity, the path to launch was agonizing, for these reasons:

• E-commerce requires many essential features at minimum: payments, logistics, customer support
• None of the founding members had experience building a product
• Communication costs were high as specs kept changing
• As a result, "priorities" became vague
• Operations turned out to be far heavier than anticipated

After more than six months from start to launch, the product generated sales of roughly 1/50th of expectations on day one — a few tens of thousands of yen — delivering to every founding member the gift of wanting to die.

Before launch, I'd been busy acquiring 3,000 pre-registered users through a mix of unorthodox and lucky tactics, and had barely been involved in product development. But watching day-one sales and user behavior, I understood one thing clearly: if we continued like this, we'd die.

I can confirm that everyone on the founding team had impressive credentials, but none of us — starting with me — was actually capable of building a product. As you can see from the above, there was no "product management" at smarby at that point. Just the dark, heavy weight of a reality that made you want to die — and that crushing feeling was what product management (the force that moves a product forward) actually was.

2 / Product management is "bitter"

After confronting those dismal day-one numbers, I lost all composure and frantically explored every angle to figure out what to do. The first thing I did was pour money into Facebook ads to buy users. I'd made pretty projections at the business planning stage about CPO and LTV, but I understood all of that was worthless. People had to come, or it was over. So I poured capital into Facebook.

The verdict: ads were also worthless. Or rather, I, the one running them, was worthless.

My anxiety had destroyed any concept of monitoring KPIs consistently — I didn't notice that a CPA that was normal on day one had shot to 10x by day three.

I want to dropkick my past self for burning money from our lifeline (capital) while looking the other way. After burning several million yen, I discovered the mistake. From that day on, I spent weeks refreshing the dashboard every minute to monitor CPA while burning through the capital. Eventually, an engineer wrote a script that let me automatically track CPA from Slack.

I also explored what could be done on the merchandising (MD) side — the backbone of e-commerce.

There was almost no supplier willing to list their products on a platform generating sales in the tens of thousands of yen, so I survived by blasting hundreds of emails every day and pulling in merchandise through sheer force of personality at each meeting. In a few cases, our credentials helped bring in a supplier. With those partners, my greatest fear was that they'd feel let down — "we got less than expected, smarby disappointed us." I can talk about it now, but there were times when everyone used their meager salaries to buy our own products.

One success story from MD: approaching the year-end peak that arrived shortly after launch, we took unsold, scattered inventory and repackaged it as coordinated outfit sets (fukubukuro — lucky bags, a Japanese new year tradition). These sold out. One by one, items were gone.

1. Increase the value of merchandise (a complete set, affordable, easy to understand)
2. Communicate effectively (we posed as mom bloggers on our owned media and promoted through articles)
3. Amplify #2 via Facebook ads (expand to the interested audience)

These three forces combined to produce smarby's first presentable monthly sales figures (still tiny, though). This was the moment I felt real zero-to-one progress — and I grasped that for an e-commerce product, the product (website and app), the merchandise, and marketing form an inseparable trinity.

I celebrated — only to be immediately humbled again, as you might expect.

Three months post-launch, smarby was starting to learn "our way of selling." And during those three months, not a single line of source code had changed. Our engineer was writing scripts to automate manual data entry for product listings, scripts to compress the huge volume of images e-commerce requires, and keeping the servers running. That was all-consuming. And yet the business was still moving forward. Modifying source code is not the only way to manage a product.

• The CEO needed to raise more money because I kept burning it
• The engineer went home only once a month
• A co-founder was the stress-absorbing mascot of the team
• I was sleeping at 2am, woken by my son's crying at 3am

No matter how late the night got, I would arrive at the one-room office in Sangenjaya at exactly 10am every day, wake up the engineer, and go buy coffee at FamilyMart together. Looking back, the taste of product management in that post-launch storm period was bitter.

3 / Product management is "frustrating"

Having learned "our way of selling" and begun to streamline operations together with the engineers, smarby finally had the energy to think about "the next move toward the future" — modifying features, adding new ones, exploring new products.

This is finally starting to sound like proper product talk. But by this point we were something like one year in. For an entire year, there was nothing like the clean product management you read about in books. Agile hadn't even come up in conversation.

As operations became smoother and sales began to accumulate, we were considering "feature development" to grow revenue further — things like:

• Adding new payment methods
• Launching a PC site (smarby was mobile-only)
• An Android app (we started with iOS only; Android took a full two years to launch)
• An automated email newsletter system for members
• Building our own media platform to replace the WordPress-operated blog

Looking back, this might be described as my first real work as a product manager:

1. Define the product's challenges
2. Weigh against capacity and set priorities
3. Define "what we want to build"
4. Communicate to get everyone's buy-in
5. See it through to release

Rough and unpolished, but this was how we started gradually changing the product itself. The process was slower than I wanted, frustrating, and full of clashing opinions.

smarby's backend had several holes from launch, so reports of "can't buy," "it's down," "it's slow" and Hotfixes flew in daily. Whenever a Hotfix appeared, the engineer's priority immediately shifted to fixing it. At the time, I genuinely couldn't understand why feature development wasn't progressing while fixes were being made. The obvious truth — that all development tasks are serial, not parallel — was understood by no one on the team except the engineer.

• "The feature that was supposed to be done by XX still isn't released"
• "We keep talking about it and nothing gets started"
• "I have no visibility into progress"

I shudder thinking about it now, but I was making comments like these to the engineer every single day, the immature product manager who couldn't understand a creator's mindset.

Fortunately, in this period, our engineer and I ate almost every meal together — breakfast, lunch, and dinner. For someone like me who can't drink and finds it genuinely hard to build personal relationships, those opportunities were precious. The "thorns" that grew out of work would soften over morning toast.

The person who fundamentally solved the "I don't understand development" problem was a different engineer who joined later. He gave me:

• "What engineers value — the three virtues of a programmer"
• "What environment development requires — give me quiet, freedom, and flexible hours"
• "What a standard development flow looks like"

...along with foundational information (and information sources). This prompted me to start reading technical books, using the terminal and git, and trying to understand the engineer's language.

The first book he recommended was "The Art of Unix Programming" (by Eric Raymond).

As I gradually began to understand the creator's mindset, I came to see the process of making things through programming as genuinely precious and fun. I started forming my own behavioral principles:

• "Solving without building" is the best approach
• Show the vision. Why does this program need to be written? What return does writing this program create for the time invested?
• Committing to source code is not something I can do. Focus on passing the cleanest possible ball so the engineer can focus on the program.
• Once you hand control to the engineer, trust them completely.
• Hotfixes arrive, user situations change, and needed feature priorities shift constantly. Determine Backlog priority at good tempo, without causing confusion.
• Instant responses, clear specs, unambiguous language — to minimize the time the engineer's hands stop.

Many of these principles are spelled out as obvious in books like "The Lean Startup" or "The Agile Samurai." But I didn't learn them from books. I learned them one by one, building a product with an engineer, oscillating between the ideal and the real, between operations and development, frustrating my mind, sometimes fighting.

For example: when I communicate development specs via Slack, I never write in the casual, abbreviated style I'd use verbally. Even if it takes the writer more effort, I use precise language. Because I've experienced major accidents from small misreadings. "Accidents that could have been avoided if I'd just been a little more careful in writing" happen less often now — probably because I've stepped on so many landmines.

4 / Product management is "Saying NO"

The approach to moving a product and business forward — product management — constantly shifts as team conditions change. It's like soccer or rugby. Adding a new engineer, bringing on contractors or fully remote members — each shift in team composition and individual properties has a huge impact.

smarby, carrying its urgency, continued to grow in line with milestones. The company that started with four people had grown to over 30 after a year and a half. Stakeholders — suppliers, users, investors — were multiplying. Naturally, "free" (or less generously, "unsolicited") opinions about the product poured in.

My next major role was to say "NO" to almost all of them. Saying "NO" to someone once isn't that hard. But continuing to say "NO" is a surprisingly tough game, and I don't think that's widely understood.

• "That shouldn't be hard to implement, right?"
• "Competitor X has that feature"
• "User A, investor B asked why you haven't built that feature yet"

These comments directed at me seem reasonable at first glance — but actually they're not. The only thing that mattered for the product and the team building it was: "Is this genuinely necessary for our users right now?"

I'm not saying a feature that satisfies a specific individual is unimportant. But delivering a satisfying experience for users next month — growing revenue 2x, 10x in a year — was the most important imperative for us as an e-commerce business.

Being accountable for revenue made it hard to give everyone's opinion full attention or detailed explanations.

Three things helped me keep saying "NO." One was burning off stress through exercise. Another was a blog post from Intercom (the customer management tool startup) — reading it over and over gave me a jolt of determination.

The third was posting to our internal documentation tool — sharing, from my own perspective, where the product was and what we needed to achieve by when. Sometimes I posted a slightly softened version on this blog as well. It may have been rough drafts written without much polish, but sharing the minimum outline of my decision-making process seemed to help people understand "why Yamotty says NO." The power of text is immense.

5 / Product management is "fun"

Whether any given decision about a product or company is right, no one can know for certain. But the results always appear. A product manager's role can be roughly measured by whether the accumulated decisions and initiatives have moved the product closer to its ideal state.

But I think it's dangerous to become too attached to evaluating individual initiatives. The real role, I believe, lies in the ability to fully define the vision — to truly answer "what is the ideal, anyway?"

• By when
• What core value will we deliver
• To whom, and how much will they use it

Defining a vision that answers these three. And drawing people into that vision. These two things are far more gut-wrenching hard work than continuing to say "NO." But nothing is more fun. That's right: being a product manager is fun.

6 / Product management is "infinitely varied"

Everything I've described is about product management in a startup. But this case may be qualitatively different from product management in an organization of meaningful scale. In a startup, product management directly holds the life and death of the company.

Also, for someone pursuing a "product manager" career rather than "entrepreneur," there's the challenge of building a product that truly reflects your own will. For a corporate PM, it's not unusual for the product to be kicked off based on someone else's idea. How much of other people's ideas can you digest through your own context and infuse with your own will? That's just as large a challenge as starting a startup.

Product management must not become an end in itself — it's a means. What kind of world do you want to create through the product? The means available to you will vary based on your professional and personal environment, skills, and condition.

I enjoy hearing other product managers' stories. But I rarely use them as reference. Almost nothing applies to my situation. If anything, I want to figure out my own path myself.

7 / In closing

"How do I start a career as a product manager?" "How do you develop product managers?" These kinds of questions started coming my way even from someone like me, who figured everything out by trial and error. And this post is part of my answer.

In a word: "I just did what was necessary when it was necessary." I have no confidence that making someone else repeat terrible experiences like "burning a massive budget on Facebook ads" would develop a good product manager. Paradoxically, product managers may not be developable through any reproducible system.

Someone might become a product manager by being an engineer and becoming the hub people rely on. Someone else might become a PM by working in customer support and developing the deepest understanding and love for users.

For those people, I hope this article can serve as a pat on the back: "It's okay — I stumbled into it too."

8 / Looking back 1.5 years later (June 2018)

Looking back again, the complete absence of any universal path to becoming a PM feels vivid — as does the memory of how many mistakes I made. A strange feeling.

Actually, before smarby, there was a person who gave me the motivation to aim for product management. That was Kawai-san, now VP of Product at Niantic, Inc. — who at the time was a product manager on the Google GEO team overseeing products like Google Maps.

We met through an NPO focused on rebuilding the Tohoku region after the earthquake, which I was involved with before smarby. Kawai-san happened to be from Sendai, and he joined our fundraising efforts, entrusting us with significant funds and working alongside us. We were given a lot of freedom: running Street View through Namie-cho in Fukushima, which was then a restricted evacuation zone; launching a crowdsourcing platform to match Tohoku local businesses with Tokyo professionals.

"Keep facing the user's pain with every tool available." "Staying in one place is not acceptable — aim for 10x." These principles I carry came from him — but looking back, when I was starting smarby, I had not actually fully applied them. Only through the successes and failures of smarby did they finally feel natural in my hands.

Product management knowledge is increasingly being systematized. But the people who can truly wield it are rare. There are things that can only be cultivated through taking risks, taking positions, and building products by hand — and that will always be true.

After smarby, I wanted to find my own answer to "how do you produce real invention?" That's why I chose Mercari — the environment seemed perfect. Mercari is remarkable: extraordinary growth rate, a stable work environment, great compensation. But when I wanted to pursue "real invention" myself, founding 10X felt like a far shorter path.

When it comes down to it, I realized: invention is the exclusive privilege of those who challenge. Just as product management knowledge doesn't become natural without the challenge of actually building a product.

My goal now is to attack "making things people want" until the day I die. That it started at smarby is beyond doubt.