How a PC from the E-Waste Pile Taught Me Product Management

The PC was sitting on a rubbish pile outside the engineering building.

One of those beige towers from another era. Monitor long gone. Cables dangling like severed arteries. Most people walked past it. I stopped.

It was 2003, and I was living in Tokyo, working as an e-learning coordinator at Tokyo Keizai University. I had no budget for technology. No server. No IT support to speak of. Just a problem I couldn't stop thinking about.

That discarded computer would teach me more about product management than any course or certification ever could.

I just didn't know it yet.

The Gap I Couldn't Ignore

I'd landed in Tokyo through a series of decisions that, looking back, seem almost accidental. A phone call from Terachi-sensei, a professor I'd come to know during my exchange stints at the university. He wanted to know if I was interested in a role they were opening up. Something about English learning technology, an early learning management system, helping drive adoption and support academics.

I said yes before he finished the sentence.

The system I was hired to support was called ALC Academy. It was essentially a digitised textbook. Students could read translations, practise grammar, work through exercises. It was ahead of its time in some ways. Think of an early Rosetta Stone, or a simpler Duolingo before Duolingo existed.

But it was passive. Reading-focused. Students consumed content, but they couldn't really engage with it. They couldn't respond naturally, collaborate, create, or do any of the things we'd typically expect in a language classroom.

That was the gap.

The system also didn't allow teachers to enrich or augment what was essentially a fixed curriculum. If you wanted to add your own activities, your own context, your own ideas on top of the product, you couldn't. The content was locked. The experience was locked. Teachers were reduced to facilitators of someone else's vision.

I knew there had to be something better.

Finding Moodle

Around this time, I started working closely with Seki-sensei, who'd been recruited to Tokyo Keizai to implement ALC Academy based on his success at another university. I don't think I appreciated at the time how significant that move was for him and his family. Relocating your life for a job is never simple, especially in Japan. But he came, and together we did a lot.

We wrote a workbook together. More of a practical companion to the online academy, really. It took the activities and lessons from the digital platform and forced students to transfer that knowledge into new contexts. It wasn't perfect, but it proved something important: teachers needed space to add their own experience and ideas on top of any product. The best technology doesn't replace the teacher. It gives them room to teach.

Then I found Moodle.

I don't actually remember how I discovered it. Version 1.5. Open source. Designed for educators. It had discussion forums, assignment submissions, quizzes that could be customised. It let teachers build their own learning experiences.

It was everything ALC Academy wasn't.

But I had no budget. No server. No way to run it.

Which brings me back to that PC on the rubbish pile.

Building From Nothing

I took it back to my office, then went to Bic Camera in Shinjuku to buy a cable. That was the only excuse I needed to spend a few hours in one of the greatest electronics stores on earth.

I'd always been technical in a tinkering sort of way. Never studied code formally, never trained as an engineer. But my dad had bought my brother and me a PC back in 1985, when I was five or six, and I'd been playing with computers ever since.

I still remember those early games. World Tour Golf with its 8-bit graphics and banger tunes. Xeliard, which I played years later whilst "I'm Too Sexy" by Right Said Fred played repeatedly on Rage. My brother and I would sit in front of that beige box for hours, figuring things out, breaking things, fixing them again.

That's where the love started. Not in a classroom. Not from a curriculum. From play. From curiosity. From having a machine in front of you and wanting to know what it could do.

So installing Linux on a recycled PC wasn't intimidating. It was familiar.

I vaguely remember needing to learn how to torrent the operating system, and getting in trouble for the network traffic at the university. But the installation was smooth. Within a few days, I had Moodle running on a recycled PC that someone had thrown away.

Teachers started using it. Then more teachers. Eventually it was being used for research papers. I started presenting at conferences. Moodlemoots, academic events, anywhere people wanted to hear about what we'd built.

I didn't call any of this product management at the time. I didn't have that language. But looking back, that's exactly what it was.

What I Actually Did (Without Knowing the Words For It)

Here's what happened with that e-waste PC, translated into language I learnt years later:

I identified a gap in the existing product. ALC Academy was passive. Teachers couldn't customise it. Students couldn't engage properly. I felt the frustration in my own teaching.

I validated the need. I talked to teachers. I watched students struggle. I confirmed that the problem wasn't just mine.

I found an alternative solution. I researched what else existed. I found Moodle. I evaluated whether it could solve the problem better than what we had.

I built a prototype with no resources. A discarded computer. Free software. My own time. No budget, no permission, no formal support.

I iterated based on feedback. Teachers used it. They told me what worked and what didn't. I adjusted. I improved. I fixed what was broken.

I scaled adoption through training and support. I helped other teachers get started. I answered questions. I created documentation.

I presented the work to broader audiences. Conferences. Academic events. Research papers. I shared what we'd learnt so others could benefit.

