6 Tips to improve the collaboration between the Product & Program Managers
As a Program Manager, who is working day-to-day with crazy Product guys, I’d like to give some tips for these who hold these positions. This post is a result of my deep introspection, after I’ve managed to clean up a lot of mess, which pop-up during the delivery.
Quick Intro
In order to develop great software products, there must be solid collaboration between the Product/Design, and Development teams. Product Manager is a person accountable for gathering and validating hypothesis, elaborating innovative product ideas or improvement of existing products. On the other hand, we have a Program Manager, who is accountable for end-to-end software delivery. Starting from planning the projects, through monitoring and controlling the development, to deployment of the software and measuring of key success metrics after that.
Both, Product and Program management activities last for very long time. Product-related activities starts before the Program. It’s when the initial ideas are generated or brainstormed, then evaluated, and the best are chosen to be validated via MVP first. Then both are collaborating closely to deliver solutions, which should solve the customer problems, with the focus on the most important parts of the product first. Product features are delivered by projects (or initiatives) within the Programs. Activities in both subject areas usually finishes during the Product decline stage, after the product was removed from the market.
Tip (1–2): Vision & Architecture
Product Manager — should has a clear vision what she want to achieve with the product or particular product idea. Having clear view on the desired state will help to plan the roadmap, and allow delivery team to think about potential architectural blockers.
Program Manager — push Product Manager to clearly articulate the desire product vision. Having a clear vision will help your Solution Architects design the product architecture, because they will knot what the PM want to achieve, and what are the intermediary stages. Think about architecture in advance so that you will not come to the wall, when you cannot proceed with development.
During my journey I had this “opportunity” that the development was started before the Architecture Design was prepared and approved*. Don’t follow me on that.
Tip (3–4): Divide & Conquer
Product Manager —have an idea about how you want to modularize the product, how do you want to split it into the modules. Think twice about how do you want to sell it, and bring revenue to your company. This work should be done as soon as possible, otherwise you will impact the delivery.
Program Manager — think about what skills or people do you need to build particular software modules. Work closely with your Architects and development teams to plan this work for success! Don’t forget about the dependencies. If the Product has a lot of Back End work to be done, try to do some storming** session to split the software into smaller chunks and improve your planning.
Tip (5–6): Prioritize & Plan
Product Manager — first things first, focus on the most important projects and features …, and please do not even try to see the projects in a binary way. Remember that you can prioritize between the projects, as well as, within the projects. Usually you do not need to have everything done within the project to release the features.
Program Manager — support Product Manager with building the roadmap. Try to implement the agile way of thinking. Persuade Product Manager to work with fixed dates, but flexible scope. Undertaking this approach will really make your live much easier, and help you during the planning sessions.
From my PgM experience, I know that Product people are visionaries. If you would ask them what they want, the answer will be everything. But, unless you work for Google probably you have limited resource capabilities. Remember about that during the Roadmapping***.
Farwell
I am curious what are your thoughts on this topic. If you have some, don’t hesitate to start the conversation in the comment section below.
Appendix
- *= We were overloaded and under-resourced; those were very difficult times
- **=I am a big fan of Event Storming sessions, during which you can take the big picture, refine it, and finally split into architecture components
- ***=I love using quarterly release roadmaps, in which each quarter is divided into two sections — commitment or optional (50% capability each). Commitment is what we said we will deliver AND Product Manager cannot change — this part of quarter is fixed. The optional part is what we will try to deliver, however, unless we started working on that part, Product Manager can still make some changes
Useful links:
— Exploit the product life cycle, by Harvard Business Review,
— User Story Mapping, video done by founder Alberto Brandolini
