Wk 2 – Update 1

A Process, a Plan, and Absolutely Nothing Working

One week down, fifty-one to go.

Last week, while rebuilding Wheel of Questions, I realized I had another problem to solve. If I’m going to build and document a new project every week, I need a repeatable way to get ideas out of my head and into something resembling a plan.

As anyone who has worked with me will attest, getting ideas out of my head is rarely the problem. Getting them organized, and keeping them from multiplying along the way, is another matter.

So thwe came up with a process.

Six questions. Every Sunday.

Thwe developed six questions that I’ll answer at the beginning of every project:

1. What’s the story?
2. Where did the idea come from?
3. What am I trying to make?
4. What do I hope to demonstrate on Saturday?
5. What could possibly go wrong?
6. How should the story end?

The questions aren’t particularly sophisticated. That’s intentional.

I don’t want to spend Sunday morning filling out a project charter. I want to capture the idea, why it interests me, what I hope to accomplish, and why anyone else might find it interesting.

The answers become the starting point for my Sunday blog post. AI helps me organize my thoughts, explore different ways to tell the story, and improve the flow. I make plenty of changes, rewrite things that don’t sound like me, and decide what ultimately gets published.

It’s a collaboration, not an exercise in outsourcing my personality.

Thwe developed this approach while writing about Wheel of Questions last week. Today, I used it again for Load Goblin.

Within a few minutes, I’d worked through the story of my friend Bruce, the Timex Sinclair 1000, cassette tapes, and my ambition to make forty-year-old technology do something it was never intended to do.

But getting the story down is only the beginning.

Stop building. Start asking.

I’ve been experimenting with another change in how I work with AI.

Rather than describing an idea and immediately asking AI to build it, I’m asking it to interview me first.

That sounds obvious. It’s what product managers do. We ask questions, challenge assumptions, explore possibilities, and try to figure out what we’re actually making before anyone starts writing code.

Yet when working with AI, it’s incredibly tempting to skip that part. You describe something, and the machine is more than happy to start building it.

Sometimes a little too happy.

So I’m trying to establish a repeatable process, and it starts with telling AI how I want us to work together.

Here’s a simplified version of the prompt anyone can try:

I’m starting a new project that I want to build and demonstrate by Saturday.

Before writing any code, act as my product management partner. Help me turn my initial idea into a realistic scope for one week.

Start by asking me those six questions, one at a time:

1. What’s the story?
2. Where did the idea come from?
3. What am I trying to make?
4. What do I hope to demonstrate on Saturday?
5. What could possibly go wrong?
6. How should the story end?

Once I’ve answered, interview me to refine the product scope. Ask one question at a time, using my previous answers to guide the next question. Challenge my assumptions, identify decisions I haven’t considered, and suggest simpler alternatives when I’m making things unnecessarily complicated.

When I introduce a new feature or idea, don’t automatically agree or add it to the project. First explain what it would cost in time, complexity, or risk, and ask what we’re willing to remove to make room for it.

Look for existing components, code, and services thwe can reuse rather than rebuilding things that don’t differentiate the product.

Don’t start writing code until thwe have agreed on the scope and I’ve explicitly approved moving forward.

Help me turn the initial story into a blog post that sounds like me, but treat it as a working draft. I’ll make the final editorial decisions.

At the end, summarize what we’re building, what we’re not building, the biggest risks, and what success looks like on Saturday.

It’s not magic. It’s just a set of instructions about how I want AI to behave.

The important part is asking one question at a time. That creates an actual conversation rather than a giant questionnaire or a fifty-page requirements document that neither of us will read.

For Load Goblin, this led us through decisions about guest access, personal libraries, sharing programs, metadata, and the cassette-player experience.

The conversation was productive, not because AI had all the answers, but because the questions forced me to make decisions about things I hadn’t fully considered.

Of course, I still managed to expand the scope along the way. Apparently, 20 years of product management experience doesn’t cure that condition.

Why build the boring stuff twice?

Another thing that came out of Sunday’s conversation was realizing how much of last week’s work thwe could reuse.

Wheel of Questions and Load Goblin are completely different products. One spins a wheel to randomly select questions. The other attempts to resurrect software from cassette tapes for a forty-four-year-old computer.

But underneath, they have quite a bit in common.

User accounts, login, password management, administration, database connections, and some of the basic website infrastructure. None of those things make Load Goblin particularly interesting, but they still need to work.

And thwe just spent a week building and improving many of them.

Rather than asking AI to reinvent all that stuff, thwe decided to reuse the pieces of Wheel of Questions that make sense.

This is something I’ve advocated for throughout my product management career. Spend your time and resources on the things that differentiate your product. Reuse, borrow, or buy the things that don’t.

It’s especially important when you’ve given yourself exactly seven days to build something.

The interesting part of Load Goblin isn’t whether I can create another login screen. It’s whether I can get a modern phone to successfully load a program onto a Timex Sinclair 1000 through an audio cable, and eventually give people a way to discover, play, and share those programs.

That’s where I want to spend my time.

Hopefully, the hours invested last week will save us hours this week.

And if this continues, perhaps by Week 52 I’ll have a pretty decent collection of reusable components.

Fifty-two domains? Oh crap.

One other thing I hadn’t fully considered when committing to 52 projects in 52 weeks was the cost of giving each project its own little home on the internet.

Wheel of Questions already had a domain. Load Goblin did not.

So naturally, I bought loadgoblin.com.

It’s a great name. I’m happy with it.

But at one new domain every week, this little experiment could turn into an expensive collection of DNS records.

I’m starting to think some future projects may need to live on subdomains of something I already own. Not every idea needs its own piece of internet real estate, especially when I have absolutely no idea whether it’ll survive until Saturday.

