Does Scrum Master need to know about the product itself?

The Scrum Master must know enough about the product domain to adequately serve the PO, and to facilitate the team's product understanding.

The Scrum Guide says:

The Scrum Master serves the Product Owner in several ways, including:

• Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible

Would it be possible to facilitate valuable discussions if you don't know what they really add towards the benefit of the product?

The thing @Ian Mitchel is quoting does not say that the Scrum Master needs the knowledge about the product or domain beforehand. That is only needed at the PO.

The SM as well as the developers do not have to know product or its domain, but the SM will then have to ensure that the whole Scrum Team understands the PO explaining goals, scope and product domain.

I am currently working for the automotive industry in our company. But if my company would dismiss all of automotive and would concentrate on medical, I would not say that I have to leave, as I do not know the domain. I know how to work as SM and could also support a Scrum Team developing for medical. Would be a difference, though, if I changed from a software developing company to a manufacturing company.

The SM as well as the developers do not have to know product or its domain

There is a good point in this approach, however, I would tweak it a little bit: the SM has to have at least as good product or domain knowledge as the developers:

• In a research lab, if all devs have a PhD in quantum mechanics, it is probably essential for the SM, too.
• In FMCG I guess it is a matter of weeks to gain a good enough understanding of almost everything.

In a research lab, if all devs have a PhD in quantum mechanics, it is probably essential for the SM, too.

I used to be SM within the worlds leading lithography machine manufacturer, where indeed all my team members had scientific PhD, whereas I did not strive further than my bachelors. Still was able to be a pretty decent SM though. But it does present its challenges, that's for sure.

Thanks guys for your contributions. 

and What about User Stories? Should a Scrum Master understand US and its value and apps/modules/features affected by US?

SM will then have to ensure that the whole Scrum Team understands the PO explaining goals, scope and product domain.

100% agree.

To provide a good result scrum master must have known about the product and many more things related to this product.

What about User Stories? Should a Scrum Master understand US and its value and apps/modules/features affected by US?

User Stories are not part of Scrum. They are an Extreme Programming concept that has gained wide adoption by Scrum and other agile practitioners.  If your team decides that they want to use User Stories, then as a Scrum Master you need to understand how to structure them and the benefits that they can provide.  That would be your contribution.  The actual content of the User Stories will be up to the Product Manager and Development Team to create and understand.  Remember that the role of Scrum Master is to help the team be more effective and efficient at producing regular increments of value by using the Scrum framework.  Your need to understand the products and work being done is limited to what you need to know in order to help the team achieve that goal.  



While on the topic of User Stories I will say that many people using User Stories are not actually using user stories and that is not a problem.  In the Scrum Guide section describing the Product Backlog this is stated.

Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".

User Stories, done correctly, can satisfy this need if you add to them the concept of Acceptance Criteria. (Acceptance Criteria was not part of the original definition of User Stories.)  But so can MANY other ways of capturing that information.  As a Scrum Master you are responsible for helping the Scrum Team understand and appreciate the benefits of capturing those attributes. So as long as your teams are capturing the described information, they can call their Product Backlog Items anything that they want. 

I believe this all depends on the existing characteristics of the Scrum Team and organization.

If there's a culture of openness and accountability, the Scrum Master might not need to understand the product at all, as long as they can leverage contributions in a way that maximizes transparency, inspection and adaptation.

It might be sufficient to get the right people talking to each other, and rely on those people to speak up in the right way.

I'm probably the member of my company's Product-Engineering team who uses the product the least, and although I have a background in web development, I haven't ever developed our platform. So I'm often very out of context about the specifics of what the teams are building.

Nevertheless, I have a pretty good sense of when conversations are taking place without the right people present, or when people are avoiding certain uncomfortable topics. I can observe and expose trends and bottlenecks in the workflow, and encourage colleagues to inspect them.

I often ask questions to encourage my colleagues to confront a situation. I don't find a lack of in-depth knowledge holds me back, because the answer isn't usually for me. It's to get my colleagues to validate that they are aligned, or tell each other that they disagree about something.

When it's important for me to gain context about a specific subject, I can usually rely on my colleagues to give me just the information I need.

I've oversimplified my situation to illustrate that skills can overcome any knowledge deficit, but in reality, I'd favour taking on as much knowledge as possible. It's rarely an advantage to not know something.

But I'd generally favour understanding the business strategy, desired outcomes and product vision over specific functionality and the intricacies of an individual Product Backlog Item.