It's a common issue to see a company's sales team promise new features in order to close a sale. Many times these new features are still in development or are still being designed. Sometimes features are sold before the development team even knows about them.

If the customer understands the features are not yet implemented this can help guide the product's design. However, if the sales team promises these features with an uninformed time frame it can put significant amounts of stress on the developers who are charged by management to meet the deadlines.

Additionally, sometimes non-existent features are sold to customers as being either completed or near completion when development may not even be aware of the requirements yet (legal/ethical issues notwithstanding).

Is there a word or phrase that can be used to describe the uninformed/irresponsible/unethical applications of this practice?

It's similar to feature creep, but occurs before development or design.

  • 17
    Unfortunately, it's usually called "business". May 6, 2013 at 15:45
  • 13
    "Chaos", "Disaster", and "business as usual" all come to mind May 6, 2013 at 15:45
  • 31
    "Monday". Alternatively, "Tuesday", "Wednesday", "Thursday", and "Friday".
    – jcmeloni
    May 6, 2013 at 15:47
  • 5
    I think Feature Driven Development is the closest.
    – superM
    May 6, 2013 at 15:52
  • 2
    fun, fun, fun! bullet-point engineering? (or a little later) vaporware?
    – Lothar
    May 6, 2013 at 16:11

6 Answers 6


Overly optimistic scheduling is the term used by Steve McConnell in his book Rapid Development. He also uses the term wishful thinking.

McConnell writes (with supporting evidence) that an overly optimistic schedule actually makes the project later.

I had a bad experience with schedule pressure once. A customer was unhappy with a timeline, even though it was in line with similar projects. We hired a contract programmer with the hopes of shortening the timeline. The customer added many more features. (There was no review of "hey, the project is taking too long, and now you want more features?") The contract programmer was not as good as we had hoped, and I spent lots of time fixing bugs and design problems.

I don't want to live through that experience again as much as I can help it.

Yes, you should look for creative ways to help the sales team and management meet their commitments. Sales pay your salary.

Yes, you should be politely and firmly speak up about unrealistic schedules. The schedule may not change, but you did what you could. You owe it to your management to give them your best professional opinion, even when it is not what they want to hear.

  • Thank you. The phrase "Overly optimistic scheduling" yields some interesting search results.
    – Corion
    May 6, 2013 at 18:58


Keep in mind that sales teams are there to ... sell the product you wrote. They are naturally adapting to client demand and selling features that their (and yours!) clients need. You actually want them doing this; it means that revenue is coming in the door and that your product is staying relevant to market needs.

I'll note that this can be related to vapor-ware, in which things are promised and promised but never delivered. But there's a nuance behind that term that's not applicable to your question.

It's only an issue when delivery schedules aren't clearly defined or when the sales team over-promises on what can be delivered. And while this creates stress for the developers involved in implementing those visions, ultimately it isn't their issue to resolve. Upper management and product development management needs to work with the sales management to define when features can be advertised for sale and what schedules can be committed to. Over-commitment tarnishes the company's image and is rightfully an issue for upper management to resolve.

Generally speaking, Developers (and Sales...) like to see a Design => Sell => Develop approach to sales and marketing. Development has an idea of what might be flogged to the potential clients and Sales has an idea of when idea XYZ could actually be delivered if the potential client is interested.

There are cases where you'll see Sell => Design => Build, and this path is more likely to cause problems for the development team. On the one hand, if the Sales team really understands the code base* then this can be an effective route to new contracts. On the other hand, there is a greater chance to over-promise what can actually be delivered in a reasonable period of time. Your question calls out some of the keys in determining how well this approach will work out.

*Yes, I know the cynical reply of "that never happens." But it can occur when one of the founders of a firm was highly technical and has moved into a role driving more sales. There is also whole branch of "Technical Sales" personnel as well.

  • 1
    I'm not referring to the normal cycle of feedback, which I expect would include development in the discussion of the feature's feasibility and timeline (at least a little bit). Do you still think it's normal/good for sales to promise features - e.g. in the next version - before development is informed? I'm not sure how to clarify the original question for this distinction.
    – Corion
    May 6, 2013 at 16:02
  • 1
    Development shouldn't be picking what new features go into the product. That's Marketing's & Sales' jobs. If you have both, there is tension between Marketing & Sales, but that's not Dev's issue. Dev should provide feedback to M / S on relative cost of new features, but M / S declare what's to be built. Sales shouldn't give firm time-frames without getting an estimate from Dev first. But that's a "shouldn't" and not a "never." Many variables are in play depending upon size of contract; scope of change; and time-frame to delivery.
    – user53019
    May 6, 2013 at 16:09
  • 1
    @Bobson by definition, a new feature is one that needs to be invented and does not exist yet. I'm not trying to downplay the requirements for communication between Development and Sales, but Sales' job is to bring in ... new sales. And that requires new features.
    – user53019
    May 6, 2013 at 16:10
  • 2
    @GlenH7 - It's a spectrum. If your software is a point-of-sale system, and the salesman promises it can also manage receiving new inventory, that's reasonable. If the salesman promises it can also manage employee hours, that's something of a stretch, but there's a connection there. If the salesman promises it can also allow you to monitor cell phone usage in your store, that's a whole different kettle of worms, and where I feel like the OP is coming from.
    – Bobson
    May 6, 2013 at 16:18
  • 4
    "Keep in mind that sales teams are there to ... sell the product you wrote." But surely they're not selling the software you wrote; they're selling the imaginary software that your customer wants to buy...
    – Ant
    May 6, 2013 at 20:55

This is a kind of organizational anti-pattern. I've heard a few terms for this practice:

  • Sales-Driven Development
  • Sales-Oriented Programming
  • Coding by the seat of your pants

Although there's nothing fundamentally wrong with this, and occasionally it can be very good for the business, if over used, it degenerates pretty rapidly into a variety of well known problems: feature bloat, big ball of mud, magic pushbuttons, etc.

  • This seems to come closest to answering my actual question so far.
    – Corion
    May 6, 2013 at 17:43

My organization would call this violating safe harbor, or selling based on forward-looking statements.

Every press release and sales presentation comes with a safe harbor statement, which boils down to, "Make your purchasing decisions based on our current features, since we don't guarantee delivery on features that haven't been released yet." Our salespeople are obligated to never promise new features on any given date, and if they do, they do so in contradiction to the safe harbor statement.


As you describe it, there is nothing wrong with this technique of selling.

It only becomes similar to feature creep when the sales team promise things that cannot be delivered in the time frame they promise them in.

When this happens, the software development process can often fall by the wayside, things must be delivered quickly, and this can lead to

  • bad code
  • bad design
  • not enough (or no!) testing

Sadly, this is very common.

  • Pardon the poor description. I've updated to clarify.
    – Corion
    May 6, 2013 at 16:18

The cynic in me wants to say "Consulting", but that isn't entirely fair, because there are many consultants out there who are honest.

It is incredibly common in software consulting to sell something you haven't built yet, especially if you are doing bespoke, green-fields projects. Many organisations sell consulting services around their product, which invariably include customizations or unique features (SAP, Microsoft Dynamics, Microsoft SharePoint, etc).

It sounds to me like you are facing the frustration that comes from having sales people who are too disconnected from the technical team. There are many ways to improve this situation, but one we are starting at my workplace is "learning sessions" where different people teach the rest of the team about their job. Developers can learn about sales, and the challenges therein; Salespeople can learn about the challenges of software development. Another technique is to have the salesperson sit with the people whose services they sell. It breaks down the "us vs them" boundaries, and encourages everyone to play for the same team.

Not the answer you're looking for? Browse other questions tagged or ask your own question.