Wednesday, March 05, 2008

aagpm: what role should sales have in development?

Jeff Lash's excellent site Ask a Good Product Manager lets clowns like me respond to questions posed by non-clowns like you.  And he occasionally posts your replies gawd luv 'im.

Last night an email dropped into my spam-crowded inbox with the following question:

How much should Sales be involved in Product Development?

We will develop about 10-15 new models this year, the list of which has been agreed upon with Sales at the end of last year.

Since then, we've been discussing these new projects with Sales at each of the monthly meeting they're holding.

I have the feeling that this was a bad idea; the projects have almost been re-discussed from the beginning each month, and there's still endless discussions about what the projects are exactly. The scope just keeps changing.

In my opinion, we should just keep them informed, through the meeting, of the progress of the projects (on track, waiting, ...). Not more.

What's your take on this?

There are those who believe one should treat sales like mushrooms when it comes to product development - keep them in the dark and feed them s__t.


They are coin-operated - sales people are interested in what it will take to close the deal they are working on Right Now, or ones that are looming large in their funnel. This makes them interested in features that are interesting to their customer, regardless of whether the feature helps the company. It's good for their deal, therefore it's good for them. Given the opportunity to steer development, they'll steer it into their deals and their customers first. Speaking of customers. . .

They believe they are the voice of the customer - salespeople spend a lot of time talking to people with money. This, dear colleague, gives them the impression that they are the voice of the customer, an impression they are more than willing to share with you if you give them the opportunity to do so. They will even argue that their opinion counts more than yours, because after all, they spend all day every day with customers, while you, Mr. Product Manager, spend your days writing requirements and looking like you need sleep.

They respond best to Big Animal Pictures - if you feed salespeople on a steady diet of detailed information, they will forget it. This has nothing to do with their intelligence, but on their uncanny ability to filter unnecessary information out of their world. They remember things like "when is it available" and "why is it better than the competition" and "how much does it cost".

Don't get me wrong, I love salespeople. They've got a tough job, and the best ones can be a joy to work with. But if you want to bring them into the development process, there are a few ground rules:

1. Interact with them one-on-one, not in groups, when it comes to getting their feedback - find the reps with accounts you want to talk to, or reps whose experience you respect. Interacting with them on a one-on-one basis doesn't create the sort of group-pressure that comes from one rep bringing up feature x and a lot of other reps chiming in that they want it to. It also gives you a Bat Phone to key decision makers and thought leaders with cash, always a good audience to cultivate.

2. Set expectations up front on how and when you'll communicate with sales - if you do training, if you write collateral, if you do customer visits to review roadmaps, whatever you do, set these expectations up front and stick to them. Ad hoc or unnecessarily frequent meetings too far in advance of a launch can confuse your message and diminish your credibility. Keep it simple, keep it focused, and you'll keep their attention.

3. Be the voice of the customer - more than anything, you need to understand the needs of the customer and translate them into solution capabilities. If you give up this responsibility and depend on sales to tell you what the market needs, you will live to regret it.

4. Publish and maintain a high-level roadmap on a fixed schedule - if sales knows they can go to a certain place on your intranet to find out what's in the queue and where it is in development, they won't need to ask you for it. And every rep will get the same answer. And every rep will understand how and when they can provide feedback to you regarding candidates for the roadmap. Leave out details - those require an NDA. And at some shops, communicating any roadmap information or futures of any sort requires an NDA, so be careful with this one.

As I said, there are those who keep sales in the dark. But I believe that sales works better when they can communicate a coherent, believable and reliable vision to the customer. It's your job to make sure that happens.

UPDATE - Regarding "being coin-operated" - it goes without saying (which is why I didn't say it) that prospects with cash who are interested in capabilities you are planning on developing can have a real impact on your roadmap. Think of their cash as a vehicle to help you set priorities. Just so long as you are talking about features that are still a little ways off - far enough off that you can schedule them without trashing your current devqueue - a salesperson's coin-operated inner nature can help you a lot and make you look like a hero.


Anonymous said...

Hi Bob,

I'm the clown (yes, I believe I am one too!) who posed the question, and I wanted to thank you for that great answer of yours!

It's exactly the kind of answer I was looking for!

I also wanted to ask you to define NDA for me as I don't know what it means (English is not my native language, and I'm not always aware of all the acronyms)

bob said...

NDA = Non-disclosure agreement

Thanks for the kind words, both here and on aagpm!

Camie Vog said...

Can I have the addy to your "other" blog?