5 ms·

Opportunity Sizing: Is the Juice Worth the Squeeze?

64 points by harterrt 5y ago

bcherny 5y ago
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.
- giantg2 5y ago
  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.
  - chii 5y ago
    > 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!
    - giantg2 5y ago
      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.
- harterrt 5y ago
  Thanks for the note and I'm glad the piece was useful!
dandellion 5y ago
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.
- tuukkah 5y ago
  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.)
  - seoaeu 5y ago
    Is "users will become advocates" a real thing that meaningfully drives market share at this point? Sure there's anecdotes floating around of this happening, but I've never been able to tell whether it actually has an impact or if it was just power users justifying why they should be considered disproportionately important.
    - tuukkah 5y ago
      I was commenting from a more general point of view: It might or might not be significant for Firefox at this point, but it's weird that all the author says about the question is that you multiply by the answer ("Multiplying 1x2x3"). Certainly marketing people care about the net promoter score, and it would be good to have an idea how its changes affect growth.
    - dandellion 5y ago
      When it comes to any of the major browsers I really doubt power users drive any significant market share. But is it the same for a niche browser? Mozilla have been trying to chase shiny features to drive adoption yet they somehow keep losing more and more market share. Why can't they at least listen to some of the people who are actively trying to use their browser... have they decided they're going all in and they'll either have it their way or they'll die trying? I would be really sad to lose my favourite browser like that.
cassepipe 5y ago
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.
- sciurus 5y ago
  Are the financials of KaiOS public?
tziki 5y ago
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.
- iib 5y ago
  A thing to keep in mind in these situations is that making the system a bit more type safe may be more personally satisfying for the engineers. They may see that as a more worthy goal than fixing `n` additional bugs. Same thing with premature, or otherwise unnecessary, optimization. Sometimes it's just fun!
  - harterrt 5y ago
    Author here. I fully support prioritizing a project because it's fun! We need to own that rationale though. In OP's situation, it sounds like their counterpart is trying to argue that this project is a "good thing to do" for the user/system. In reality, it's a bit of code hygiene that makes it more fun to do work (still important [1]). That dissonance hides the true value of the work and makes it difficult to reason about. [1] https://blog.harterrt.com/bad-tools https://blog.harterrt.com/bad-tools
- harterrt 5y ago
  Thanks for the note! Doing opportunity sizing early in the product life-cycle definitely helps with this type of situation. Though, I've found it only really helps when it's a forward looking analysis or (rarely) when part of a no-blame retrospective.
coolgeek 5y ago
harterrt - I hope you're still reading this... This is a really good (initial) framework for thinking about what new features should or should not be built. But I would advise against using it (alone) as a tool for deciding which existing features should be removed (as other readers suggest may be happening). With new features, it's a binary choice - build or not. With existing features, there is a third choice - continue development, stop development (but maintain), or remove feature. Removing features has costs that might not be worth the savings. Google lost a lot of goodwill over the last few years by unceremoniously dropping products. Mozilla, over the last year or so, seems to be making some of the same mistakes. Chromium is terrible enough that users don't really have an alternative - at the moment. But goodwill is really hard to get back after it's been squandered.

64 points by harterrt 5y ago

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.

giantg2 5y ago
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.
- chii 5y ago
  > 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!
  - giantg2 5y ago
    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.
harterrt 5y ago
Thanks for the note and I'm glad the piece was useful!

dandellion 5y ago

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.

tuukkah 5y ago
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.)
- seoaeu 5y ago
  Is "users will become advocates" a real thing that meaningfully drives market share at this point? Sure there's anecdotes floating around of this happening, but I've never been able to tell whether it actually has an impact or if it was just power users justifying why they should be considered disproportionately important.
  - tuukkah 5y ago
    I was commenting from a more general point of view: It might or might not be significant for Firefox at this point, but it's weird that all the author says about the question is that you multiply by the answer ("Multiplying 1x2x3"). Certainly marketing people care about the net promoter score, and it would be good to have an idea how its changes affect growth.
  - dandellion 5y ago
    When it comes to any of the major browsers I really doubt power users drive any significant market share. But is it the same for a niche browser? Mozilla have been trying to chase shiny features to drive adoption yet they somehow keep losing more and more market share. Why can't they at least listen to some of the people who are actively trying to use their browser... have they decided they're going all in and they'll either have it their way or they'll die trying? I would be really sad to lose my favourite browser like that.

cassepipe 5y ago

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.

sciurus 5y ago
Are the financials of KaiOS public?

tziki 5y ago

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.

iib 5y ago
A thing to keep in mind in these situations is that making the system a bit more type safe may be more personally satisfying for the engineers. They may see that as a more worthy goal than fixing `n` additional bugs. Same thing with premature, or otherwise unnecessary, optimization. Sometimes it's just fun!
- harterrt 5y ago
  Author here. I fully support prioritizing a project because it's fun! We need to own that rationale though. In OP's situation, it sounds like their counterpart is trying to argue that this project is a "good thing to do" for the user/system. In reality, it's a bit of code hygiene that makes it more fun to do work (still important [1]). That dissonance hides the true value of the work and makes it difficult to reason about. [1] https://blog.harterrt.com/bad-tools https://blog.harterrt.com/bad-tools
harterrt 5y ago
Thanks for the note! Doing opportunity sizing early in the product life-cycle definitely helps with this type of situation. Though, I've found it only really helps when it's a forward looking analysis or (rarely) when part of a no-blame retrospective.

coolgeek 5y ago

harterrt - I hope you're still reading this... This is a really good (initial) framework for thinking about what new features should or should not be built. But I would advise against using it (alone) as a tool for deciding which existing features should be removed (as other readers suggest may be happening). With new features, it's a binary choice - build or not. With existing features, there is a third choice - continue development, stop development (but maintain), or remove feature. Removing features has costs that might not be worth the savings. Google lost a lot of goodwill over the last few years by unceremoniously dropping products. Mozilla, over the last year or so, seems to be making some of the same mistakes. Chromium is terrible enough that users don't really have an alternative - at the moment. But goodwill is really hard to get back after it's been squandered.