2 ms·

What success metrics do you use?

ghiculescu 8y ago
Hard to give a one size fits all answer, it depends on your project. But some examples: - speed of delivery (not so much hitting a public deadline as shipping it as fast as you thought you could internally) - quality of final product (were there delighters that didn't get built because they were too hard) - number of follow up bug fixes shipped shortly after the main project ships (did we ship a bunch of bugs and not realise until users found them) - number of new users acquired from shipping the feature
- waterlink 8y ago
  As a Lean practitioner, I love the last one: > number of new users acquired from shipping the feature
- Jach 8y ago
  How are you measuring these things? 1. It's one of my dreams to work at a place using prediction markets for internal estimates. Anything else feels worthless and engineers are incentivized into the "quadruple what you're currently thinking" estimate so they more often meet deadlines -- or try to "under-promise, over-deliver" except management rightly catch on to that one immediately. (As an engineer I still want to be a La Forge and work with other La Forges, even if Scotty[0] sometimes has a point; modeling managers as demanding children has some gaping model gaps.) 2. What I've seen is that many delighters aren't that hard, but they're often treated as "polish" that goes into the p3/p4 priority backlogs and maybe might resurface if a customer ever brings up a desire for that to the product management. What delighters have you seen that weren't shipped because they were too hard? Were they actually too hard, or was it just too much to get them done by some release date alongside all the other stuff so they get shoved to the backlog just the same? 3. Are you measuring bug count based on what customers report or internal bug reports? If internal, even if people aren't gaming this directly, it's still easy to get into a bad cycle where reported bugs get ignored and go unfixed which leads to fewer reported bugs. That might be mistaken for higher quality. 4. Is this one measured from surveys? Obviously not all features are directly customer visible so let's take something concrete like shipping an Observer mode for an RTS video game that shipped its big release a couple months ago. How would you measure the impact of getting new users from that one feature? [0] https://www.youtube.com/watch?v=8xRqXYsksFg https://www.youtube.com/watch?v=8xRqXYsksFg

Hard to give a one size fits all answer, it depends on your project. But some examples: - speed of delivery (not so much hitting a public deadline as shipping it as fast as you thought you could internally) - quality of final product (were there delighters that didn't get built because they were too hard) - number of follow up bug fixes shipped shortly after the main project ships (did we ship a bunch of bugs and not realise until users found them) - number of new users acquired from shipping the feature

waterlink 8y ago
As a Lean practitioner, I love the last one: > number of new users acquired from shipping the feature
Jach 8y ago
How are you measuring these things? 1. It's one of my dreams to work at a place using prediction markets for internal estimates. Anything else feels worthless and engineers are incentivized into the "quadruple what you're currently thinking" estimate so they more often meet deadlines -- or try to "under-promise, over-deliver" except management rightly catch on to that one immediately. (As an engineer I still want to be a La Forge and work with other La Forges, even if Scotty[0] sometimes has a point; modeling managers as demanding children has some gaping model gaps.) 2. What I've seen is that many delighters aren't that hard, but they're often treated as "polish" that goes into the p3/p4 priority backlogs and maybe might resurface if a customer ever brings up a desire for that to the product management. What delighters have you seen that weren't shipped because they were too hard? Were they actually too hard, or was it just too much to get them done by some release date alongside all the other stuff so they get shoved to the backlog just the same? 3. Are you measuring bug count based on what customers report or internal bug reports? If internal, even if people aren't gaming this directly, it's still easy to get into a bad cycle where reported bugs get ignored and go unfixed which leads to fewer reported bugs. That might be mistaken for higher quality. 4. Is this one measured from surveys? Obviously not all features are directly customer visible so let's take something concrete like shipping an Observer mode for an RTS video game that shipped its big release a couple months ago. How would you measure the impact of getting new users from that one feature? [0] https://www.youtube.com/watch?v=8xRqXYsksFg https://www.youtube.com/watch?v=8xRqXYsksFg