Live data from Hacker News

I forced every engineer to take sales calls and they rewrote our platform

old.reddit.com

161–170 of 221 posts

Re: I forced every engineer to take sales calls and they rewrote our platform

#161

Earlier quoted context omitted.

God forbid an engineer should have an opinion on UI/UX.

I have long believed that the biggest issue here is that engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX. They are not always the best people to judge how or if less experienced users will tolerate or adapt to those patterns. It’s fine to have opinions but they must be prepared for them to be challenged. Even better if they can invite others to challenge…

> engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX

I don't think that's entirely accurate. We tolerate steep learning curves if the result is an increase to our power. That's why we are power users.

Vim, for example. Some of us put effort into learning it because it's a powerful and efficient editing language that will enable us to easily accomplish hard things.

Caring about the system itself and being willing to put effort into it are what separates power users from normal users. We don't do this because of masochism, we do it because we want to increase our power.

Normal users want the system to just do what they want without any thinking or effort at all, as though it was a highly specialized tool for their exact task rather than a powerful programmable general purpose computer.

Personally I don't care at all about how "less experienced users will tolerate or adapt". This unceasing focus on the wants and needs of normal users frequently hinders us. Developers typically reduce the complexity and feature set of a piece of software in order to turn it into something a normal user can deal with. We want more power, not less.

Normal users don't really matter unless they are directly paying our salary. We should all favor ourselves unless we're getting paid to focus on someone else.

Re: I forced every engineer to take sales calls and they rewrote our platform

#162
post #95

Earlier quoted context omitted.

There are two separate problems, and they aren't mutually exclusive, but this post seems to be specifically about the latter case (if one believes the story, of course): - The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements. - The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear. In the first the PM(…

Lots of product managers have never studied product development. You'll find philosophers, designers, physicists, even musicians in the role. Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees. The result, which you often see in companies with 300+ employees, is that engineers have far more e…

> Last year I dug into this and found it's not unusual. Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. But most have little to no background in business, marketing, economics, or product development. Some companies go even further and promote an engineer with project management experience to Head of Product.

I was right with you until the last sentence of this. As an engineer-turned-PM who is still very much technical, I can count on one hand the number of technically competent PMs I've known in my life, and have plenty of fingers left over. Having experience developing products can easily be a liability, because while delivering software is important, you're mostly expected to be an advocate for the business, which means that you live in the world of corporate politics and can't be perceived as too in the tank for the tech staff.

What I see is the exact opposite of what you've described: the PM that gets ahead is invariably someone with a background in business or marketing, and the technical background is deemed almost irrelevant. If you spend too much time focusing on technical issues, someone swoops in with the theater of "data-driven decisions" and "rapid iteration" -- you can justify virtually anything by cherry-picking statistics, and it's always possible to criticize the development speed of a team when you don't involve yourself in the details -- the role quickly becomes about spinning a compelling story to upper management.

Basically, a huge percentage of PMs understand little more than the first few chapters of The Lean Startup.

Re: I forced every engineer to take sales calls and they rewrote our platform

#163
post #119

Earlier quoted context omitted.

If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor? I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't design…

> If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor? Playing along with this analogy, what I think we see a lot of in product development is the customer going t…

> Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.

That’s the kicker. They know what the customer _wants_ not what they _need_

The number of times a Jr engineer has asked me “how do I accomplish task X in technology Y, it’s really important!”

I always, always ask “what problem are you trying to solve. Not once in over 15 YoE has the solution been to use X.

A good PM doesn’t say “this is what the customer needs” because most of the time the fucking customer doesn’t actually understand what they need.

The engineer knows that holding the ice cream cone upside down means they’re trying to use the product in a way it was never intended, so they push back.

A good PM would ask “why do you want to hold the ice cream cone upside down, customer?”

“Oh well we don’t actually want to hold it upside down, we just get frustrated that sometimes when we put too much ice cream on/in the cone it falls out. So if you can make the cone hold the ice cream while upside down, the problem is solved!”

“Oh, so what you actually need is a bigger cone that can hold more ice cream?”

“Oh, yeah that would work too”

meme about Spider-Man facepalming, where Spider-Man is the engineer

Re: I forced every engineer to take sales calls and they rewrote our platform

#165
I don't think you can build a unified platform using anecdotes. That's why product research and product market fit is a thing. Not product customer fit. Unless you're willing to understand how to address your market segment's painpoints, you're just going to have a platform like jira that does nothing great but everyone somehow limps along with it.

Re: I forced every engineer to take sales calls and they rewrote our platform

#166
post #128

Earlier quoted context omitted.

I run a small tech startup, about 2M ARR. And at times we’ve been short staffed on support and I’ve sat in for support for a day or two. And every time I do this I discover loads of issues customers are complaining about that don’t seem to ever make it back to our engineering team. Perhaps it’s just our support reps, or the nature of support, but they seem to love to “solve” problems themselves rather than reporting…

At my last job I worked in professional services, and after reporting multiple issues over and over and over through the normal process I finally wormed my way into a friendship with engineering and product leadership. A conversation with someone they trust was THE ONLY WAY to get them to take seriously a Jira report from the field saying "this is annoying/broken at every customer. Yes there is a workaround, but can…

This is spot on and echoes my experience (seeing it from the dev side)

Re: I forced every engineer to take sales calls and they rewrote our platform

#167
post #163

Earlier quoted context omitted.

> If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor? Playing along with this analogy, what I think we see a lot of in product development is the customer going t…

> Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists. That’s the kicker. They know what the customer _wants_ not what they _need_ The number of times a Jr engineer has asked me “how do I accomplish task X in technology Y, it’s really important!” I always, always ask “what problem are you trying to solve. Not once in over 15 YoE has the solution been…

My point is that by letting the customer define the solution rather than explain the problem, nobody knows they're even trying to hold it upside down. The why of it all is lost in some PM / Engineer power struggle that usually results in ice cream cones having covers (and a happy customer).

Re: I forced every engineer to take sales calls and they rewrote our platform

#168
post #93
post #83

Earlier quoted context omitted.

It sounds like it's a B2B SaaS product that's gone through multiple pivots with very weak guidance on product on every step. Not that I'm disagreeing with you, but it's a very common way for things to go wrong.

There's just something about the specifics that seems really odd to me. "60% of features"... really? Sixty percent, specifically? Like I think this story is maybe based on some series of events at a SaaS and I agree with you in principle but it seems like the author ran it through a Linkedin thought leader LLM.

60% of the features in a product small enough to rewrite in 2 weeks is probably 3 features.

Re: I forced every engineer to take sales calls and they rewrote our platform

#169
post #163

Earlier quoted context omitted.

> Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists. That’s the kicker. They know what the customer _wants_ not what they _need_ The number of times a Jr engineer has asked me “how do I accomplish task X in technology Y, it’s really important!” I always, always ask “what problem are you trying to solve. Not once in over 15 YoE has the solution been…

My point is that by letting the customer define the solution rather than explain the problem, nobody knows they're even trying to hold it upside down. The why of it all is lost in some PM / Engineer power struggle that usually results in ice cream cones having covers (and a happy customer).

As a sw engineer, I’m going to tell our customer that the thing they claim they want they do not need.

Because I’ve done this enough times, they’ll listen to me and we won’t waste time on it.

You should try it, instead of designing soggy ice cream cone caps.

Post reply on HN