3 ms·

None of those things are going to make a bad feature successful and not doing these will not make a good feature unsuccessful. They're all a form of technical d

None of those things are going to make a bad feature successful and not doing these will not make a good feature unsuccessful. They're all a form of technical debt that should be used very sparingly. Some of them will be more of a distraction than they're worth. Somewhere around 2010 a sort of product development pseudo-science started to take hold of the industry. Telemetry, A/B testing, surveys... oceans began to be boiled to avoid the uncomfortable fact that good product is developed intuitively by good product people. This "last 1%" is somewhat akin to waterfall development. Stay lightweight, hire people proven to design and ship awesome product and iterate as fast as possible. Use your own product. Talk to people who use your product. Take chances with your product design. Don't let organizational turf wars shape the product (something telemetry driven development is notorious for). Good old fashioned craftsmanship and creativity can go a long way. It's how new industries are born.

zwieback 3y ago
Just wondering, have you ever worked on something with a longer lifetime than the typical young engineer's job rotation? One thing we run into all the time is awesome quickly iterated things outlasting many people who understand how it was done. Admittedly there's a big difference between web apps and products that are meant to last or even contain hardware components.
- bluefishinit 3y ago
  Yep, I've worked on consumer products with decade plus lifespans. I was lucky enough to have worked in places that valued creativity, so shipping interesting features was always prioritized over direction by committee with data augmentation. I'll say that the end-users really loved that. They for the most part don't want you rearranging their living room (so to speak) they want new home additions.
- freetanga 3y ago
  Agree. Tech is a very broad universe. Is not the same to create a consumer facing platform for a new business than creating a Core System for a Telco, Utility or Bank. In those cases, the 1% (minus documentation) is crucial, as core features are not removed nearly ever. When you are experimenting with consumers and a feature might end up being a failure, then yes some of those items could be cataloged as tech debt of sorts.
- quickthrower2 3y ago
  The differing views I reckon is Startup VS. Older business. We are now veering into "strategy". You need to think about what your "100%" looks like for a project. Lower case agile makes these 100%s smaller by the projects being smaller so you have more information for the next iteration.
forrestthewoods 3y ago
> None of those things are going to make a bad feature successful and not doing these will not make a good feature unsuccessful. They're all a form of technical debt You said what I was thinking but couldn’t come up with the words. These aren’t the difference makers. Every “successful product” is held together with spit, glue, and an ocean of tech debt. There is no utopia.
dalyons 3y ago
intuitively i agree with you, i've seen a lot of the pseudo-science. But curious, can you elaborate on how telemetry driven development leads to organizational turf wars? I think i've seen that too but interested to hear your thoughts.
- bluefishinit 3y ago
  Everything from what gets tracked to how the data gets interpreted. It also can put a target on certain growth areas that will attract the more "ambitious" people from the company. All will try to make the case with the telemetry data. Does more time on a page mean users are more engaged or are they struggling to find out what's going on? Depends on which product manager can make a better case, probably involving even more telemetry which has to get prioritized. In the creative IC model, the designer and developer work to solve a problem based on their experience building product. Or someone has a kick ass idea one day and just implements it creating a step change in usage. That type of environment requires freedom and trust, it also puts a lot of control in the hands of the ICs which is why it's not popular with product managers, directors, vps...
  - vasco 3y ago
    I agree with you in spirit but you have to realize that every developer and designer pairs will think they are the ones that know what they are doing and should have the trust. I've seen trust be given for periods of years and teams simply wasting time and not meaningfully improving anything. This only works with good product people on board and most product people aren't any good at product.
    - lazyasciiart 3y ago
      Saying that you’ll use data to make decisions doesn’t change that - most people can’t tell the difference between meaningful data and random sets of numbers with a headline, so it’s still trust awarded to the most convincing salesman.
  - solatic 3y ago
mastazi 3y ago
I only partially agree with you because that list also includes things like documentation, error metrics and alerting... those have nothing to do with marketing folks pushing for more telemetry. Things like documentation and alerting are something a good engineer should worry about IMHO
preommr 3y ago
> None of those things are going to make a bad feature successful and not doing these will not make a good feature unsuccessful. Which is why the article says: "This last 1% isn't just what separates a great product from a good product, it's what separates a product that might not eventually fail from one that will eventually fail." A feature can easily be successful while being impossible to maintain because when it comes time to pay the cost, all the main people involved have already claimed the required benefits and jumped ship.
jrochkind1 3y ago
> They're all a form of technical debt that should be used very sparingly I'm not sure if you mean you should hardly ever, or almost always, do the "1%" things.
huganabaga 3y ago
> ship awesome product and iterate as fast as possible And that attitude is why so much software just sucks. Spending some time to contemplate and test and find out what's good and throw away what's not before it ships, all that goes a long way with quality. "Iterate as fast as possible" is one of those immature ADHD approaches and I'd run if a manager forced my team to do this kind of rushed nonsense.
- bluefishinit 3y ago
  > Spending some time to contemplate and test and find out what's good and throw away what's not before it ships Why would you build something to throw away before it ships? Hire good people and they won't build un-shippable crap. "As fast as possible" doesn't mean you rush things, it just means you don't waste time with all these peripheral activities.
  - huganabaga 3y ago
    > Why would you build something to throw away before it ships? That's because you learn things along the way. About underspecified requirements, about design choices that looked good on paper but ended up brittle, about tech that promised something but couldn't hold up to it when tested out thoroughly. There are many reasons and in every field you see this effect. > Hire good people and they won't build un-shippable crap Ever heard of a prototype? Those exist for a reason.

