Admittedly there's a big difference between web apps and products that are meant to last or even contain hardware components.
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.
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.
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.
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...
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.
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.
I'm not sure if you mean you should hardly ever, or almost always, do the "1%" things.
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.
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.
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.
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.