Sorry, not a job posting... I am all theory here.
In times when people are reducing staff and cost cutting, it would seem odd that I am about to highlight another required role. I want to highlight an article to support a problem that I am seeing in medium to large sized organizations. From Pragmatic Marketing: Software Product Architect Job Description
"As Product Architect, you will lead the design effort on a variety of projects in a highly collaborative, fast-paced environment. Your role is to design innovative solutions to real market problems. You will work closely with product and marketing managers, user interaction designers, and software engineers to develop new product offerings and improve existing ones. This position reports to the VP of Development."
Consider this situation... Two product managers who are based in different offices, organizationally on separate teams and each own one product. Both products are typically bundled and used at a customer site and except for the rare integration scenario neither product manager collaborates with the other. Imagine if you will, each Product Manager receives a separate enhancement request from a different customer asking for the same thing. Separately, they each run through basic sensing techniques to determine the pervasiveness of problem and articulate the problem statement for their product. Awesome! Now what?
They have documented a problem for their product that should potentially be solved in one and only one of products. The challenge at this point, how do they recognize that they are on the verge of writing requirements, getting estimates, passing it through various validation stages for the same problem, in essence duplicating effort? This becomes a bigger problem if the development team builds the solution twice.
In practice, we want one of the product managers to identify a problem, document it and the other product manager to identify a problem and recognize that the problem already exists. Technology can help, at least you will have a central repository for searching, but still required is discipline to collaborate, strong writing skills to ensure they are communicating in the same language and responsibility to do the right thing (make the right decision).
On the development side of the organization there is usually an architect type role that binds everything together, someone who is ultimately responsible that the technical designs are consistent and within the existing framework to ensure efficiency on the development side (no one is duplicating effort). I think the Product Management teams need this role too (or someone with this responsibility). I want to think of this as a Product Management Architect. This is someone who has overall responsibility for the quality of the problem statements, someone who is responsible for the best solution for those problem statements, someone who holds the big picture for the product portfolio and someone who has the potential customers in the front of their mind, not the technology.
The simplicity of my scenario doesn't really do the problem justice but if you start to think about a 15 member product management team that parses maybe thousands of inputs into hundreds of problem statements how pervasive this problem can be.
At the end of the day, as technology providers, operation efficiency is paramount to our success and maybe even a differentiator. Duplicating effort is the opposite of efficiency. The market sensing and problem identification is the bread winner of product management and the key to efficiency begins at the point of problem statement concept.
Last point, for the smaller groups I'd like to see you begin to have problem statement regular (weekly) review sessions on a regular basis. No harm can be done by reviewing the problems experienced by your customers.
Stewart... I like the idea of a Product Management Architect, it is a very clarifying way of explaining a pretty complicated topic.
I have typically thought of that role as the Product-Line manager. In that case, there is usually a management hierarchy where several product managers report up to the line manager. Is this role distinct from the line-manager role? Is the architect a peer to the other product managers? Their boss?
Any thoughts on this role as it relates to traditional product management organizations? Agile organizations?
Mike
Hi Mike,
I see the role as a peer to other Product Managers but would expect in some organizations that it could be management role. (This has a smell though.)
As for traditional vs. agile organizations, the primary job function (hopefully tying problems together) will be closer to the front-end of the process and likely not impacted by Agile or traditional except for the speed for which the data needs to be monitored.
What do you think?
Stewart
I think I am going to have to think about it. ;-)
Maybe I'll just have to write a post of my own to explore the topic a bit further.
To me this is clearly an organizational scaling issue.
I am having similar conversations with folks on technical architecture, testing architecture, UX architecture, and now product management architecture.
It seems that we want to empower teams to innovate, but provide enough guidance that we have a coherent product line (or testing strategy, or UI, or reusable components).
I think the trick, whether traditional or agile, is to figure out just how much planning and design, or requirements writing, to do up front so everyone can see the big picture.
Thanks for the response.
I wonder how much of this can be solved with flatter organization structures or having less people who have greater responsibilities. -Stewart
This strikes me as a job for a VP of PM, who needs to make sure that all the members of his team are working well together and doing so efficiently. At the higher level of what the overall architecture of the product/solution is, that's something that senior marketing needs to get involved in.
I think it boils down to having someone in charge of the portfolio and maintaining a portfolio view.
The question is who owns responsibility for keeping the product in-line with the product strategy. This person, let’s say it’s the Product Manager must have a mirror role at the product line or portfolio level.
You must have a product line/portfolio manager to ensure the product line/portfolio is following the product line strategy. Maintaining this strategic alignment from product portfolio to each product could be another aspect of this role.
@Bob - In some cases the VP of PM could do this, but in others it might be too high of a role. I am hesitant to apply a title to the position (despite my blog title), but it is a responsibility that needs to be in place to support all product managers across the product line. It is really the problem architecture that is important to ensure a single requirement voice to development.
@Derick - Your last sentence said "Maintaining this strategic alignment from product portfolio to each product could be another aspect of this role." This is the underlying concept from my original thought, only clearer. :-)
Stewart
Interesting. I like the title including"architect" since sometimes by looking at the functionality requests for the two products could be *stated* by user groups very differently but underlying it could be the same. So it's not just about straight matching up of different request lists.
This is related to what I saw at a client site in the last year, where we discovered that very similar applications were being developed by the IT team for individual divisions. This was since requests were coming in a piecemeal fashion and the Web site as a *whole* not being considered.
Like bob corrigan, I see this as a responsibility of the VP of PM. It amounts to a technology platform to be shared by the two product managers. Such as technology platform would provide a consistent interface much like Adobe's CS4 functionality, which lowers the barriers for cross selling, and reduces the training needs of customers. Technology platforms have their own roadmaps which interact with the product roadmaps managed by the PM team.
David, my only concern with making it the VP of PM is the time it takes to make sure this is sorted out. Might not be a full-time job but if they have 10 product managers under them, it could be part-time activity and I suspect the VP of PM is likely too busy already.
Having a technology platform road map helps, because I assume all features (or problems) then have to funnel through this platform. If they don't then how do I stop two product managers making the same feature in each of their products when it should be done in one. I need someone to filter all problem statements.
Again, this is not a problem for everyone but some it is and when it is, someone needs to act as that filter.