Storyboarding and Product Owner's role

One "non-traditional" technique that I used in a particularly technically-complex project was to construct a sort of "knowledge base" (KB) that was managed by the Product Owner (in association with Stakeholders), and provided to the team.

This KB was first used as a repository of authoritative information about the complexities of the underlying business. Then, as implementation-related technical decisions were made concerning the interpretation of these things, those were added to the KB as well – "footnoted to" supporting information elsewhere in the KB. The "user stories," then, referenced these particular added sections.

It seemed to work pretty well ...

When you need to build a product (or even some module, or feature), you need to have a list of items that are part of that product, so that you know what you are currently working on, what to build next, track and communicate progress, etc. In Scrum, these are items in the product backlog (usually expressed as user stories).

The product owner is the one responsible for managing the product backlog, to create the items in it, prioritize them, detail them, and make sure the items are clear enough so that everyone understands them.

The product owner can obviously just sit down and create a bunch of items and user stories and add them to the backlog. If they know exactly what they want, and know what they are doing, this approach can work. Sometimes though, this approach might be insufficient. Depending on the product's complexity, on how many stakeholders there are, etc, the product owner might miss some activities or interactions between user stories when they just write them down as a list. They might also have a harder time prioritizing them too, if there are dependencies between them.

Storyboarding and user story maps are techniques to better visualize stories, the interactions between them, the activities and roles necessary to build the product. They are good techniques to gather requirements from stakeholders, discuss with everyone what's needed, and create user stories from those discussions. With user story maps you can also decide easier on possible releases since you now have a map of stories instead of just a list of them, and you can more easily draw lines of separation between what's needed and important now and what can wait for later.

What should a product owner do with storyboarding/storymapping and the backlog?

The product owner use them to make sure the product is properly defined so that everyone knows what needs to be built. It's the product owner's job to manage these, but as you mentioned yourself, a shared understanding must be achieved (for ex, if the product owner knows what's needed but developers or stakeholders have no clue, then there is no point in doing storyboarding or story maps). Also, how this shared understanding is achieved differs from company to company; some companies use techniques like storyboarding/storymapping to do that, some don't. Whatever floats their boat.