I tend to go by results, and for me, "results" means shipped* code that is used and accepted by end users**, can be maintained and extended***, and doesn't generate trouble tickets.

* MVP doesn't count.

** Can include users inside the organization.

*** It's OK if it requires senior-level ongoing support. I think expecting it to be maintained by monkeys is a bad idea.

To me, "MVP doesn't count" feels like a crazy take -- in many roles, the _only_ ask is to produce a series of different MVP's. I guess maybe the definition of "MVP" is a bit squishy, and these people-who-ship-MVPs themselves make MVP-MVP's, which shouldn't count as shipped?

I spent most of my career, shipping finished product, which, in many cases, probably could have benefitted from an MVP-like "tuning phase," but we called that "beta." I think MVP generates more useful feedback, but I really don't like thinking of an MVP as "shipping software."

I also worked for hardware companies, where shipping stuff had some pretty serious stakes, and learned how to make sure we got it as good as possible, before getting it out the door.

I like the idea of evolutionary design, and "tuning," but I think it's a bad idea (for me) to deliberately ship bad software as an end-product.

(Also, MVP, by definition, generates lots of trouble tickets. I am allergic to trouble tickets. It's totally a personal thing, but I live by it).

saying "MVP doesn't count" implies that you throw it away and then right "the perfect system" at some point. If you've ever had an MVP land you know that's not how it happens.

I write "as close to perfect" as I can get. I know that "The Perfect is the enemy of the good" is a popular meme, but I have found that "The perfect is something to strive for" has been useful, for me.

In fact, my way has been working for me, for decades.

I'm quite aware that many folks do it differently, and that's one reason that I try to "keep it in the I," and write about how I do it, and talk about the bar that I set, for myself.

Most of the software I write, is free software that Serves a pretty small demographic. It can have a fairly outsize influence on the lives of the people that use my software, and I really care about the end-users of my work, so I tend to set a pretty high personal bar.

I'm quite aware that I don't have many of the stressors that beset commercial software houses, so I sincerely don't feel "snooty." In fact, I feel profoundly grateful to be in a position, where I can follow my muse.

I really would like it if folks wrote better stuff, but I am also aware of the culture, and how that's next to impossible, these days.

How do you define success? If a product bombs, is that because of the engineering or the product design?

I don't think it's possible to answer generally. Track what matters for your business.

if it's successful, it's because of sales. If it fails, engineering didn't build the right thing / was too slow - it really doesn't matter.