Live data from Hacker News

One cost engineers and product managers don't consider

firstround.com

51–60 of 102 posts

Re: One cost engineers and product managers don't consider

#52
post #49
post #15

For years, the two things that most frustrated me to hear from product managers were "how hard would it be..." and "can't you just..." It took me quite a while to figure out why I had such a strong, visceral reaction to these phrases. Oh, man. When it comes to my natural reaction to this, the words 'strong and visceral' doesn't even do justice. It took me a really long time to understand why I had such a deep-seated…

> the business units are so disconnected from engineering they don't even realize the costs of what they're asking for In software you get this at all levels, including in the freelance/consulting world - people have no clue of the costs of what they're asking for so when they can't even make bad guesses, they go with "how hard would it be..." for a big feature request or "can't you just..." for what they see as a sm…

You're putting way too much baggage on to "how hard". It doesn't necessarily carry any implications of "yesterday and with no budget"; it's a scoping question.

"How much will it take and how much will it cost to... ?" condenses down to "how hard…". You can tell they're functionally equivalent because you can give the exact same answer to both.

"Can't you just" is a whole different story, granted.

Re: One cost engineers and product managers don't consider

#53
post #15

For years, the two things that most frustrated me to hear from product managers were "how hard would it be..." and "can't you just..." It took me quite a while to figure out why I had such a strong, visceral reaction to these phrases. Oh, man. When it comes to my natural reaction to this, the words 'strong and visceral' doesn't even do justice. It took me a really long time to understand why I had such a deep-seated…

The worst are inexperienced product managers who look at you like you're trying to pull a fast one.

If it's something small, then maybe just code it up quick in a branch named after the PM-Feature (so you can keep track). Then ask them to validate the requirement before you merge it in (hopefully you can help with this). At least this way they know that you aren't being lazy etc.

Next time that PM asks for something "simple", do a quick branch list of invalidated feature requests.

Re: One cost engineers and product managers don't consider

#54
I've frequently heard designers, developers and VPs of Engineering -- which I'll collectively call "builders" -- argue that a product should have fewer features and thus should be "simple."

But I honestly can't remember reading once when a user has said they want fewer features. Users want it to easy, yes, but they also want the features that make their lives, well, easier; see how that works?

Whenever I hear builders argue for simplicity I get deja-vu as if I'm hearing union members argue against those who might cross the picket line, or lobbyists trying to convince congress to give their clients tax breaks, or record companies complaining about downloaded musics, or, or, or,... well you get the picture.

Re: One cost engineers and product managers don't consider

#55
post #49
post #15

For years, the two things that most frustrated me to hear from product managers were "how hard would it be..." and "can't you just..." It took me quite a while to figure out why I had such a strong, visceral reaction to these phrases. Oh, man. When it comes to my natural reaction to this, the words 'strong and visceral' doesn't even do justice. It took me a really long time to understand why I had such a deep-seated…

> the business units are so disconnected from engineering they don't even realize the costs of what they're asking for In software you get this at all levels, including in the freelance/consulting world - people have no clue of the costs of what they're asking for so when they can't even make bad guesses, they go with "how hard would it be..." for a big feature request or "can't you just..." for what they see as a sm…

The people asking probably don't think they have no clue of the costs of what they are asking for, they think they have a vague idea of the relative costs based on their perception of what is involved and their past experience of other changes.

Now, these ideas may often be very wrong, and may be in fact so wrong that "no clue" is the best description, but its not, for the most part, dishonesty when people act like they have some general expectation of the cost.

Re: One cost engineers and product managers don't consider

#56
post #35

Users don't want complexity, either. This is not true. Users want a manageable and appropriate amount of complexity. Sane defaults, reasonable options. In the sitcom 'Allo 'Allo, a woman is trying to set up a date with a character who's a stickler: "What if I am late?" > "Don't be late" > "What if I am early?" > "Don't be early. Be punctual ." I'm reminded of this whenever I see something on the minimalist vs flexibi…

> Users want a manageable and appropriate amount of complexity. Sane defaults, reasonable options.

+1

Re: One cost engineers and product managers don't consider

#57
post #4

Good article, makes an important point about complexity. Just want to add one extra thought though: he or she will run reports against the usage data to find out whether a given feature is often used. That data can then be run past the product managers who can help decide whether it's sensible to just drop the feature. It's important to be careful here, and it's one of the traps that is very easy to fall into (see Gn…

That's how I feel about Apple deeming unimportant my Home, End, PgUp, PgDn, and front-delete keys.

Just in case you’re not aware: the Fn key, in conjunction with the arrow keys or the delete key, let you type those keys. Though that’s certainly not as convenient as having dedicated keys.

Also, you can remap different keys to those keys with the free software KeyRemap4MacBook (https://pqrs.org/macosx/keyremap4macbook/index.html.en). For instance, you can remap \ to be forward-delete and Fn+\ to be typing ‘\’.

Re: One cost engineers and product managers don't consider

#58
post #15

For years, the two things that most frustrated me to hear from product managers were "how hard would it be..." and "can't you just..." It took me quite a while to figure out why I had such a strong, visceral reaction to these phrases. Oh, man. When it comes to my natural reaction to this, the words 'strong and visceral' doesn't even do justice. It took me a really long time to understand why I had such a deep-seated…

I've had some luck defusing these kinds of remarks by calmly but firmly stating that "with though simplifying assumptions, anything is trivial". YMMV.

Re: One cost engineers and product managers don't consider

#59
post #4

Good article, makes an important point about complexity. Just want to add one extra thought though: he or she will run reports against the usage data to find out whether a given feature is often used. That data can then be run past the product managers who can help decide whether it's sensible to just drop the feature. It's important to be careful here, and it's one of the traps that is very easy to fall into (see Gn…

We hit this at MSN: we removed the "print" button from all articles. Result? Engagement in Japan fell. Why? Apparently, printing out a sheaf of articles to peruse on the train is (or was) a thing. Solution? Re-enabled the "print" button in Japan; everyone else was saved from downloaded the unused-in-market "print" button, lowering PLT.

Please keep in mind I'm talking about stuff from about five years ago when you run to MSN.jp looking for print buttons.

Re: One cost engineers and product managers don't consider

#60

I've frequently heard designers, developers and VPs of Engineering -- which I'll collectively call "builders" -- argue that a product should have fewer features and thus should be "simple." But I honestly can't remember reading once when a user has said they want fewer features. Users want it to easy , yes, but they also want the features that make their lives, well, easier; see how that works? Whenever I hear builde…

I think fewer features isn’t something a user would request. Fewer features is just something they would notice the absense of. Users don’t always know what they want.

For example, there may be a ten-item menu where the user only uses the two features at the bottom. The user is slightly annoyed every time they have to move the mouse all the way down there to select that feature. But it probably wouldn’t occur to them to ask that the other menu items be removed – they are just trying to ignore those items.

Post reply on HN