Three Types of Leadership
Scrum is a simple framework with three roles: product owner, development team, and Scrum Master. Each role provides a distinct type of leadership. As the product owner, you lead the product and are responsible for its overall success. The cross-functional development team makes the design and technology decisions; and the Scrum Master guides process and organisational change, as the following picture shows.
While the three roles exercise different leadership, the people involved must effectively collaborate to achieve product success and align product strategy, roadmap, backlog, design and technology, and process decisions—without losing focus of their respective core responsibility. 
Lead the Product
As the product owner, you should lead the product and guide the development effort by providing an inspiring vision; a validated product strategy that clearly communicates the product’s value proposition, target group, stand-out features, and business goals; an actionable product roadmap that details the strategy and states how the product is likely to evolve; a prioritised product backlog that captures the functionality required; and by engaging the stakeholders in the right way, for example, inviting them to product strategy and roadmap workshops and sprint review meetings.
While I’d like to encourage you to involve development team members and key stakeholders in the visioning, strategising, and roadmapping work, you should lead these activities with the aim to maximise the value your product creates. This may mean making tough decisions and saying no to some ideas and requests, while trying to be an effective, balanced leader—avoiding the pitfalls of being too authoritarian and not assertive enough.
Providing the right product leadership is demanding; it requires a specific skills set and usually your full attention as the person in charge of the product. Consider all the things you have to do: be in contact with the users to understand their needs and validate ideas; manage the internal stakeholders and keep them in the loop; regularly review the product strategy and roadmap thereby considering market trends and the competition; work with the development team on the product backlog and answer questions that arise in the sprint; attend the sprint events—and the list goes on. 
Nevertheless, product owners often step in and take on additional responsibilities, such as looking after the development team and resolving conflicts in the team, or making design decisions, when the Scrum Master or dev team do not provide the necessary leadership—be it that they lack the time or skills, or that there is no Scrum Master at all. As a consequence, product owners can become too tactical and inward-focused, too concerned with team and process issues, and neglect the strategic product work.
This risks no longer seeing the wood for the trees. In the worst case, the strategy is no longer valid, but you do everything you can to steam ahead, asking the team to push out more and more features. On a personal level, taking on additional responsibilities is unhealthy and unsustainable: You will end up overworked if you try and keep up all the product work and take on dev team or Scrum Master duties.
Do the Right Thing
As the product owner, you are not responsible that the team members collaborate and manage their work effectively, that the right user experience (UX) is created, that the right software architecture is used, and that the right technology decisions are made. That’s the job of the development team.
You are also not responsible that the right process and methods are used, that impediments are removed, that stakeholders and management understand agile principles and practices, or that the necessary organisational changes are made—be it establishing an effective product management group, adjusting roles and responsibilities, or providing the team with an environment that is conducive to creative work. That’s the responsibility of the Scrum Master.
While it’s great to care, you should refrain from taking on additional responsibilities, as this will only stabilise an ineffective setup: If you can carry out Scrum Master work and look after the team, then why would it be necessary to hire a dedicated, qualified Scrum Master? If you can do the UX design, then why hire a designer?
As hard as it may be, say no, provide the right leadership, and focus on your job—achieving product success, not managing the development team or the process.
 I have placed user research, sprint goal selection, and product backlog refinement between the product owner and development team in the picture above, as these responsibilities are shared by the two roles in Scrum. You should therefore involve development team members in carrying out user research activities like observing users and listen to their feedback on prototypes and product increments. The same is true for choosing the goal of the next sprint, and making changes to the product backlog including analysing the data, breaking larger items into smaller ones, and getting them ready. This allows you to leverage the knowledge and creativity of the team; and it helps the development team members understand the user needs and make the right design and implementation decisions.
 When you manage a larger or more complex product, carrying out the necessary product work as a single product owner is often impossible. Consequently, you will have to share product leadership amongst a group of people, as I discuss in my article “Scaling the Product Owner Role“. Whatever scaling approach you choose, the basic division of labour stays the same: The product people lead the product, but not the team or process.