Perhaps domain registration needs to become another question in my new process.

Does this ridiculous idea really deserve its own domain?

I suspect I’ll be terrible at answering that one.

And now for the part where nothing works.

With the storytelling, scope, and reuse strategy reasonably sorted out, it was time to actually make something.

Thwe already had a rough plan for Load Goblin, and work had begun on generating the software. In theory, the process seemed straightforward enough. Take some BASIC code, turn it into a program file, encode it as audio, and play that audio through the Timex Sinclair 1000’s cassette input.

Thit seemed pretty confident about this.

I was considerably less optimistic.

Before going much further, I wanted to prove that the computer could load anything.

I’d already powered up the TS1000 and confirmed it could accept BASIC commands. But that didn’t tell me whether its cassette-loading circuitry actually worked.

Thwe searched for a known-good WAV file online to establish a baseline, but finding one I could actually download and use proved surprisingly difficult.

So thwe built a little test application to play audio files and started with the programs thwe had generated, including Hello World.

I connected the TS1000 to my TV, plugged in the 16K RAM expansion pack, hooked everything up, typed LOAD "", pressed Enter, hit Play, and wished for the best.

Nothing.

The squiggly lines on the screen stayed squiggly. No indication that anything interesting was happening.

Maybe the volume was wrong.

Adjust. Play.

Nothing.

Try again.

Nothing.

At this point, I started wondering whether the damn computer worked at all.

Enter the janky thrift-store Walkman.

Time for a control test.

I’d picked up an old portable cassette player, along with some tapes, hoping I could use the original technology to verify the machine.

I replaced the batteries, opened the cassette compartment, and discovered a tape containing some strange recording of an alternative-news program.

No idea. Put that aside for another rabbit hole.

Out came the mystery news tape. In went a game called Cube, which I was hoping might be some sort of Rubik’s Cube clone.

At this point, I didn’t particularly care what Cube did. I just wanted to see something happen.

Typed LOAD "".

Pressed Play.

Nothing.

Flipped the tape. Adjusted the volume.

Nothing.

Swapped the audio cable.

Nothing.

Switched back to the phone.

Nothing.

Back to the Walkman.

Nothing.

I was running out of combinations, patience, and comfortable positions on the floor.

My knees were not enjoying this trip down memory lane.

Wait. What the hell is EAR?

Eventually, I pulled out the original manual that came with the computer.

Yes, the manual.

That thing I generally avoid reading until I’ve exhausted every other possibility.

And there it was.

The TS1000 has two audio jacks: MIC and EAR.

I’d been plugging the cable into MIC because, well, I was sending audio into the computer.

Apparently, in the world of 1982 cassette computing, EAR is the input and MIC is the output used to record programs.

That makes perfect sense once you understand that the labels refer to the cassette recorder’s connections.

It made absolutely no sense to me while sitting on the floor wondering why nothing worked.

Aha!

I’d found the problem!

Hopes restored. Optimism returning.

Plugged the cable into EAR.

Started with the phone.

Nothing.

Adjusted the volume.

Nothing.

Fuck.

Switched to the Walkman.

Nothing.

Adjusted the volume.

Nothing.

Fuck. Fuck.

Mono? WTF?

Now I’m on my phone, searching for every possible reason a Timex Sinclair 1000 might refuse to load a cassette.

Volume levels. Audio settings. Cable types. Signal quality.

I have an enormous box of random cables that I’ve been accumulating for years. I almost never use any of them, but I keep them because someday I might need one.

Apparently, someday had arrived.

I dug through the collection and found a handful of audio cables left over from when my son was trying to connect some unusual microphone and iPhone setup to his gaming rig.

Surely one of these would work.

Back to the phone.

Nothing.

Volume.

Nothing.

Different cable.

Nothing.

At this point, I was starting to question not just my wiring skills, but my entire choice of project.

Wait.

What did that say about a mono cable?

Seriously? I don’t have one of those!

After more research, I ordered a shielded mono audio cable for delivery Monday.

Order placed.

Hopes slim.

Bruce, we’ve been here before.

Somewhere in the middle of all this, I couldn’t help thinking about my friend Bruce.

Forty years ago, thit didn’t exist to help us troubleshoot anything. Bruce and I struggled to load programs onto a Timex Sinclair using cassette tapes, trial and error, and whatever patience two kids could muster.

Here I was, forty years later, doing essentially the same thing.

Except this time I had AI helping me.

Thit was perfectly happy to figure out how to generate BASIC programs, encode them into .p files, and convert those into audio.

And I was sitting on the floor, with increasingly unhappy knees, trying to get a computer to do absolutely anything.

Maybe vibe coding software to make vibe coding on a TS1000 possible wasn’t such a brilliant idea after all.

I started this experiment because I wanted to see what I could build in a week with AI.

Now I was wondering whether I’d managed to pick a pipe dream for Week 2.

All I wanted was to see that mysterious Cube game run. I didn’t even know what it did.

Surely that wasn’t asking too much.

Sunday night.

By the end of the day, thwe had accomplished quite a bit.

A repeatable process for starting projects. A clearer product scope. A plan to reuse the infrastructure from Wheel of Questions. The beginnings of a website. And another domain name to add to the collection.

But the one thing that mattered most still hadn’t worked.

Not Hello World.

Not our test program.

Not even Cube. Whatever that is?!

Nothing.

I hadn’t proven the computer could load anything, from anyone, using any method.

I was only two weeks into this fifty-two-week experiment, and I’d already managed to choose a project that might be impossible to demonstrate.

Maybe the cable would fix everything.

Maybe the TS1000 was broken.

Maybe I’d made a mistake.

I go to bed unsettled, nervous, and hoping that one last Hail Mary would work.

That package couldn’t come soon enough.