Hacker News Reader

Comment by fdgsdfogijq | Hacker News Reader

What I have noticed even in top engineering companies is an interesting dichotomy. Product determines the "innovation", engineering determines how to build it. I wonder if thats because, if you let engineers do both, you end up with a mess and accomplish nothing. Programming is hard enough, programming within well defined barriers and goals is much easier. You have a low risk cycle of design -> code -> test.

The issue is that often product is not technical enough to bake in technical possibilities to how they think about innovation. Not always, but I have seen this happening even on recommendation and ML marketing systems for some of the large most sophisticated companies.

View on HN

> I wonder if thats because, if you let engineers do both, you end up with a mess and accomplish nothing

No, it is because an Engineer (with technology selection blinders on) will jump to a What/How before the Why actually lands in a conversation.

The why will be recorded as "what the customer wants", we jump from problem to solution too fast.

In fact most of the times the product org only provides a "What" to the engineering team which is where most of the problems are buried & plays it close to the chest with the "Why".

I was an engineer reporting to the CPO in my last job and my entire job was to diffuse the "Why" down to the engineering org, so that they felt purposeful about the problems they were solving & to push back on the What if there's a better solution possible. But I didn't get to redefine the "Why" part of the question, even though I really wanted to do it to make more progress in the directions I was already headed.

Once you got "what", then you get to "how", "who", "when" and usually "how much?".

The message usually bounces off the end of that and goes back, to the customer who's eventually going to solve the "how much" problem.

>is because an Engineer (with technology selection blinders on) will jump to a What/How before the Why actually lands in a conversation.

I'm in marketing/biz dev now at an engineer-led company, and in a meeting last week a dev team presented a new UI that is a MASSIVE departure from our current approach. At the end of the demo, they informed us that a) it's being released in 2 weeks, b) do you think the clients will like it, and c) can we charge more for it?

> a) it’s being released in 2 weeks b) do you think clients will like it

Oh god, that gives me the sweats. Godspeed.

You let your engineers diffuse the "Why".

You let your engineers figure out the "How".

You let your engineers implement the "What".

... at the end you let your engineers figure out everything. So tiring.

> if you let engineers do both, you end up with a mess and accomplish nothing.

Hard disagree. When left on their own, a product oriented engineer delivers value orders of magnitude higher than a technical product manager.

As an engineer I want to agree. But for a large corporation, I think they prefer the risk averse approach of strict requirements for engineering.

> What I have noticed even in top engineering companies is an interesting dichotomy. Product determines the "innovation", engineering determines how to build it. I wonder if thats because, if you let engineers do both, you end up with a mess and accomplish nothing.

The top companies have product and engineering working closely together. This allows product people to go deep on optimizing their product skills and engineers to go deep on optimizing their development skills, both of which are most effective when performed in conjunction with each other as part of a strong team.

There are great product-minded engineers and great engineering-minded product managers out there, but it's much easier to find people who are simply good at their domain and know how to work closely with people in other domains to get things done.

Some companies try to cargo-cult this by drawing a dividing line: Product defines the "what" and engineers define the "how". Product works in isolation, hands things off to engineers, then engineers churn through tickets in isolation. This is not good at all.

In my experience, it's way too easy for engineers to geek out on the how without addressing the "why". I'm guilty of this myself, from time to time.

When product is leading the charge, it often means they've validated a need from a customer and are ready to address it. When engineering leads, they're often pushing a capability without having evaluated it against customer needs.

On the contrary, I've seen product teams assume the pain of the consumer and relay the same to engineering; and then engineers having to push back on the insane requirements.

Nevertheless, product which work in an agile model without collaborating with tech is doomed to fail

Reply on news.ycombinator.com