Hacker News new | comments | show | ask | jobs | submit login
Kevin Rose: What I Learned Building a Product Team (medium.com)
21 points by mikelbring 1607 days ago | hide | past | web | 6 comments | favorite



This is an impressively content-free article.


It's a great headline, but the article is absent. I feel confident in asserting that (excluding misclicks) the users who upvoted this article did so without RTFA.

It makes me wish we could run a quick experiment where "trap" articles would be thrown on the front page with real-seeming headlines, usernames, and apparent votes, but no content at all, as a way to detect users who upvote without RTFA and discount their future votes.


After working as a pm, I feel I know a bit of what he's getting at. The appealing solution to scope creep/misalignment/doubt mid-development is to compromise and make everyone happy; Stakeholders, developers, your boss. This keeps people happy in-process but will probably leave you with a mediocre end product.

The thing that was painful was betting on and fighting for your own vision of how something should play out. This requires selling like a mad man, fighting tooth and nail for your idea, which is scary as shit and very draining. Hopefully, it will lead to a better end product though. Either that or having wasted months of dev time and possibly missed the market window, and it's all on you.


I think the larger problem that is touched on a little here is getting your team to buy into your vision. When the team becomes disinterested or uninspired in the long-term product, all the little problems start becoming big problems. Words like "can't", "useless", "pointless", "too hard", etc start becoming more common place. It tends to also be the point where people start clocking in and out for their paycheck instead of their passion.


My motto is "people pay you to solve the hard problems". Our nature during product development is to simplify, cut away and focus. Unfortunately you could start out pointing at the hard problems, but end up solving the easy ones because it makes more sense. Of course no one then cares for the result.


Not much?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: