The odd couple: Working with the sales team

Despite the cultural divide between the sales and development teams, they are more linked than they might care to admit. Their mutual success is tied to a product launch from concept through implementation. Yet, frequently, these two groups are at loggerheads—the developers think the sales team makes unrealistic promises to the customers, and the sales team thinks development can’t hit a deadline.

The hard truth is that it’s not up to the development team to say whether the product is ready to sell. Even in good times, the sales cycle (length of time from initial customer lead to getting the check) can be three to six months—maybe even longer. To keep the lights on and pay the bills, the sales team will have to start prospecting for customers before the development team has completed the product. That means that the sales and development teams will have to work to coordinate their efforts internally.

Beyond that, the two teams may even work together with the customer to seal the deal. In this article, we’ll address how sales and development teams can work together—and why they should.

Setting expectations for sales
To do their jobs well, the sales team relies on the development team for accurate information about the product’s status. In setting expectations for the sales team, developers need to make an appropriate level of commitment for product development, including resources and timelines. Over-committing and under-committing both hinder the sales cycle for a product still under development. The sales team needs to provide the best case possible for customers interested in buying the product, and they can only do that with clear, reliable input from the development team.

In addition, the development team must set accurate expectations as to how the product functions today and how it will be enhanced in the future. They should also define interim workarounds for current programmatic issues and provide plans on how to resolve those issues permanently.

Setting expectations for developers
Just as developers need to keep the sales team informed, the reverse is also true. Sales people need to keep developers informed about what they need in order to sell the product; this includes:

Deadline requirements for development milestones, including the need for functional specifications, a product guide, and a working demo to show select customers.

Product functionality required in the beta product.

Product functionality required in the shipping product.

Fostering communications between sales and development
All that communication and expectation-setting sounds great, but on a practical level, how does it work? The particulars vary from organization to organization.

Nancyfaye Autenzio, president of Mobellium, a wireless applications startup, says, “In my opinion, the best conduit from sales to the developers is product management, which is typically a marketing function. The product manager should be the individual responsible for qualifying, prioritizing, and documenting product features and enhancements. Having numerous sales people contacting developers at will, with conflicting needs and requirements, is a recipe for disaster.”

Kevin Hoisington, a sales and marketing consultant working with wireless-industry clients, suggests, “Make each side experience the other’s role. Make developers go on sales calls and to marketing events. Make the sales team spend time testing applications with the QA and development team for a demo or new release. Both are tough jobs, but respect has to be earned and internalized before both sides can appreciate it. Once this happens, communications between the groups will be open and trusted.”

What the sales team is up to
In case your organization doesn’t provide the extensive cross-training that Hoisington recommends, it’s worthwhile to consider how the sales team does its job when selling a product still in development. Naturally, what they’re doing will affect you as you develop the product, but there’s more: As a developer, you may even become involved in the sales effort. (More on that topic later in the article.)

First, a good sales team knows the audience. Some customers are just not interested in early versions of products; some love it and enjoy being early adopters. A savvy sales team will cultivate the early adopters. They’ll get these customers involved in focus groups and ensure their input in the early stages of the development life cycle when you are building functional specs.

Autenzio notes a set of best practices for selling products under development:

The sales team should choose from the “early adopter” list.

They should be up-front about where the product is in its life cycle, making sure the customer understands whether you’re in alpha, beta, or pilot.

They make sure the customer understands what the sales team is asking them to do and when. The sales team should qualify the customer to ensure that they’ll be able to give the feedback you need in a timely fashion.

They’ll articulate what the customer will get in return for their time and effort—write it down and follow up with interim reports during the trial.

They’ll plan for a feedback report to close things off.

Most of all, a good sales team will be responsive to the customer—and that’s where the development team comes in. The sales team may want to create special teams to respond to early-adopter customers, whether they bring up an implementation issue or a needed bug fix, or even if they need your company’s executive team to help justify their decisions and efforts to their senior management.

If a customer is going to buy a product under development, they must believe in the product as a solution. This confidence-building requires input from your organization’s sales, marketing, and development teams. And that’s where developers can enter into the deal-making.

How the development team can help seal the deal
Sales and marketing provide the client face of the company, but developers can add substance and technical backup that can differentiate your product’s sales pitch from the competition’s. Developers, system analysts, and even technical writers can contribute a great deal to the sales effort, answering customers’ questions with authority and know-how and reassuring customers that your team knows its stuff. The presence of the development team at the sales table demonstrates that there is a multidisciplinary team behind the sales force/business development team.

But developers must proceed with caution, because their hyperanalytical mindsets can become a disadvantage in this setting. “Developers, engineers, and technical people tend to be overly critical, even with their own work,” Hoisington notes. “Many savvy customers take advantage of situations on customer calls and at trade shows where technical team members are present and openly solicit their opinions on the state of a product or of a certain technology. A technology or product feature that meets 90 percent of the product functional specifications may be adequate for many customers, but in the eyes of a developer, it still may stink. That is what the customer will hear.”

You want to become a sales weapon for the company, not hurt the company’s efforts. To that end, when the customer is present, you need to temporarily sideline the critical attitude that makes you a great developer and instead focus on how the product can work for the customer.

Conclusion
Selling a product that’s still in development requires communication and teamwork between the development and sales teams. Despite their cultural differences, sales and development can impress clients who are on the fence about a purchase decision. The technical team’s heavyweight presence could be the nudge that encourages an indecisive customer to make the purchase.