Delivery manager’s contribution to product development

The best way that I have personally experienced for a Delivery Manager to participate in a Scrum setting is to have them be a stakeholder.  They can provide great insight into the way customers use products, how to make the product easier to implement, how to ease customer onboarding, etc.  That information can lead to some very good Product Backlog items. All of these contributions would be done in coordination with the Product Owner as part of effective Product Backlog management. 

It is also the case that often the Delivery Manager is the first stakeholder to encounter the product updates.  You can help with doing some user acceptance testing as you have knowledge of the user.  You can be a regular participant in the Sprint Review.  

As a Delivery Manager, you have information that can improve the product for other stakeholders, whether they be external or internal.  

The role of a delivery manager can take various forms and content depending from an organization, business domain it serves, complexity of the product and other factors. 
I would kindly ask to share your experience on how the DM can contribute to the design and development of the product if his/her role is mainly assuming work with clients(UAT assistance, training, issue resolution, etc.). 

In my experience, the various forms you allude to are likely to rob a team of the ability to manage delivery for themselves, and to thereby account for value and quality.

Anyone can however evidence servant leadership. A useful contribution to design and development might therefore be to establish transparency over organizational constraints, including certain roles, and challenge them.

Delivery Managers take care of the professional growth of the teams(again depends on the organisation structure),  help the team by managing team dependencies within organisation and anything else that is hindrance to delivery of the product. 

Apart from those, If the team follows Scrum, DMs can be a mentor to help team with design and development ideas.But by making sure they don't impede the team that manages 'Delivery' of the product.

I'd like to offer a slightly different approach here based on some pitfalls I've seen. 



There's a good reason Scrum only talks about 3 roles, and that's because ultimately these are all that is needed to deliver value, which of course should be our focus. 



I'd be super weary of getting into the game of 'how does role X fit into scrum'. There are endless roles and hierarchies inside many organizations with lots of people that will ask that question, and I don't think it's helpful to think about how things can or should move around those structures. 



As a scrum master and coach, I would instead try to flip it around. Ask those individuals, regardless of their role, what their skills an experience can offer the team to help deliver valuable increments of their product. Two people in the same 'role' might have vastly different things they can add. 



Then it becomes more about helping those people to understand where and how they can interact with the team most usefully, where there is risk of 'breaking' the process, and how they can demonstrate servant leadership.



By switching the conversation away from the role, which fundamentally will become "your role is not important, sorry", you can bypass the inevitable stress and defensiveness this can bring and instead focus on the value the person brings to the organization and how best to leverage it for success.

Thank you so much for all great insights you provided!