In this week’s episode of Troubleshooting Agile, Jeffrey Fredrick and I dive into a fascinating session run by Timo at CITCON. He approached the room with his tongue firmly in his cheek to argue that we should do our testing later—specifically, right in production.

While half the room left because they couldn’t spot the sarcasm, it blew a few minds when I stood up and said: “Actually, testing in production is a brilliant idea.”

Jeffrey and I look back at how tech titans like Etsy have successfully shifted all the way to the right—using real credit cards to buy real items from real creators every single hour to prove the ground truth that their system actually works. We also break down how the rise of AI makes this kind of production observability, logging, and metric-tracking absolute table stakes for survival.

Stop hiding your software from the wild. Tune in to find out why you need to start testing in production (and no, we aren’t telling you to skip your unit tests!):

👉 Watch on YouTube here:

I bet the answer is a resounding no. Yet, adventurous organizations are mindlessly handing over end-to-end product ownership and production access to autonomous agents without a second thought.

Jeffrey Fredrick and I sat down with a room full of brilliant people at CITCON:AI in Helsinki to tackle a question most people are ignoring: What should you not use AI for?

Our conclusion? You can let large language models generate options and trade-offs all day long, but you must never hand over your decisions or your ownership. AIs don’t have names, addresses, or bank accounts—you can’t take away their bonuses or sue them when they delete your production database.

If Carl the Chatbot is no smarter than Bob the Intern, why are you giving him the keys to the kingdom while you go to the beach?

In this week’s episode of Troubleshooting Agile, Jeffrey and I look at the real-world consequences of treating silicon pattern-matchers like expert evaluators, the true nature of risk mitigation, and why AI hasn’t actually created a single new problem for us—it just lets us make our existing mistakes much, much faster.

👇 Drop your own AI horror stories or structural guardrails in the comments below!

You’re wrong.

In a product context, blindly answering the question as asked means you are blindly accepting the underlying assumptions behind it. You are completely missing the bigger win: the opportunity to learn what your product could—or should—actually be.

In this week’s episode of Troubleshooting Agile, Jeffrey Fredrick and I dive into why answering questions directly is often a transactional mistake. We discuss:

• The “Lizard Man Quotient” and Gojko Adzic’s lizard optimization: What extreme outlier users uploading blank slides can teach you about hidden product value.

• The origin of Flickr: How trying to build a game about monsters fighting accidentally resulted in a massive photo-sharing website.

• Our own frantic battle with Descript: Why a confusing interface makes users ask all the wrong questions.

Sometimes, the best answer you can give is mu—unasking the question entirely.

Stop answering unhelpful questions and start uncovering the real context. Click the link below to listen to the full episode.

👉

Soundcloud:

YouTube: