What a Product Manager Is and Isn't, and Why You Should Probably Stop Trying to Hire One.

I’ve had a lot of people contact me over the past two years trying to recruit me for a Product Manger role or looking for referrals to qualified candidates. I have a solid network and am well respected in NY Technology, Advertising and Publishing circles — so I’m used to constant pings by Executives I’ve consulted with or recruiters I’ve worked with and am happy to help when I can.

I feel compelled to write a post because out of several dozen inquiries for positions titled with some variation of “Product Manger”, only one was actually involved with any sort of product management. The rest? Sigh…

There’s been a huge conflation of terms with regard to “product management” in the past few years and it seems to be over-represented in NYC area. This conflation really needs to stop. Now.

The role of a Product Manager has a bit of variation in it’s definition, but it’s usually something around the lines of “the person who is ultimately responsible for a product”. In a large organization, Product Managers are essentially divisional GMs or ‘micro-ceos’; in smaller ( and tech ) organizations, they tend to be inter-disciplinary people who might report to a “head of product” or directly to the CEO.

Generally speaking: Product Managers are highly skilled and highly experienced professionals, often with extensive background across one or more areas, who are tasked with developing or fine-tuning what a ‘product’ should be to best achieve business goals.

Most “Product Managers” I’ve known can be categorized like this:

* Most have 10+ years of professional experience, with pretty impressive track records; rarely do they have less than 5years experience;
* They either have advanced degrees like an MBA, MS, PHD or work-based equivalent, i.e. a C/VP/D level employee who have done some stellar work;
* All are experts / authorities in at least one discipline — and can somewhat function in whatever roles they oversee/interact with, as they’ve quite a bit of experience working across them. They understand when the Engineers are slacking off or overworking, when the Marketers have a ridiculous request, and when the project managers are over/under promising.

Sometimes people have a strong technical background – but that’s not a requirement, it’s a bonus over their experience leading teams and deeply understanding the marketplace they’re working in.

To give some quick examples:

1. I was recently at eConsultancy’s Digital Cream NYC event, in a room full of 150 people who were mostly Chief Marketing Officers / VPs of Marketing. If I were a technology company in the advertising space or a publisher looking to sell innovative new ad solutions, I would want to recruit a Product Manager from the attendee list. This is rather simple – the person who could best manage my advertising product, would be an expert in advertising. Few (if any) people there had any coding experience whatsoever.

2. Several publications that I know of built out Editorial Product departments staffed with former Senior Editors and Operational Editors. What better way to deliver on editorial needs than by hiring a seasoned journalist ?

3. A friend literally wrote the book on a certain technology, and is often called in to advise on different implementations of it — addressing the costs to scale/iterate, user behaviors, implementations, etc. He tends to advise people in a very “product management” capacity.

4. When Facebook buys a startup, their executive staff tend to be acquired as Product Managers to own a section of the Facebook experience.

Some of the things a Product Manager typically does is:

* Understand and manage the business goals: identify the best business opportunities , create and push products to address them.
* Understand the functionality and scope of the product: if it’s technology, they can code; if it’s a marketing product, they understand how and why advertising is bought.
* Understand the customers: make sure people will want to consume the product
* Make decisions and be qualified to make them: balance a mix of Strategic Decisions ( into markets or users ) and Operations ( costs to iterate – both financially and team morale )
* Manage the process : work with P&L sheets, quarterback the scope/design/build/deploy/sales process.
* other things I’m too tired to note. Product Managers are tasked with balancing the goals of the Organization against the needs of multiple types of Consumers and the people/resources to build them. It’s a lot of work, but it’s amazing fun for a lot of us.

The scores of “Product Manager” positions that are plentiful in NYC right now are nothing like my descriptions above – they tend to be a hybrid of skills belonging to a Digital Producer ( in the adverting world ) and Project Manager ( in , well any industry ). They are mostly what I consider entry level – with a max of 3 total years work experience , but often in the 1-2 range.

These positions tend to be highly administrative , require no expertise or inter-disciplinary skills, and don’t even have access to seeing budgets — much less managing them or trying to affect revenue operations. Sometimes they’ll include a bit of customer development work, but most often they don’t. These positions completely lack a “Strategy” component, tending to either be a very entry level position or a mislabling for the most incredibly experienced and talented Project Manager you’ve ever met.

Almost always these roles become filled by someone who honestly shouldn’t have that job. One of my more favorite “Product Manager” interactions was with someone who had just assumed the new role as their second-ever job, with their first job being several years as a Customer Service representative. If the company provided Customer Service, it would have been a really good fit — but the company provided a very technical service, and their “Product Manager” was really functioning more like a mix of an “Account Manager” and “Digital Producer”, they were visibly out of their element and unable to understand the needs of their clients or the capabilities of their team.

This is really a dis-service to everyone involved.

* It makes a potential employers look foolish to actual Product Managers , and labeled as a company to avoid.
* It skips over a huge pool of extremely talented Digital Producers and Project Managers who would excel at these roles.
* It creates a generation of early-career professionals with the title of a Product Manager, but without the relevant experience or skills to back it up.

Because “Product Manager” is so often a role that an experienced professional transitions into, it’s not uncommon to see someone with 1-2 years of “Product Manager” in their title, but a resume that shows 3 years as a Vice President and 5 years as a Director at a previous employer. You might even see someone with 3 years of “Product Manager” as a title — but an additional 9 years of “Digital Producer” or “Project Manager” experience behind them as well. Plenty of professionals from the Production side transition into Product Management too, once they’re well versed in their respective industries.