zwieback 3y ago

Just wondering, have you ever worked on something with a longer lifetime than the typical young engineer's job rotation? One thing we run into all the time is awesome quickly iterated things outlasting many people who understand how it was done. Admittedly there's a big difference between web apps and products that are meant to last or even contain hardware components.

bluefishinit 3y ago
Yep, I've worked on consumer products with decade plus lifespans. I was lucky enough to have worked in places that valued creativity, so shipping interesting features was always prioritized over direction by committee with data augmentation. I'll say that the end-users really loved that. They for the most part don't want you rearranging their living room (so to speak) they want new home additions.
freetanga 3y ago
Agree. Tech is a very broad universe. Is not the same to create a consumer facing platform for a new business than creating a Core System for a Telco, Utility or Bank. In those cases, the 1% (minus documentation) is crucial, as core features are not removed nearly ever. When you are experimenting with consumers and a feature might end up being a failure, then yes some of those items could be cataloged as tech debt of sorts.
quickthrower2 3y ago
The differing views I reckon is Startup VS. Older business. We are now veering into "strategy". You need to think about what your "100%" looks like for a project. Lower case agile makes these 100%s smaller by the projects being smaller so you have more information for the next iteration.

forrestthewoods 3y ago

> None of those things are going to make a bad feature successful and not doing these will not make a good feature unsuccessful. They're all a form of technical debt You said what I was thinking but couldn’t come up with the words. These aren’t the difference makers. Every “successful product” is held together with spit, glue, and an ocean of tech debt. There is no utopia.

dalyons 3y ago

intuitively i agree with you, i've seen a lot of the pseudo-science. But curious, can you elaborate on how telemetry driven development leads to organizational turf wars? I think i've seen that too but interested to hear your thoughts.

bluefishinit 3y ago
Everything from what gets tracked to how the data gets interpreted. It also can put a target on certain growth areas that will attract the more "ambitious" people from the company. All will try to make the case with the telemetry data. Does more time on a page mean users are more engaged or are they struggling to find out what's going on? Depends on which product manager can make a better case, probably involving even more telemetry which has to get prioritized. In the creative IC model, the designer and developer work to solve a problem based on their experience building product. Or someone has a kick ass idea one day and just implements it creating a step change in usage. That type of environment requires freedom and trust, it also puts a lot of control in the hands of the ICs which is why it's not popular with product managers, directors, vps...
- vasco 3y ago
  I agree with you in spirit but you have to realize that every developer and designer pairs will think they are the ones that know what they are doing and should have the trust. I've seen trust be given for periods of years and teams simply wasting time and not meaningfully improving anything. This only works with good product people on board and most product people aren't any good at product.
  - lazyasciiart 3y ago
    Saying that you’ll use data to make decisions doesn’t change that - most people can’t tell the difference between meaningful data and random sets of numbers with a headline, so it’s still trust awarded to the most convincing salesman.
- solatic 3y ago

mastazi 3y ago

I only partially agree with you because that list also includes things like documentation, error metrics and alerting... those have nothing to do with marketing folks pushing for more telemetry. Things like documentation and alerting are something a good engineer should worry about IMHO

preommr 3y ago

> None of those things are going to make a bad feature successful and not doing these will not make a good feature unsuccessful. Which is why the article says: "This last 1% isn't just what separates a great product from a good product, it's what separates a product that might not eventually fail from one that will eventually fail." A feature can easily be successful while being impossible to maintain because when it comes time to pay the cost, all the main people involved have already claimed the required benefits and jumped ship.

jrochkind1 3y ago

> They're all a form of technical debt that should be used very sparingly I'm not sure if you mean you should hardly ever, or almost always, do the "1%" things.

huganabaga 3y ago

> ship awesome product and iterate as fast as possible And that attitude is why so much software just sucks. Spending some time to contemplate and test and find out what's good and throw away what's not before it ships, all that goes a long way with quality. "Iterate as fast as possible" is one of those immature ADHD approaches and I'd run if a manager forced my team to do this kind of rushed nonsense.

bluefishinit 3y ago
> Spending some time to contemplate and test and find out what's good and throw away what's not before it ships Why would you build something to throw away before it ships? Hire good people and they won't build un-shippable crap. "As fast as possible" doesn't mean you rush things, it just means you don't waste time with all these peripheral activities.
- huganabaga 3y ago
  > Why would you build something to throw away before it ships? That's because you learn things along the way. About underspecified requirements, about design choices that looked good on paper but ended up brittle, about tech that promised something but couldn't hold up to it when tested out thoroughly. There are many reasons and in every field you see this effect. > Hire good people and they won't build un-shippable crap Ever heard of a prototype? Those exist for a reason.