Repost: Searching: Product Management Architect

This is a repost of a post that I did on the Product Management View. There were some interesting comments on the original.

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.



If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

  • Share/Bookmark

Related Posts:

  • Shared Links 09-Feb-2010
  • Budget and your Strategy
  • Agile 2010 Submission Request
    blog comments powered by Disqus