PM Accountability: What if your building crumbles?

I first became aware of Zaha Hadid, an Iraqi-British architect, when I came across pictures of the Dongdaemun Design Plaza in Seoul, South Korea. Over the years, she's become famous for her "neofuturistic" designs of structures all around the world.

I've always found it unfortunate that the term "architect" is overloaded in IT as in many cases the role a traditional architect plays is quite similar to that of a product manager. The architect seeks to understand the client's requirements and design something that exceeds their expectations. Sometimes wild creativity is called for (as is often the case with Ms. Hadid); sometimes the client requires pure utility. When it comes to big buildings, bridges etc., it is structural engineers that ensure the architect's design can be implemented in the real world (somewhat akin to the role of software engineers in software product development).

Reading about problems with one of Ms. Hadid's creations yesterday (pieces are falling off a library she designed in Vienna) caused me to consider the nature of the accountability a good product manager carries with respect to their product. Our job is to understand our customers' needs and, with the help of other disciplines like UX, design a solution that will make them happy (if we thrill or delight them, so much the better). Obviously, even the best design will disappoint if it is implemented poorly. Unfortunately, I've been in situations in my career in which software I've conceived and designed has begun "falling apart" once it made it out into the wild.

I assume I'm not alone.

The nature of our dependency on good implementation raises many critical questions for product managers and underscores the broad, sometimes nebulous nature of our responsibilities. Although we can't be expected to understand and supervise every aspect of our "baby's" implementation, to be successful, we must hold ourselves out as the single neck to strangle when customers start reporting "cracks" in our creations.

Without getting carried away and overextending this metaphor, I can think of a few important takeaways for product managers from Ms. Hadid's misfortune:

• You will be judged internally and externally for things you don't directly control. Be aware of what's happening on the implementation side of things and be prepared to go beyond the call of duty to avoid shipping a poor implementation of your ideas
• Be careful about what you sign up for in terms of accountabilities: You simply cannot control every aspect of your product, from architectural decisions to the coding of a specific algorithms. Do what you can to ensure quality (and other aspects of product development) and demand that the appropriate folks are also held accountable for it.
• Think deeply about your next step when you have the feeling a shaky building has been erected and will soon have its inauguration. If it starts to crumble, it's probably not development that will be in the headlines.

The architect metaphor can be a powerful one for discussing the accountabilities of product managers as they relate to other software product development disciplines. What do you think? How do you ensure customers are happy with "the building" your team delivers?