Troutgirl’s insightful post about the relationship between engineering and product management reminded me of a similar puzzlement I had a while back about websearch and XP (and by extension, PM).
This was at a time when Extreme Programming (XP) was all the rage, and so I thought seriously (if idly) about how it would work if applied to developing a websearch engine. And my conclusion was: not very well at all. The hardest concept to make fit was the On-Site Customer: XP insists that you should have very tight interaction with the end customer, to constantly prioritize features and make sure that you’re not going too far off track.
The problem with this idea in web search is that near the top of the priority list for many customers would be one very large feature request: make the results more relevant. This single “feature improvement” has some interesting characteristics: 1) it’s hard, 2) it’s a product of all the parts of the system at once, and 3) the customer can’t describe how it should be done.So I concluded that the web search engine is, as a development problem, “narrow but deep”. That is, if you think of it as a box diagram with features on the top edge, there aren’t many separable features, but there is a lot going on underneath to support that small number of features. A lot of the decisions about what happens to support that narrow interface will be architectural, and so will have to be made by engineers. (Whether web search _should_ have a narrow interface is an interesting and separate question — as it’s usually conceived, however, it does.) By contrast, UI-rich programs (say, web or DB apps with lots of separate pages or screens) are usually “shallow but wide” — lots of mostly-independent functionality exposed directly to the customer, and about which the customer could have lots of suggestions and opinions about prioritization.
So this leads me to a nicely falsifiable theory about XP: my guess is that whoever came up with the XP ideas in the first place was working in a “shallow but wide” software domain, because it’s only in domains like that that XP could look like a particularly good idea. (Anyone know the facts of the matter?)
Taking it back to Troutgirl’s post, I suspect that my “narrow but deep” has some overlap with her “high-innovation” (though actually an orthogonal distinction). I also suspect that depth distinction matters for PM-vs-eng as well as for XP, since in a sense part of the job of the product manager is to embody that onsite customer, or at least represent their desires. My predictions with regard to PMs and “narrow but deep” domains are that 1) [somewhat obviously] you need a smaller PM-to-eng ratio for such projects, and 2) the relationship will be more vexed in exactly the ways Troutgirl describes for high-innovation projects. The area where PMs in their traditional role really shine, I suspect, is in the corner of the space that is both shallow-but-wide and low-innovation (at least in an engineering sense). In that corner, the customer (or PM) can really know what he wants, the feature/product tradeoffs can be complicated and business-driven, a lot of the challenge is in communication and speccing, and engineers really are just executors.
Now, how much more smoothly would these professional collaborations work if (as Troutgirl suggests) the roles were understood to vary depending on the type of project?
Tim Converse 