Live data from Hacker News

Opportunity Sizing: Is the Juice Worth the Squeeze?

blog.harterrt.com

1–10 of 26 posts

Re: Opportunity Sizing: Is the Juice Worth the Squeeze?

#3
I wonder if this kind of reasoning might be why Mozilla keeps dropping features of Firefox I liked such as RSS, bookmark descriptions, FTP, while adding stuff I don't care about like Pocket and Hello. I've recently finally caved in and installed Chromium and Brave, to see if they might be worth switching because of the reasons I had for using Firefox are just not there any more. After 15 years using Firefox (and advocating for it and installing it on many of my families computers for many years) it's hard to switch, and with the state of privacy and tracking I feel like my only choice is to pick what type of poison I want to drink.

Re: Opportunity Sizing: Is the Juice Worth the Squeeze?

#4

I wonder if this kind of reasoning might be why Mozilla keeps dropping features of Firefox I liked such as RSS, bookmark descriptions, FTP, while adding stuff I don't care about like Pocket and Hello. I've recently finally caved in and installed Chromium and Brave, to see if they might be worth switching because of the reasons I had for using Firefox are just not there any more. After 15 years using Firefox (and advo…

I think you are right, the author does not discuss the ultimate question of their framework at all: "3. How will those users change?" That is, will the users become advocates of our products and recruit many more users, or will they become disillusioned and turn to competing products even for the heck of it. (Not every decision and outcome is logical either.)

Re: Opportunity Sizing: Is the Juice Worth the Squeeze?

#5
post #2

This is one of those “Product Management 101” things that engineers are surprisingly bad at. I couldn’t agree more that this is an essential skill for engineers (especially sr engineers), whether they’re working on infra, growth, or product.

At least in my experience, management tends to break engineers of this 'skill'. They usually just want us to build whatever they say. Never mind if we could tweak the underlying business process to make the technical system better and even save the business money.

Re: Opportunity Sizing: Is the Juice Worth the Squeeze?

#6
One sure thing is when you actually finish a project it might be worth trying to market it or just wait a little to see where it can go. See Firefox OS, or how we could have had an android independant alternative phone os and how Mozilla could have been financially independent thanks to revenues that are now going to KaiOS.

Re: Opportunity Sizing: Is the Juice Worth the Squeeze?

#7
post #5
post #2

This is one of those “Product Management 101” things that engineers are surprisingly bad at. I couldn’t agree more that this is an essential skill for engineers (especially sr engineers), whether they’re working on infra, growth, or product.

At least in my experience, management tends to break engineers of this 'skill'. They usually just want us to build whatever they say. Never mind if we could tweak the underlying business process to make the technical system better and even save the business money.

> They usually just want us to build whatever they say.

a bad manager would.

But also, an engineer capable of this is basically CxO material - which threatens said manager's career progress!

Re: Opportunity Sizing: Is the Juice Worth the Squeeze?

#8
Something like this should be part of every engineering curriculum. As a small anecdote, I've several times ran into engineers who spent inordinate amounts of time to make the system just a tiny bit more type safer, and when I ask how many bugs would this have fixed during the last year they don't know. When I do the work and send them the single, low-impact bug their efforts would've fixed, they still go through mental gynastics to justify their efforts.

Re: Opportunity Sizing: Is the Juice Worth the Squeeze?

#9

I wonder if this kind of reasoning might be why Mozilla keeps dropping features of Firefox I liked such as RSS, bookmark descriptions, FTP, while adding stuff I don't care about like Pocket and Hello. I've recently finally caved in and installed Chromium and Brave, to see if they might be worth switching because of the reasons I had for using Firefox are just not there any more. After 15 years using Firefox (and advo…

That's funny, because I remember Firefox starting as "Phoenix", a very lightweight browser free from the bloat of Netscape.

I also don't quite get people's attachment to FTP. FTP has always been a horrible protocol and only relatively tolerable back before the Internet got so widespread. The moment one went from a modem to say, DSL, one would quickly bump into the horrors of FTP under NAT. And even before then, FTP sometimes screw up hours of downloading with ASCII mode.

FTP is clearly a protocol made for command-line comfort, and was never a good fit for something like a web browser anyway. The directory listing is an atrocity because it's made for human eyes and requires a dozen different parsers for automation depending on variety. The mess with the passive/ASCII stuff requires the user to understand those are things that exist and what they may want. And the hacky anonymous download access was achieved by giving the user instructions in the login banner.

All those things are really not suitable for anything that aims to make it simple to download on click.

Re: Opportunity Sizing: Is the Juice Worth the Squeeze?

#10
post #7
post #5

Earlier quoted context omitted.

At least in my experience, management tends to break engineers of this 'skill'. They usually just want us to build whatever they say. Never mind if we could tweak the underlying business process to make the technical system better and even save the business money.

> They usually just want us to build whatever they say. a bad manager would. But also, an engineer capable of this is basically CxO material - which threatens said manager's career progress!

Not just bad managers. At large companies the processes and leadership structure are sometimes too focused on meeting dates (usually arbitrary) and sticking to the initial plan/design. I get that we won't change course for everything or we will end up with scope creep or in a loop of refactoring, but it would make sense for the items with the largest benefit or clear net value-add.
Post reply on HN