« Vote for Silicon Valley P-Camp topics | Main | Agile mainstream flows into Collabnet »

02/24/2010

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

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.

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).

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.

The comments to this entry are closed.

About the Heretech

  • Tom Grant is a senior analyst at Forrester Research. You can e-mail him at tgrant@forrester.com, or reach him via Twitter at TomGrantForr. All opinions expressed here are my own, and not necessarily those of my employer, Forrester Research.

Heretech podcast

  • A weekly podcast about the technology industry, with a special emphasis on product management and product marketing. See the FEEDS section for the links to the podcast.

Twitter Updates

    follow me on Twitter