This will be a short post. Volumes have been written on the product development (delivery) process. Do something agile (not SAFe). I will however focus on the product management perspective on this.
I use the acronym “PR” (as in pull request, the thing engineers do to integrate code) to refer to the two core aspects of delivery: producing results.
Produce
Delivery is about making it happen. Building software is mostly software engineering work at this stage. Nevertheless, the product manager does have their duties here too. Be it wearing the “PO” hat in a Scrum setting or some similar role, product management contributes with guidance and micro-prioritisation (in contrast to macro-prioritisation when picking which opportunity to work on).
Beside the prioritisation of backlog items and shepherding of tasks into planning increments via agile rituals, the PM needs to support the team to get those tasks shipped. The PM has an interest that items of value get in front of users asap. What exactly needs to be done will vary based on company, existing roles (like scrum masters, delivery managers, project managers etc.) and PMs skills, but it needs to be done.
Delivery is also about communication. Tell the world about your new fancy feature. Stakeholders, users and your mum all want to know. Make a plan how to best do this and execute on it.
Results
Possibly the most overlooked part of the whole product process is what follows after we actually deliver something to production. Many teams just move on and never look back.
That’s a mistake.
Why put all the effort in in the first place? How is the new feature contributing to the success? Yes, it was validated in Discovery. Does that mean it is a guaranteed success? No.
Follow up on the desired outcome! Are we seeing the expected impact? Measure adoption, engagement, retention, satisfaction with the feature to understand if it’s being used as intended. Maybe people try once and never again. Maybe people use it, but are unhappy. Check on the patient doctor.
Once you understand how the feature is performing, take a decision (and document it). You will need to either improve, fix, leave as is or even kill the feature based on what you learn. Once decided, make sure to communicate accordingly.
tl;dr
Product management mostly plays a supporting role in product delivery. With one exception: following up on the results. Delivering a feature is not done with the release. A product or feature is only fully delivered when it creates the desired outcome and we have decided to keep it (and not kill it). Read that again: We are delivering on outcomes, not outputs.