PM's latest annoying responsibility

The more social we get, the more we expose about ourselves. That's a fact of life that antedates social media, the Internet, or computers. From this perspective, social media are just a new way to  reveal ourselves, sometimes by choice, other times not. 

For the PM in charge of product requirements or release checklists, working on a social media product requires standing your ground on security and privacy issues. I won't beat on the unfortunate launch of Google Buzz further, except to make one last point. To avoid the sort of morass in which Google finds itself, someone in PM needs to have both the authority to insist on whatever external testing, use case analysis, red team testing—some way, any way, to avoid a class action lawsuit.

Unfortunately, very few PMs are experts in security and privacy. Historically, compliance and risk management don't overshadow the tech industry the way they figure prominently in pharmaceuticals and other tightly-regulated verticals. The section 508 requirements of the Americans With Disabilities Act, an important box to check before releasing a new product, is the closest many PMs get to anything resembling regulation.

That situation may change. Security specialists in tech companies deal with technical issues like, "How vulnerable are we to cross-site attacks?" Normally, they are not the people who think through the capabilities of the product to see if there is some way that product might compromise security or privacy. Even if they volunteered for the job, it's not feasible to bring them into the product development cycle early enough to make a difference. Nor will they be able to stay engaged to monitor how the features inevitably change over the course of development.

Therefore, it's unavoidable that security, risk management, privacy, and related issues naturally fall into the laps of PMs. Social media products raise questions about who can pry into your personal information, or how these details might become public without your permission or knowledge. Other products create different risks. For example, the Strange Case Of The Voyeuristic Laptops at a Philadelphia-area high school raises the question, is the company that produced the software used to spy on students at all liable for the abuse of the technology? Does circumventing an operating system's security features create other points of legal exposure?

I've yet to meet a PM who loves dealing with these kinds of issues. Who wants to be the person who, in a release meeting, presents the 15 potential security problems that need to be addressed before the product ships? Particularly if, just before you, someone gave a brilliant demo of how incredibly cool the product will be, if only it could get into the hands of customers. And, of course, success is defined as the absence of problems, not positive gains that everyone can celebrate. ("Woohoo! Three product releases without a lawsuit!") Sadly, I don't see a way of avoiding this responsibility.

Comments

[Saeed Khan]

Tom,

This is a good example of where having differentiated roles in the Product Management organization would make sense.

If security and privacy are important to a company's strategy -- or if Product Management identifies them and advocates focus on them -- then having someone (or several someones if the company is big enough) in the PM org who can align security/privacy priorities of the market, company and product would make sense.

And that's a proactive task of course, not something raised at a release meeting.

PMs in B2B companies have to deal with SOX issues regularly -- security is a big part of that -- so it's not something that is alien to many of us. And of course B2C products/services have their own privacy and security issues.

For Product Management to grow and deliver additional value to a company, we need to stop thinking of Product Managers as individuals with horizontal product responsibilities.

They should be viewed -- like every other department views their own staff -- as members of a team/dept that has both hierarchies of responsibility and differentiation of roles.

[Vanessa]

There needs to be a clear distinction made on wants vesurs need as you pointed out with architectural changes. A strong change management process is a requirement for PMs to impliment. Unforunately, end-users start to hate hearing change request and extra costs, something that invariably happens, the more complex the project.Are large projects more likely to fail? Yes. Statistically researched, large projects failed often (as did projects in general). One way to circumvent a project failure is to break it down into parts. Project discovery and high level requirements gathering are a good starting point. Development and implementation can come later (in the 2nd phase).

[Visual]

If you're working on the UI and rropets before you've finalized the underlying database and system architecture then it's no wonder that you'll have to revisit the UI and rropets many times over later. Don't put the cart before the horse. Yes, business requirements can change midstream during a project but that's what proper change management processes (also part of the PMBOK) are for.