If you're playing 128th notes at 178bpm each note is 11 ms. If your BT headphones have a 30 ms latency everything you play will be off. The only BT headphones that work for music are AIAIAI headphones which require their own transmitter and receiver. They still have a 16ms latency and barely work.
Mostly covered elsewhere in this page, but in my opinion, gold PMs understand, on a deep level, the intersection between user needs, the marketplace, company strategy, and the engineering resources available; don't take shit from any of them, and can balance each of them.
1. User needs: this means not just talking to users, but seeing how users use your product and competing products. You understand what users are actually trying to do. Not taking shit from users means, just because a user tells you they wish something existed, therefore it gets written down as a feature request. Maybe something else would be better, maybe the user is a sourpuss who is giving you crap because they're having a bad day. Gold PMs read the room. Allowing every user direct write access to the feature request lists is design-by-committee and guaranteed to result in crap. Gold PMs know how to filter out everything but the most essential.
2. Marketplace: Gold PMs understand what other products are in the market. They understand that the market chooses between different products in the market, and therefore, what's important is how to differentiate the product within the market. Good PMs understand the difference between a feature that other products have that needs to be built in their product (i.e. table-stakes/non-negotiable, like SSO in Enterprise products), and not taking shit by adding features just because other products have them already (the building of which won't help differentiate their product in the market).
3. Company strategy: Gold PMs listen to executives who say which market segments the company is trying to reach so that they can reach out to the relevant users and choose relevant features, and not run after irrelevant segments that don't fit into the strategy. Not taking shit means knowing when to push back when executives pick a market segment that isn't going to be interested in the product (happens more often than you'd think), and making sure that the team has the budget and resources to go after (i.e. talk to users in) that market segment.
4. Engineering resources: Gold PMs understand, roughly, the skills of the engineers and developers who are available to them to build the features. They know what feature requests are feasible, approximately how much time it takes to build them, and when they need to back off and let engineers pay down technical debt. Not taking shit from engineering includes concerns like: not allowing Engineering to build feature work that they feel is really important but hasn't been through the Product process (market research, UX, etc.), pushing back when Engineering says something will take much longer than you think (i.e. is it a misunderstanding over scope?), pushing back when Engineering releases half-assed work (i.e. almost like QA in terms of exploring edge cases in the Product, and making sure those are addressed).
Gold PMs are valuable to Engineering when they distill user needs + marketplace + company strategy into a very simple list of the top 3 things that need to built in the next two weeks, and can clearly explain (including showing their work) why those 3 things are at the top. They are anchors when those top 3 things are clearly bullshit, when they don't even bring you a list of prioritized features to build, when their presence is required to get anything (even non-feature work) done, when they push paper for the sake of pushing paper, when they get in-between you and necessary externally-sourced information (design files, customer feedback, bug reports, etc.).
How is it possible to be efficient in these points without a strong engineering background, especially if you are innovating? Discussions in points 1, 2 and 3 will only be note taking if you cannot concretely envision what the implementation could be and need to ask engineering everything that is not a generic or superficial feature. The non-technical PM I have worked with always turned up to be project managers drowning the engineering and design teams in meetings and processes.
Why do points 1 and 2 require strong engineering background? Knowing a feature is important or what features users actually want is not related to how hard it is to implement or how long it will take. If you have a good relationship with your engineers, you should be able to talk to them and trust their input.
Point 4 is the one that really sounds like needing engineering background.
I have had two, because one fell out of my bike bag. It's pretty good for something you can easily carry on a bike, but it's not the lap of luxury. Unless you slouch down a lot you're going to wobble left and right.
I wish. Reddit jumped the shark years ago but I did look into it at one point. There's a lot of factors you wouldn't anticipate that will trip you up. Not the least of which is quality moderation. Your site will either die under the crush of awful free speech, or live long enough to run out of visitors. It's a tough balance Reddit didn't have to face as harshly in a different time.
reply