Sometimes being quick to market is more important then having to maintain the product. Sometimes providing a bad product is only relative to the competition (which may have a worse product). Sometimes having a good customer service is more important than the reliability of the product. etc.,.
I do agree with solving the end user needs... if a client does not need your product you really can't run a company for long.
Eventually will came someone with a truly good product and distrupt the market
In some fields having a good business and regulatory relationship with the customers (e.g., hospitals, DoD, banks, etc.,) is much tougher than building the product. There are many barriers in place and these fields are not so easily disrupted (having a superior product is definitely not enough).
Also note that having a bad product now that is better than the competition does not mean you cease to improve.
That is popular opinion among the unemployed, as hoisting that BS on your project lead has real world consequences after your code audit. =)
They want it! and they want it now!
The head engineer says it's all just a temp hack, it is completely shitty, they could give it to costumers but then the maintenance will be impossible, they will need months to add any new features on top of it, they will probably waste all their time on fixing bugs, and they'll quit if they have to maintain it for long.
What would you do? (A) continue develop until you have a nice maintainable product, or (B) sell the product now and face the consequence of wasted developer time and loss of their motivation.
Sometimes in such situations the answer is (A), but not always. It depends. How much money you got? how certain are you of the timeline for "finishing" the product properly? which option is riskier? How much competition you have and how likely they are to publish a product before you? What could having a real customer teach you about your product? What do you need in order to get the next round of investment?
This is just an example, but IMO product graveyard is filled with great maintainable and reliable code no one had a chance to use. I love software and I'm really not disregarding its importance, I just think it's not always the most important thing.
I will tell you a terrible secret of successful software companies: "One doesn't make money writing software, but rather reselling the same software mullions of times over."
You should know this already. =P
And I do have specific real cases from my experience in mind... One of a great product that never finished (money ran out, CEO didn't want to provide something that was for "a single customer" as in your words), another of a shitty buggy unmaintainable software that did grow a company from 4 to 100 employees then to an exit and only then came the nice eased-back rewrite.
I have culled many half-arsed options... and the decisions are far from arbitrary. Also, who budgets for a project burning over $100k a month in labor without a detailed plan... lol
Start-up have terrible survival odds. Decisions should not be arbitrary. There should be a detailed plan.
1. when two people are "talking past" each other.
2. It isn't only about 'what I'm saying'; multiple streams of conversation can happen at the same time and all be useful and even true
Groan. This comment could make its point without assuming what the other party knows or doesn't.
For example, for many engineers, what they (a) can learn and (b) be proud of while building a product is a big part of success.
For some CEOs, engineer satisfaction is only a secondary or tertiary goal -- their business success crowds out most other things. This is complex; sometimes this drive is what helps a business succeed; sometimes this is why people get treated poorly or ethics go out the window.
As this is mostly on-topic for the parent thread... I can respond...
When faced with a painful product launch/schedule, as management messed up resource budgets etc... there are a few actions one can usually take:
1. ignore the issue, accept a 60% probability of failure risk, and naively hope management is replaced
2. adjust current project scope, follow MVP rules, and defer features for v2
3. cull the project, and eject unprofitable/unhelpful members from the team
4. Leave the company before the shite hits the fan
Note, compromising workmanship is not on the list, as a business "Brand" is often more important than non-stakeholder opinions of intangible asset valuation.