6

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.

Corion
  • 730
  • 6
  • 15
  • 17
    Unfortunately, it's usually called "business". – Corbin March May 06 '13 at 15:45
  • 13
    "Chaos", "Disaster", and "business as usual" all come to mind – Dan Pichelman May 06 '13 at 15:45
  • 31
    "Monday". Alternatively, "Tuesday", "Wednesday", "Thursday", and "Friday". – jcmeloni May 06 '13 at 15:47
  • @Dan, painfully accurate set of synonyms you have there. – cdkMoose May 06 '13 at 15:51
  • 5
    I think Feature Driven Development is the closest. – superM May 06 '13 at 15:52
  • 2
    fun, fun, fun! bullet-point engineering? (or a little later) vaporware? – Lothar May 06 '13 at 16:11
  • I think my long-winded (and somewhat biased) question may have distracted people from its actual purpose and unintentionally fostered discussion of the practice. I bolded the real question so hopefully we get more responses. I'm mainly interested in a **name for when the practice is detrimental** (or even internally-used jargon for it). – Corion May 06 '13 at 17:38
  • 2
    Unfortunately there's not usually special names or jargon terms for things which are so frequent as to be the norm. 4 on a Friday is beer thirty, 4 on a Tuesday however has no name because it is totally normal. – Jimmy Hoffa May 06 '13 at 18:33
  • I just hoped that if it had a name it would be easier to find documentation eschewing or decrying the negative sides of the practice (or with suggestions to improve it). Having a label applied makes it easier to discuss with coworkers and colleagues. – Corion May 06 '13 at 18:53
  • It's a project management problem, perhaps try closing this Q and asking on PM something like known cons and standard approaches to the problem if you want to get your head around the issue more clearly such that you could then converse more authoratatively on the topic. There's an extravagant amount of writing on the topic already – Jimmy Hoffa May 06 '13 at 19:06
  • Creep features? – psr May 06 '13 at 20:25
  • Business as usual. – Andrew Lewis May 06 '13 at 21:46

6 Answers6

15

"Normal"

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 06 '13 at 16:02
  • @Corion - Maybe something about inventing new non-existent features? – Bobson May 06 '13 at 16:08
  • 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. –  May 06 '13 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. –  May 06 '13 at 16:10
  • I updated the question to clarify. – Corion May 06 '13 at 16:18
  • 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 06 '13 at 16:18
  • @Bobson - Yes. I was wondering whether someone had coined a term for when the practice is done badly. – Corion May 06 '13 at 17:47
  • 1
    @Corion - I like "Sales Driven Development" myself, but I don't think that's quite irresponsible enough. – Bobson May 06 '13 at 18:25
  • Developer promoted to project/program management. Managers forced to put on sales hats in addition to everything else. I can work; but there's no guarantee that a good developer will make a good pmt, or that a good project manager will be able to sweet talk the customers effectively. – Dan Is Fiddling By Firelight May 06 '13 at 19:27
  • 1
    If sales people do not consult with the technical team leads in development, they might promise something which is impossible to deliver even if investment is available to hire an unlimited number of new people. Or they could promise something that is doable, but with a return on investment which is unreasonably negative (more than a reasonable cost for retaining customers). – Kaz May 06 '13 at 19:48
  • 1
    @Corion Would that not be *greed* (driven-development) if this practice is done badly? Either means making your developers work overtime in order or risking excessive contract penalities? Consider that sometimes losses are accepted just to get into business with a big players. – Lothar May 06 '13 at 20:44
  • 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 06 '13 at 20:55
  • @Ant - that is quite true. Ideally, there is more overlap than not between existing and promised features. But that's not always the case. –  May 06 '13 at 20:57
8

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.

p.s.w.g
  • 4,135
  • 4
  • 28
  • 40
7

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.

Aaron Kurtzhals
  • 2,138
  • 1
  • 16
  • 18
  • Thank you. The phrase "Overly optimistic scheduling" yields some interesting search results. – Corion May 06 '13 at 18:58
3

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.

Carolyn
  • 139
  • 2
1

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.

ozz
  • 8,322
  • 2
  • 29
  • 62
0

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.

guysherman
  • 669
  • 4
  • 8