Question: How do you manage product ownership with the technology organization?
I manage products with an online job portal and my question is related to product ownership.
While I sit in the product management organization, we have a separate technology organization that is responsible for delivering according to the directions set by product managers. The people in the technology team are mostly creative and young and we certainly want them to contribute to the product development and put in their own initiative to improve the product.
But how do we define the ownership between product team and technology team then? What are the best practices in organizations where product managers and development managers report to different heads?
The fact the Product Management and the technology team report into different different heads is not a problem, in fact it is more the norm in the software industry. Product Management is fundamentally responsible for defining what should be built by when (i.e. priorities), and Development (in your case the Technology team) is responsible for defining how those priorities can be met within the given time frames and resources. You need to have that well defined and understood, otherwise discord will ensue.
To get the most out of the creative talents of that team, involve them in the requirements definition phase. See what ideas they have that align with the business objectives that need to be met and decide from that input, what makes sense to prioritize.
I’m assuming that the creative talents you mention revolve around user interface and design of the portal? Or does it extend to the middle tier(s) and back-end of the portal as well?
At one company I worked at, we had a general goal of improving the server performance of our product by at least 25% every major release. This usually involved architectural or internal changes. How this was achieved was not defined by Product Management, but we tasked the architects to propose suggestions for performance improvements, and we’d discuss and decide with the architects what made the most sense for a given release.
This had a number of benefits beyond the performance improvements. It involved the Dev team in the requirements process and ensure that there were beneficial but technically challenging projects for the Dev team to focus on during the release cycle.
I’m not saying that you need to task your teams with architectural improvements, but simply that you have to define some high level goals that your technology team can chew on a bit and propose solutions to.
One approach is to strike a good relationship with the head of the Technology team and work with him/her to identify a few key people on that team that can work with you closely to generate ideas for improvement. Make sure that the improvement aligns with business goals and ensure there is clear benefit to the work.
In the end, success will depend on how much buy in the technology team has in the process you implement. If they feel they are part of the process and that you listen to their input and incorporate it where possible into your plans, you should be able to benefit from their creative talents.