[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.