Who Owns the Website, and Why

While the the evolution of roles described in the OP are steps in the right direction, usually the inefficiencies caused by the problem require some deep organizational changes beyond hiring some "growth hackers" or "product managers."

I encountered this a lot at previous employers where I developed SEM management systems (ie. optimizing keywords on Google Adwords). SEM had its own P&L (profit/loss) goal so we ran into issues like:

- Bidding on our own "brand" terms. Like if we're oursite.com, we would bid on "our site." Naturally we'd get ranked #1 on AdWords. Yet our site was also #1 on Google's organic results. I'm sure we were absolutely cannibalizing our (free) SEO traffic and hurting for the business units that had SEO P&L responsibility.

- Pretty much any change to the site threw our numbers out of whack. There was one major release that improved the UI greatly, but did add some additional load time to pages. Our Adwords rankings got killed, the SEM team freaked out because it was now mostly impossible to hit our P&L, and it turned into a disastrous political situation.

- We had no input to the actual site ourselves. When our site had no relevant content for whatever was being searched for, the resulting page was pretty much like yelling "OMG WHY THE HELL WOULD YOU EVEN SEARCH FOR THAT YOU SHOULD JUST LEAVE RIGHT NOW BECAUSE WE PROBABLY DON'T HAVE ANYTHING YOU'LL EVER LOOK FOR IN YOUR LIFETIME" at the user. So if a user came in on a keyword that would lead to one of these pages, there was very little chance they'd hang and poke around for something else, which made bidding on the "wrong" keywords incredibly costly. We REALLY wanted to change that page to something more consumer-friendly, but we never really had any channels to do that.

- Ironically, at the team level, the director of SEM resisted hiring any product managers. He wanted tech and operations to feel like one team and communicate constantly. We all talked with the analysts directly. Our wins were theirs, our needs were theirs, our pain points were theirs and vice versa.

Most organizations I've been at, the "product manager" is really just "have a meeting with everyone that's not an engineer, find out what they want, tell the engineers what to do." You know, kind of like this guy: http://www.youtube.com/watch?v=mGS2tKQhdhY

I recognize that this is not an easy problem to solve. My understanding is the idea of the growth hacker is someone that can "see the big picture" and then implement the solutions that lead to the best possible overall outcome. Beyond the right individuals though, it's important to have the right organizational structure to even allow that process to manifest. A very obvious example of a company that understands this is Apple, who has exactly one person in the entire company with a P&L goal[0].

[0] http://blogs.hbr.org/cs/2011/10/steve_jobs_solved_the_innova...

That is demoralizing (and even offensive) to front-end developers. The "beautiful Photoshop mocks" of a designer that can code will be nothing like those from a designer that can't, and that's a much more important factor for it making it to production "intact" than the abilities or intentions of the developer.

I'm certainly biased, but I can only laugh when a designer complains that text doesn't look the same everywhere and wants to use a static image instead. Having the 'freedom' to do that from the start is not any better.

I would be interested in reading more about different 'types' of Distribution Hackers. You mention they are often a 'mix of coder and marketer,' but I would be interested to see what other skill-sets might produce distribution hackers.