

Who Owns the Website, and Why - dmor
http://distributionhacks.com/who-owns-the-website-and-why

======
nhashem
I'm going to summarize the overall problem here as, "everyone has different
goals for the same product," and the OP has some suggestions on how to unify
them.

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...](http://blogs.hbr.org/cs/2011/10/steve_jobs_solved_the_innovato.html)

~~~
dmor
Oh you are so right, I didn't mean for this to read like solving a growth
hacker or product manager would solve the problem -- I intended to say that
these people could be part of the solution, and that often product managers
have historically been the titles who do this kind of work so if you are
pattern matching it might help. Thanks for the feedback, and the specific
examples -- I will work to use more of those in the future

------
ricardobeat
> This allows designers to take back the reins, no longer accepting “I just
> can’t do that in HTML” or an endless litany of unqualified feedback as
> excuse for poor implementation of beautiful Photoshop mocks.

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.

------
SparksZilla
Loved the post and the blog overall!

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.

