1) Trust is key:
Particularly early in development for a new product there will be a lot of Product Backlog items which may or may not be understandable without development experience. At this early stage you'll be relying on your Scrum Master and in particular the development team to explain the need for these things so that you can properly prioritize them. My suggestion is to build a good relationship with the Scrum Master and at least one (preferably all) of the developers who can act as a guide for some of the more esoteric work that may need to be done in the sprint.
2) Your job is to serve the team:
The ultimate goal is to ship great software, that's why you're there, that's why the team is there and in a roundabout way that's why the Scrum Master is there. That being said, which role in a Scrum organization is most likely to get blocked, thus preventing the shipping of said software? If you answered the Scrum Team then you are correct. While it's not something that you can prevent altogether it's definitely not a problem that you should contribute to.
Let's imagine a scenario where the development team is working on various aspects of your product. One by one, (or even all at once) they need some feedback from the product owner so they call you and it takes you day (8 productive hours) to get back to them. One day turn around time isn't so bad right?
By applying the power of math, assuming a 14 day sprint and the loss of one day due to the product owner waiting to get back to the team, that's slightly more than 7% of the sprint lost to the product owner turnaround time which is likely a wide enough margin to cause sprint failure. Part of the whole point of having a product owner is to provide a single dedicated source of feedback for the team since the actual customers are usually off doing other things (which usually don't include software development).
My thought on the matter is that the Product Owner (and the Scrum Master) should adopt a helpdesk mentality when the Scrum Team requests some feedback. That request should be turned around in a matter of hours, minutes preferably. If at all possible, try to position yourself in the office WITH the Scrum Team and make them feel comfortable walking into your office (or cube, or whatever) to ask questions and get feedback when they need it.
3) It's your job to understand our customers:
Q: What do developers know really really well?
Q: What is unlikely for a developer to know really well?
This means contacting customers who provide feedback personally, spending time with customers who actually use the product and/or a legacy solution to find out what they like/don't like. Being an active part of the online community (if there is one) for the business area and just generally getting into the head of the folks who will ultimately use your product.
This also means putting your ego aside in many cases to allow some backlog items you may really like to take a backseat to functionality that may be important to the customer base as a whole.
4) The Team occasionally fails
Each sprint adds value to the final product but that doesn't mean that the Scrum team will always deliver exactly what they committed to. Some sprints may see them over-deliver while other sprints that fail to implement everything. Neither Scenario is good or bad, it simply means that software development (at the team level) is unpredictable at best.
Think of it this way, if the team maintains a planned velocity of 100 hours per sprint but delivers the first sprint with an actual velocity of 90 and the second sprint with 110, what's the average?
The point here is that sprint success or failure isn't necessarily important to the Product Owner so much as the team delivering value to the product so don't sweat the details here and use some of the trust we talked about earlier. The team occasionally fails because they're trying new techniques, setting ambitious goals for themselves and is generally looking to improve every sprint, this results in the occasional failure but will generally trend towards a faster more efficient team over the length of the entire release.
5) You are not a Project Manager:
This part is actually a bit tricky but ultimately, it's your neck on the line as the Product Owner if the Product ends up sucking. But that doesn't mean that you set the schedule for the team, worry about how the allocates the work or god forbid, plan the sprint backlog. It's your job to set the teams priorities at the backlog item level and to provide valuable feedback for the team. If you attempt to control any aspects of development past these levels then frustration and team unhappiness will result.
You see the team understands the technical intricacies involved with their work because their the ones doing it, they (should) know each others strengths and weaknesses and even each others schedules better than any Project Manager, Scrum Master or even Product Owner ever could which makes the team the most logical place to hammer out those details. This is the primary reason why the team decides on the amount of work to pull into the sprint backlog rather than any other role.
6) The Sprint Review is not a dog and pony show:
I could go on for hours about any one of these six points and you may see more detailed posts about them in the future. The truth is that a strong Product Owner is often the secret sauce that separates a great software development team that amazes customers from a mediocre one that simply pushes out a release every now and then.