But I thought Martin’s most interesting comment was the following, which ties into the Tyner Blain article I blogged on Monday about tying requirements management and interaction design together:

The next most common situation is that product management is put in the engineering organization. While this has the benefit of putting the people that invent and design the product next to the people that build the product, this can also be problematic because engineering organizations are really designed to focus on building a product right, rather than building the right product.

There seems to be a battle brewing on the design front. Do PMs do design or is that a job for the engineering organization? According to Alan Cooper, there are three key functions – 1) interaction design (which he does), 2) an engineering organization focused on finding technical solutions to design problems presented by the first group, and 3) another engineering organization focused on creating production code based on the technical solutions found by the second group. Setting aside this interesting bifurcation in the engineering organization itself, you’ll notice that product management doesn’t show up in Alan’s taxonomy. But if we make the logical mapping of PMs <==> interaction designers, it does align with Martin’s implicit assertion highlighted above – that PMs are responsible for design, as well as requirements.

We can then tie it back to Michael’s Ten Tips for Writing Better MRDs, tip #2 of which is Use Screenshots, “Use screen shots or mockups to explain what you mean. Most of us have heard the saying “A picture is worth a thousand words”. When it comes to writing MRDs, a screen shot is worth a thousand words!” But aren’t mockups what we PMs often get in trouble about – that it’s overstepping our purview into design? I’d be curious to hear what people think about this

Technorati :