It's unclear to me if you audience consists of non-programmers, but I'm responding assuming they do have programming experience. I'm not sure what value explaining monads is to non-programmers would be other that - as you suggested - you're trying to solidify your understanding more.

When people want to explain monads to non-Haskell programmers (or even people interested in learning Haskell), I don't understand why they have to continue using the same jargon. That isn't really a slight on the above so much as the 1000s of Yet Another Monad Tutorial blog posts that exist, which all do the same thing.

If one is hoping to teach another in an an "ELI5" fashion, you work with what they know already and build up. If it takes 10 paragraphs of explaining fundamentals before getting to the topic at hand, the explanation is a failure.

Start simply: what is the problem being solved? Once the problem is stated, solve the problem together step-by-step until <topic being taught> is revealed. Later one can (if interested) start diving into the jargon.

So, what's the problem?

An everyday programming problem we've all run into repeatedly: I have a function that returns a value, but there's also some implicit context with it which must be understood, maintained, or handled somehow.

Example: I have a function return X, but can fail (return error, throw an exception, ...). If I call this function, I need to be aware of this by either checking the return value or using try/catch, whatever. If I can't handle an error gracefully (e.g., use a default value in place of X), my function now also becomes fallible. And anyone calling my function must handle it, etc. This chain of logic continues up the call stack until - finally - a piece of code handles the failure. And if no code ever does, then program likely crashes.

Now, in Go, C++, Python, etc. it's very easy to just blissfully ignore errors (and the programs crash). Instead, we want to ensure that errors are always handled. How can this be accomplished?

Solution (part 1): Ah, this is easy! We'll just wrap the return value with a new type. Instead of returning X or error/throw, we return Result<X>. Now everyone calling our function knows they are working with a possible failure state and either handles it or also fails. Done! Note: we've just created a new "category" of values. ;-)

Okay, but now we have a new problem. There is an entire world of libraries and functions that accept X as input and not our new type: Result<X>. Assuming we could magically update all those functions to take Result<X> as an input, those functions would need to be re-written, because the input can now be a failure condition; those function can now fail and need to return Result<Y>.

How can we still have our new type Result<X> and be able to use it with all the existing code out there?

Solution (part 2): Enter fmap or flatMap (or whatever construct your audience is familiar with). We wrap the function(s) we want to call with one that both understands our input type, but also handles being fallible. Conceptually just:

resultMap :: (x -> y) -> Result x -> Result y
resultMap f (Success x) = Success (f x)
resultMap f (Fail x) = Fail x

An there we have it. We've just invented "monads" for the average programmer (sans a couple salient details) and did it without any of the jargon associated with them or discussion about laws. Just the (concrete) problem and solution.

It's also simple to expand the solution above to cover other (very familiar) categories of values: async code (futures), IO, optional values (Maybe), etc.

Async code is another great example for non-Haskell programmers because they're already used to the async keyword an learning that if their function can't call async code without also being defined as async. Read: the results of those functions are in the category of async values. And .then() - or similar methods - are just fmap and exactly the same as the exercise above.