Test-n-Tell - tiny apps, Big ideas

  Building a product is a long and laborious process. Sometimes it's painful. Sometimes it's fun. Most of the time it's both. Eventually you get to the point where the product is sitting in front of you. You tested it. Your friends and family tested it. Nothing seems obviously broken. So now it's time to publish.

  In the last article, I covered the first proper playtest of my game and how I organised it. A lot of the feedback I received wasn't actually about gameplay. People commented on the visual style, how the game looked on different devices, whether things felt too small or too big, and whether the whole thing looked consistent.

  It’s an exciting moment when you hold a playable build of your own game. You’ve already spent hours testing it yourself and you think it’s finally ready to go out there for wider testing. But how do you actually put your game into other people’s hands?

  The beginning of development went surprisingly smoothly. My game concept was simple and well understood, so Codex had no problem getting the project started. It created the basic structure in Godot , set up a playable scene and implemented the core rules. Very quickly, I had something resembling the main gameplay screen where I could move balls around the board and see whether the basic mechanics actually worked.

In this series of posts , I am sharing my experience creating a game from absolute zero as a non-developer and non-designer. In the introductory post , I covered why I picked a game for this experiment. Today, we'll go through the first steps of the process: selecting and setting up the key tools.

My blog's stats are clear: people are interested in practical experiences. Especially when it comes to AI and vibe coding tools. Luckily, that's what I've been doing these past few months - heavily using AI to create a digital product end-to-end. This series will get into all the fancy and stinky details of my process, challenges I've encountered along the way and, of course, the final result accompanied by the cost breakdown.

  I have been using Codex more and more recently. Not in a “look, AI wrote me a todo app” kind of way. More like: I need to ship my actual product, fix real bugs, improve real tests, and not spend my evenings arguing with a robot about why it deleted half of my codebase.

The job of a product manager is already changing. We use AI more and more in our daily work, and there is no sign of this slowing down. Writing, research, analysis, prototyping, summarising calls, checking requirements, preparing strategy docs, testing product ideas - all of it can already be supported by AI.

  There’s a persistent myth in product development: that what you ship is the roadmap. In reality, what you ship is the organisation that built the roadmap.

  Spreadsheets are among the most powerful tools in modern organisations. They clarify plans. They align teams. They make trade-offs visible. They help leaders reason about complexity. But they also create one of the most dangerous illusions in product development: the illusion of certainty. 

  I've been doing a lot of vibe coding lately, and one tech stack emerged for me as the most practical. Spoiler alert 1: it's Firebase + Codex + Google Cloud. Spoiler 2: tomorrow it could change.

  Everyone who has ever tried to create a product has their embarrassing failure story. Here's one of mine.

  I have built products in many different industries: HRtech, marketing, last-mile.. But one industry, where I really wanted to work, always eluded me - that's Education tech. The stars were never rightly aligned for me to work in EduTech until I decided to build my own EduTech app.

  Whether we like it or not, we all need to be competition-aware as PMs. Most of us have competitors, and understanding what they do might help us to win in the market.

  Is it only me, or have we stopped talking about frameworks? Long gone debates about Agile vs Waterfall, we stopped fighting over TDD vs BDD or KANO vs effort/value... it's KANO by the way, KANO is way superior.

  A common misconception when people say Product-led org is to assume product managers are running things. That shouldn't be the case. Product-led is about the mindset of everyone.

  In this series, I've tested and reviewed multiple tools in the AI agents category. Some of them are useful, others less so, but one thing is certain: this category has a huge potential to change our whole industry and have major effects on people's roles.

  I continue to test different AI agents that could create digital products with no coding knowledge required. Next in the list is the tool called Replit .

  Imagine spotting a problem in your daily life. Maybe it's a particular task you need to do that is frustrating, maybe it's something your friends or family need. Most importantly, you think you know how to solve that problem, but you're not a "technical person" and can't build apps, what can you do?

  Lately, I've been trying and reviewing modern AI agent tools that can write code, create designs and build full working products. While doing that, I realised PMs need to steal another practice from the engineering playbook - peer reviews.