

“Developers Don't Need to Know the Product” - benkross
http://www.projectsherpa.com/blog/developers-dont-need-to-know-the-product/

======
mathattack
There are two kinds of programmers with massive productivity benefits to an
organization:

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.

~~~
benkross
1 - You describe what most Banks and Hedge Funds would call RAD (Rapid
Application Developers) Developers (I know redundant like saying "The La Brea
Tar Pits...the the tar tar pits ; 0 ). They are those who are good enough with
dev, but understand the biz domain well. I've seen some startups where Product
Managers can also function in that capacity, prototyping, basic dev.

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 ben@projectsherpa.com

~~~
mathattack
I'll shoot you an email....

------
RougeFemme
>"The product side needs to provide a set of requirements, and the development
side needs to find out what the client needs, and how to deliver it. The
development side has to have enough product knowledge to determine the actual
need, not the stated want"

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.

~~~
soneca
Lost in slashes here.

------
pinaceae
"The product side needs to provide a set of requirements, and the development
side needs to find out what the client needs, and how to deliver it. The
development side has to have enough product knowledge to determine the actual
need, not the stated want"

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.

~~~
j_baker
See? Now you're going back to "engineer is a dumb machine who translates other
peoples' thoughts into code" land. Reality is more like this:

"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."

~~~
sanderjd
You're both being far too black-and-white or even _adversarial_ \- the jobs of
both the product and development teams is to _talk to each other_ to determine
how to realistically make the product that the customers want.

------
mrchuckmills2
> I’m sure that no one has ever said something that stupid out loud

You haven't been around much, have you?

~~~
benkross
I have been fortunate to be surrounded by people who are generally intelligent
and progressive that believe engineers should be part of the entire lifecycle.

Would you care to share your experience with us?

~~~
j_baker
It's rarely that blatant. Most people use more covert methods to keep
engineers out of the lifecycle. It can be frustrating because most of these
statements can be valid when uttered under different circumstances.

\- "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.

~~~
benkross
Hey j_baker thanks for sharing your perspective. The beauty and curse of code
is that it's hard to have subtext that isn't explicit, like in your example.
Again if "Let's see what product thinks" has the negative connotation you
allude to, in my mind that is a horribly run company. We are still very small
(6 ppl) so I want everyone to think like product managers and CEOs - as long
as they fulfill their core responsibilities. It gets a little harder bc
sometimes, engineers will be vetoed, not because they don't have great ideas,
but ultimately, there is some negotiation between a great product/experience
and something sellable or to work with a time constraint.

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 ben@projectsherpa.com

Cheers,

Ben CoFounder ProjectSherpa ben@projectsherpa.com

------
matthewsinclair
I've had a similar experience in financial services but from the other
direction, and particularly as an architect.

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.

~~~
gliese1337
You have to consider their goals, which define their needs. If they are in
very senior positions and have very high salaries already, and don't
understand the technology, then it's fairly obvious that _they_ do _not_ need
to understand the technology. They got everything they wanted without that
ever being a requirement.

Of course, it's better for everybody else if they do. _We_ need them to
understand the technology. They don't.

~~~
benkross
Until they are going to be bankers for a tech entrepreneur's M+A deal or IPO.
Then we'll see how much they need to know tech ;) The meek shall inherit the
earth in some ways was foretelling the rise of the technologists - disclaimer,
I am not religious and mean it in it's literal sense.

------
alien3d
Yes And No. No 1\. Should a developer will knew all business logic around
?Must knew accounting if erp ,must knew mechanical if do mechanical project.
Yes 1\. Most developer come from business logic itself and normal CS
degree.Some big system(ORACLE E_BUSINESS,SAP and so so on) not even cater for
their environment business.Some fell back to Microsoft Excel.So to counter
them at lease have business logic also.

------
j_baker
If there's one thing that grinds my gears, it's people who treat engineers as
if they were some kind of underclass who have absolutely _zero_ ability to
understand customer needs. It's sometimes like engineers solely exist to
translate other peoples' ideas into reality.

~~~
jmspring
Large companies that tend to be PM driven come to mind in this particular
scenario. It is not universal, but I've met multiple PMs from a couple of
companies that referred to engineers as "the devs" and felt their meetings and
schmoozing across teams was the most important thing.

