Comment by bluefishinit | Hacker News Reader

Comment by bluefishinit | Hacker News Reader

Parent Full thread

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.

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.

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.

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.

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.

> 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.

> 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.

> 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.

> 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.

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

> 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.

> 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.

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.

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...

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.

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.

> In the creative IC model, the designer and developer work to solve a problem based on their experience building product.

This is great for helping to build products, not companies. Companies are larger than just their products; they also have obligations to existing customers, stakeholders represented by auditors, etc. That's not an argument that new products should be anchored down by these other concerns; it's an argument that "creative IC" should only be launched with clear alpha/beta/preview-style labeling, and that there should also be engineers who are not paired with Product, whose job it is to "fill in the rest", so to speak, because it's also important.

Reply on news.ycombinator.com