Mindless recruiters ( and certain nameless conglomerates ) of NYC don’t understand this though. They just focus on buzz-words: if someone has been in “product” for 2 years, they target them as if they’ve only been a professional for that long. It’s all too common for the salary cap of a not-really-a-product-manager position to be 1/4 the targeted recruit’s current salary. The compensation package and role should be commensurate with the full scope of someone’s work — i.e. 12 years, not 3 years.

So my point is simple – if you’re hiring a “Product Manger” you should really think at what you expect out of the role.

* If you’re really looking for a “Project Manager” or “Digital Producer” — which you most likely are — change your posting and recruit that person. You’ll find a great employee and give them a job they really want and care about. If you manage to get a Product Manager in that role, they’re going to be miserable and walk out the door.

* If you realize that you’re looking for a role that its both strategic and operational — and is going to be one of the most important hires for your organization or division, then either hire someone with relevant Product Management experience OR hire a relevant expert to be your “Product Manager”.

Dreamhost UX Creates Security Flaw

Last week I found a Security flaw on Dreamhost caused by the User Experience on their control panel. I couldn’t find a security email, so I posted a message on Twitter. Their Customer Support team reached out and assured me that an email response would be addressed. Six days later I’ve heard nothing from them, so I feel forced to do a public disclosure.

I was hoping that they would do the responsible thing, and immediately fix this issue.

## The issue:

If you create a Subversion repository, there is a checkbox option to add on a “Trac” interface – which is a really great feature, as it can be a pain to set up on their servers yourself (something I’ve usually done in the past).

The exact details of how the “one-click” Trac install works aren’t noted though, and the integration doesnt “work as you would probably expect” from the User Experience path.

If you had previous experience with Trac, and you were to create a “Private” SVN repository on Dreamhost – one that limits access to a set of username/passwords – you would probably assume that access to the Trac instance is handled by the same credentials as the SVN instance, as Trac is tightly integrated into Subversion.

If you had no experience with Trac, you would probably be oblivious to the fact that Trac has it’s own permissions system, and assume your repository is secured from the option above.

The “one click” Trac install from Dreamhost is entirely unsecured – the immediate result of checking the box to enable Trac on a “private” repository, is that you inherently are publicly publishing that repo from within the Trac browser.

For example, if you were to install a private subversion and one-click Trac install onto a domain like this:

my.domain.com/svn
my.domain.com/trac

The /svn source would be private however it would be publicly available under /trac/browser due to the default one-click install settings.

Here’s a marked-up screenshot of the page that shows the conflicting options ( also on http://screencast.com/t/A2VQT5gOVkK )

I totally understand how the team at Dreamhost that implemented the Trac installer would think their approach was a good idea, because in a way it is. A lot of people who are familiar with Trac want to fine-tune the privileges using Trac’s own very-robust permissions system, deciding who can see the source / file tickets / etc. The problem is that there is absolutely no mention of an alternate permissions system contained within Trac – or that someone may need to fine-tune the Trac permissions. People unfamiliar with Trac have NO IDEA that their code is being made public, and those familiar with Trac would not necessarily realize that a fully unsecured setup is being created. I’ve been using Trac for over 8 years , and the thought of the default integrations being setup like this is downright silly – it’s the last thing I would expect a host to do.

I think it would be totally fine if there is just a “Warning!” sign next to the “enable Trac” — with a link to Trac’s wiki for customization , or instructions ( maybe even a checkbox option ) on how a user can have Trac use the same authorization file as subversion.

But, and this is a huge BUT, people need to be warned that clicking the ‘enable Trac’ button will publish code until Trac is configured. People who are running Trac via an auto-install need to be alerted of this immediately.

This can be a huge security issue depending on what people store in Subversion. Code put in Subversion repositories tends to contain Third Party Account Credentials ( Amazon AWS Secrets/Keys, Facebook Connect Secrets, Paypal/CreditCard Providers, etc ), SSH Keys for automated code deployment, full database connection information, administrator/account default passwords — not to mention the exact algorithms used for user account passwords.

## The fix

If you have a one-click install of Trac tied to Subversion on Dreamhost and you did not manually set up permissions, you need to do the following IMMEDIATELY:

### Secure your Trac installation

If you want to use Trac’s own privileges, you should create this .htaccess file in the meantime to disable all access to the /trac directory

deny from all

Alternately, you can map access your Trac install to the Subversion password file with a .htaccess like this:

AuthType Basic
AuthUserFile /home/##SHELL_ACCOUNT_USER##/svn/##PROJECT_NAME##.passwd
AuthName “##PROJECT_NAME##”
require valid-user

### Audit your affected code and services.

* All Third Party Credentials should be immediately trashed and regenerated.
* All SSH Keys should be regenerated
* All Database Accounts should be reset.
* If you don’t have a secure password system in place , you need up upgrade

## What are the odds of me being affected ?

Someone would need to figure out where your trac/svn repos are to exploit this. Unless you’ve got some great obscurity going on, it’s pretty easy to guess. Many people still like to deploy using files served out of Subversion (it was popular with developers 5 years ago before build/deploy tools became the standard) , if that’s the case and Apache/Nginx aren’t configured to reject .svn directories — your repo information is public.

When it comes to security, play it safe. If your repo was accidentally public for a minute, you should wipe all your credentials.