[yashap]

Depends on the company.

When I worked for a larger company with a pretty mature product, this was true - deadlines were internal and arbitrary. It also helped that the product was more of a “nice to have” for our customers than “absolutely crucial” - they didn’t truly NEED anything it did (it was software to make social media marketing more efficient).

But I’m now at a smaller Enterprise SaaS startup, where the product is absolutely crucial to the customer’s work (core operational software for public transportation agencies). The reality is that the product isn’t yet mature enough to close big sales without making sales commits. I dislike sales commits, but we’d legitimately lose every big RFP unless we commit to adding the ~2-5 features they really, truly need that we don’t yet have. And sales commits come with real, external due dates, that you need to be able to meet if you don’t want to piss off your customers. You need to be able to say “yeah, we can build X by date Y”, and then actually deliver on that.

[irrational]

This is one of the reasons I’ve stayed where I am for so long. I get paid a nice six figure income to work on a training platform that is useful, but not critical. It is a low stress job with little to no critical dates.

[lmm]

> The reality is that the product isn’t yet mature enough to close big sales without making sales commits. I dislike sales commits, but we’d legitimately lose every big RFP unless we commit to adding the ~2-5 features they really, truly need that we don’t yet have. And sales commits come with real, external due dates, that you need to be able to meet if you don’t want to piss off your customers.

That's just pushing the issue one level higher. Most likely both the customer and you would be happier if you were able to iterate with them rather than building the thing they thought they would want however many months back. (And while it may be harder to set up that kind of contract, it's absolutely possible)

[lelanthran]

> Most likely both the customer and you would be happier if you were able to iterate with them rather than building the thing they thought they would want however many months back. (And while it may be harder to set up that kind of contract, it's absolutely possible)

Possible? Sure. Just like it's possible that I could win the national lottery.

In practice, multiple companies bid for contracts, and all of the bids have to be of the form "Deliver $X in $Y months for $Z dollars".

No company is going to accept "Choose us, and we'll work until you're happy with the product or you run out of money, whichever comes first".

Agile doesn't work where there's competition for the project. It can't, because the buyer of that project cannot evaluate "we'll work until your money runs out" against the other bids that state "$X in $Y months for $Z dollars".

Agile works well for internal teams that are sheltered from having to provide competitive bids.

[webmaven]

One approach is value-based contracts: "we'll work with you and charge X% of the value we deliver."

[lelanthran]

> One approach is value-based contracts: "we'll work with you and charge X% of the value we deliver."

Which still loses to the other bidders who say "$X in $Y months for $Z dollars".

[webmaven]

No, not necessarily. It depends on how often and badly the org has been burned on past project failures.

Typically, the intermediate step is to tie some compensation (such as a bonus) to a particular metric, but why not just go whole hog?

Even if X% is projected to be larger than $Z (and in fact, the better the project succeeds, the larger the %X total ends up being, but you can cap it, or make the % progressive up to a point and regressive above it), the advantage for both client and vendor being aligned on the upside is considerable.

[yashap]

The problem is winning the RFPs. There are some core features and integrations that they really, really want. If we don’t have them, and won’t give a firm commitment to building them, we lose the RFP.

“We’ll work collaboratively and evolve the product over time in yet-to-be-determined ways” can work when you have an established relationship and 2-way trust, but there’s not much of that during an RFP. If a competitor commits to their biggest asks, and we don’t, we lose the RFP.

[holoduke]

Its an example of bad leadership. You see it often. Higher management thinks product x can be ready in a y period. Reality is much different. One of the key reasons why companies and products fail.