In part 1, I wrote about how community management contributed to tribe.net’s success and how traditional marketing played a key role in the company’s downfall, but those are small aspects of a larger story.
I put a call out to some former co-workers to get their input; the folks who responded were both early Engineering hires, and they each affirmed that my input into the product development process added value. If I get more feedback from other teammates, I’ll share it here. (And folks, if you don’t mind me sharing your names, let me know so I can edit this post.)
The reply I received from Engineer 1 suggested that I was was an effective proxy for our members, but that our overall progress toward creating a highy functional, user-friendly product was spoiled by “too many cooks.” As a result, he said that our service became less successful over time, even though we had direct and actionable feedback from end-users telling us exactly what they needed and wanted.
I agree with his assessment that what we were creating was “truly revolutionary.” We didn’t rely on the cold calculations of the social graph “to provide advertisers with a better view into what to try to sell me.” At times, our social network was “maddeningly hard to use, stupidly fragile and yet, it serves the needs admirably.” He also wrote;
“Who you report to is immaterial if leadership is dedicated to providing utility, usefulness or entertainment, or, as seems to be the vast majority case, not dedicated to such.”
In part 1, I suggested that Community Management might have been more effective if it’d been run out of Operations. My reasoning was facile; Ops generally gets the resources it needs, because when it doesn’t, things break down. This was a pretty simple reading of Operations teams, and I’ve got some second thoughts about that.
Engineer 2 praised me as “the ultimate user advocate … and therefore should have been a part of the Product organization with significant upstream input on features and priorities.”
In hindsight, I agree with him completely. The person writing/reviewing Product Requirement Documents has a permanent seat at the table, even if they attend more meetings than they care to. However, I never really felt that my CM input was embraced by the entire product team. I got along well with our PMs, but I’ll never forget the afternoon I turned to one in frustration and asked if we could prioritize the development of some admin tools that would reduce the amount of manual work I had to do.
I’ll never forget his response:
“It’s not my job to make your job easier.”
I was a little floored by such a baldly disinterested response. Instead of interpreting it as rudeness, I decided to assume that this was the way all product managers operated and that I must have crossed a line.
Several years later, a talented product manager (and several former co-workers) set me straight, and I’m deeply appreciative.
Another reason I’m certain tribe.net thrived early on is because everyone owned their role. I recently heard someone say that working in an immature startup is like little-league soccer; regardless of their respective positions, everyone swarms the ball if it rolls their way.
I’ve seen that problem writ large at many firms, but not at tribe.net. In terms of mutual respect and teamwork, I’ll be lucky if I ever find an culture/environment like that again.
Maybe I’ll have to create one.
More Gaudy Patter 