“Developers Don't Need to Know the Product” | Hacker News Reader

“Developers Don't Need to Know the Product”

projectsherpa.com

30 pointsbenkross26 comments

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.

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

I'll shoot you an email....

Why are people as short sighted to always say there is a limited number, and expect they define every possibility.

It writes a little easier than, "Here are two dimensions of many. On the X axis consider technical skills. On the Y consider 'knowing your customer's business better than they do'. Plot a line..." :-)

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

Lost in slashes here.

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

Working with Product is never that clear cut. Sometimes they need to be prodded to come up with exact requirements.

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

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.

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

You haven't been around much, have you?

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?

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.

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

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.

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.

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.

Everything is based on stored bits. It's how those bits are interpreted that matters. No banker should care that they store bits instead of physical cash. It simply doesn't matter. I've only ever seen inept programmers think that everyone should know the underlying technology, which I guess you could say is hypocritical, as I doubt many of them truly understand what's happening in the lower levels of programming, physics, or math. Abstraction - it's important.

That is all going to change as the world becomes more data driven. As a sales person, relationships are important, but still without a deep understanding of my data, I would be incredibly inefficient. Talk like that also sounds like what the Equities traders were saying up until 2007 or 2008. I don't need to know tech, I don't need to know algos, until they were replaced by trading tech and those same guys who were making 1.5-2 MM/yr couldn't get 150K jobs. Automation and electronification are happening. Only people at Jamie Dimon and Lloyd Blankfein's level can truly afford to be luddites. As the old guard dies, the youth will start changing everything. Technocrats vs Plutocrats will rule.

If you could throw in some extra buzzwords and drop a few more names, it might be helpful in convincing me you're not an idiot.

Synergy.

Matthew, I should have put my response to you. I'll be curious to see what happens with Bitcoin and when crytocurrencies become the norm, whether the business will start to respect tech. Show me a great business mind with great technical sense and s/he will be the master of the universe. Algo and HFT which now move the majority of capital markets are essentially just messages passed back and forth. So to your point - you nailed it! And this is coming from a sales guy who recognizes the EXTREME strategic advantage technology provides. If any of you are interested in a Beta invite to the Next Gen job search and career management platform send me an email to ben@projectsherpa.com with the subject BETA

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.

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.

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.

Reply on news.ycombinator.com