A metaphorical question like this does require a good explanation . . . and I will provide one. Let me describe two cases.
Case One, developed according to Scrum
In the first case, you are running your development according to Scrum. As a product owner, you have your end goal clearly defined. You chop up your end goal functionality in small pieces, so you have a complete set of stories for the product available. These stories are fed batch by batch to your development team.
You clearly explain for every story what the result should be and why this is needed. This way you build your product in small, incremental steps. Every sprint, your product is growing and you are getting closer to your envisioned end result. Also, you have your stories prioritized so the important parts are built first. Sounds like the way it should go . . . right?
Case Two, developed according to Scrum
In this second case, as a product owner you run your development according to Scrum. You have your end goal clearly defined, and only a set of stories available to cover the next two sprints. You clearly communicate with every story what the result should be, why that piece of functionality is needed, and how it fits with your envisioned end goal. After every sprint you evaluate the result, learn from the result, and start to extend your story set until you again have the next two sprints covered.
This way you are defining your product as you go, while you still keep the intended end goal clearly in sight. Anything you learn can be directly translated into the sprint without throwing away all the preparation work that you have done. Also sounds like the way it should go . . . right?
Two ways to paint your product
Case One I see happening most of the time. And I understand that. It gives a clear framework and it provides management with a tangible result of the work of a product owner, even before development is started. In the end you need some proof that you are doing your job when you are in a classic organization. This way you can always show that it is not you if development fails somehow.
In Case Two you are lacking that "work proof" and you have to rely on "results proof." For that you need to have the trust of management. But the benefit of this way of working is that you learn while you are going forward without wasting any work that was done ahead of development. So less waste, more control, and a better chance of hitting your goal.
Any new product is a journey into the unknown. Sure, you see an opportunity in the market, and sure, you have an idea about how to fulfill that opportunity. But everything is based upon interpretation, some vague market research with a focus group and a gut feeling.
In Case Two you can go back to your focus group, show the results of your sprint, and take the feedback directly into stories for the next sprint without feeling the pain of throwing away work.
But as a product owner, you need to be really close to your team in this second case. Observe every element during the sprint, be sharp in the sprint demo, and directly understand the implications of every piece of functionality created.
So are you an artist?
Case One is painting by numbers . . . more of a Bob Ross scenario. As a product owner you define up front the parts that the development team needs to color in fully. Nice result for people who are not capable of painting. You will not learn, and you will get the predicted product, but there's no guarantee on the predicted market result.
Case Two makes you an artist. It is the Rembrandt scenario. You play with your lines, interact with your market and your team, and learn from every stroke you make, discovering elements you didn't plan on. You are continuously innovating and have a far better chance of achieving your desired market result.
Special thanks to Bente Diemer, who came up with the painting metaphor while doing research for UX in Scrum.