[wrs]

I sort of see your point, but you’re misusing the term “table stakes”, which by definition are what you have to put up to play at all. It sounds like you would implement the table stakes features, but not go farther with the “normal” extensions. The strategy being to get a callback with the exciting features, and have the table stakes features that let you avoid being vetoed for missing something essential.

[pfarrell]

Yeah that’s pretty much what happened. What I was thinking was we over estimated what the table stakes were. We were building a collaborative SQL editor aka notebooks. We spent way too much time getting it working with different dbs instead of focusing on a couple and building the things that actually made us stand out. A single customer wouldn’t really care about all the dbs we could talk to that were the one she was using.

[allknowingfrog]

I don't disagree, but I also hear "table stakes" used more often as a hand-wavy justification for a feature list than as a genuine, informed evaluation of customer demand. This seems to align with the sentiment of the parent comment. At some point, "common usage" become unassailable, no matter how much it irks me.