1 - Those that can identify what needs to be done at a level deeper than the end users, can communicate very well, and can code reasonably well. (Coding well enough to understand complexity, and can do things on the fly if needed)
2 - Those who appreciate the difficulties that users have, and have an enormous technical toolset to bring to bear on tough problems.
Much performance literature says, "Play to your strengths" but when people in batch 1 already know their end users in and out, it helps to develop technical skills. And people in bucket 2 - when they make the leap to deeply understand their customer's business, they're extremely powerful. This is also why many firms like to hire CS majors for non-CS jobs.
2 - Couldn't agree more, but ALAS, there aren't enough people graduating with CS degrees, let alone STEM in general. When I tried to do a market analysis, it was a painful experience. My CoFounder (Great Engineer) was able to do in two hours, what would have taken me two days, because of his software and database skills, not to mention that he had more time to interpret the data vs just gathering. I'd be curious to continue the discussion. If you'd like, please send me an email to firstname.lastname@example.org
When I've been in "QA-ish" roles and worked with developers like this, I loved them - and told them so - which was the last thing they expected from an extrovert. I was OK with the ones who DIDN'T have the product/business/user knowledge, but were willing to listen to what I had to say - even if I was saying you/we/I need to go back to the product side for clarification; I don't think this is what they really need/want. And I've battled with those developers who neither had nor wanted any business/user/product knowledge AND didn't want to talk to the product side or listen to QA AND still wouldn't listen to QA after QA got clarification from the product side.
Of course, ideally any clarification is received before or - at the latest - during coding, but life ain't ideal.
You haven't been around much, have you?
Would you care to share your experience with us?
- "Only "power users" will use that." Sometimes this one's true, but some people will say this about any idea engineers come up with.
- "Let's see what someone in product thinks." The key thing you have to pay attention to here is the subtext. If it's "Let's keep product people in the loop", that's good. If it's "Your idea is invalid because you don't have the title 'Product Manager'", then you have a problem.
- "I understand you don't want to complicate the code, but our customers don't care about that." This one's a minefield. It puts you in a place where you have to either make a poor technical decision, or get accused of not caring about the customer.
But by far the most common tactic is merely excluding engineers from important meetings, and only bringing them in when they need someone to write the code.
I personally think it is ASININE not to involve my engineers in the decision process, bc they might be able to optimize my business process, or even my thoughts as a product owner. I am a sales and marketing guy, that desperately wants to become a good product manager. The only way I can do that is by learning from others' approaches. If you'd like to continue the dialogue feel free to email me at email@example.com
I can't tell you how many times I have heard the phrase "I'm a banker, I don't need to understand the technology" from people in very senior positions with very high salaries.
The thing that they fail to understand - apart from routinely missing fundamental banking concepts like "on behalf of" or "product as sold" - is that banking is technology.
Banks don't store cash any more, they store bits.
Of course, it's better for everybody else if they do. We need them to understand the technology. They don't.
disagree with that statement.
"The product side needs to find out what the client really needs and build requirements out of it. The development side has to determine how to deliver it."
Fixed that for you.
"The sales side figures out what customers claim they can't live without. The product side figures out how to turn those perceived needs into a product. Development figures out how to make it meet with reality."