Every single one of those steps is what product managers do. I just happened to be doing it in a university, with a recycled PC, because I was a teacher who saw a problem and couldn't leave it alone.

The Pattern That Keeps Repeating

Twenty years later, I built Guest Loop.

It's a platform for vacation rental hosts who want to own their customer relationships instead of depending on Airbnb and Booking.com. Different technology. Different market. Completely different context.

Same fundamental approach.

There was a problem I personally experienced. My wife and I own rental properties. We were frustrated with the existing tools. We wanted to build direct booking channels. We were tired of paying platform fees and having no control.

So I researched. I tried all the existing tools. I studied their pricing, their sales approaches, their products. I identified the gaps. I looked at forums, Reddit, LinkedIn groups, Facebook communities, anywhere vacation rental hosts were talking about their problems.

The same frustration kept appearing. Hosts wanted to own their customer relationships. They wanted direct bookings. The existing tools helped with guidebooks but didn't solve the deeper problem of customer ownership.

So I started building. First something that was just for me and my wife's properties. A tool we actually used. Then I realised others could benefit. Then I started talking to other hosts. Then I built it properly, with architecture that could scale.

The first version was ugly. The backend was horrible. Clunky. Confusing. Buttons in the wrong places. Workflows that made sense to me but baffled everyone else.

I shipped it anyway.

My wife was my first and harshest user. She'd try to do something, get frustrated, and tell me exactly what was wrong. Not gently. Not diplomatically. Just: this doesn't work, fix it.

That feedback was gold. Every complaint was a roadmap item. Every frustration was a bug to fix.

After dogfooding, after feedback from early users, we gradually fixed it. Smoothed the rough edges. Removed features that confused people. Added features they actually needed.

Some features I loved had to go. I'd built things I thought were clever, innovative, different. Users didn't care about clever. They cared about simple. They cared about getting the job done with minimum friction.

The product got better because we shipped it ugly first. If I'd waited until it was perfect, I'd still be waiting.

Twenty years between Moodle and Guest Loop. Different technology. Different market. Same pattern: find a problem you personally feel, believe you can solve it better, and just start building.

What Teachers Already Know How to Do

Here's what I want you to understand.

Every unit plan you've ever written is a prototype. You start with learning outcomes. You design activities to get students there. You sequence them carefully, building from simple to complex. You create assessments to check if it's working. Then you deliver it, watch what happens, and adjust on the fly when something isn't landing.

That's iteration. That's user research. That's product development.

Think about what you actually do in a classroom. Before the lesson starts, you've made dozens of decisions. What's the learning intention? What do students already know? What misconceptions might they have? What's the hook that gets them interested? What activities will move them from where they are to where they need to be? What will you do if half the class gets it immediately and the other half is lost?

That's product scoping. That's user journey mapping. That's contingency planning.

You've been doing this for years. You just called it teaching.

The Difference Now

When I deployed Moodle in 2003, I needed to understand Linux, server administration, networking, database configuration. The technical barrier was real. Not insurmountable, but real.

Now, you can build sophisticated applications without knowing how to code in the traditional sense.

I built Guest Loop using Cursor. It wasn't vibe-coded, where you just ask AI to make something and hope for the best. I primed it with context. I specified security practices. I designed architecture that could scale to a global audience. The AI was a tool, not a replacement for thinking.

But here's what's changed: the gap between having an idea and having a working prototype has collapsed. What used to take months takes days. What used to require a technical co-founder can now be done by someone willing to learn and iterate.

The skills you need haven't changed. Finding problems. Validating solutions. Building prototypes. Getting feedback. Iterating. Shipping.

Teachers have been practising these skills for years. The only difference now is that the technical barriers have fallen away.

Pull Your PC From the E-Waste Pile

I didn't have permission to build Moodle at Tokyo Keizai. I didn't have budget. I didn't have a technical team. I just had a problem I wanted to solve and enough stubbornness to try.

That same energy is available to you now. The tools are better. The barriers are lower. The cost of failure is smaller.

You've spent years developing skills that transfer directly to building products. You understand users because you've taught them. You understand iteration because every lesson is an iteration. You understand shipping imperfect things because you've handed back marked assignments covered in red pen, knowing the feedback is how students get better.

The first version will be ugly. Ship it anyway.

The feedback will sting. Learn from it anyway.

The process will be uncomfortable. Trust it anyway.

You don't need permission. You don't need a budget. You don't need a technical co-founder.

You need a problem you personally feel. A belief that you can solve it better. And the willingness to start.

Pull your PC from the e-waste pile. Build your first ugly thing. Ship it.

The world needs what only you can build.

This story is from "Teach Yourself Out," which shows teachers how to translate classroom skills into products, income, and options. If you want the full path, the book goes deeper.