I was in a board meeting last week reviewing a product release schedule for the next year. I was extremely concerned that we missed the last release, and as we dug in deeper what we saw were a few features scattered throughout the schedule tied to deals that were just closed. Now this would not be a big deal if these requirements were market-driven features that were necessary for a number of customers. However, the big concern was that most of these requirements were one-off features for specific customers that were just closed in the earlier quarter. So while engineering missed the release date for the product and should be held accountable, this analysis points to a much deeper issue and is a great example of how all of the various groups and functions in a company need to work together as a team.
My first thought was that if we continued on this path we would never have a product that met market needs. There would be no way that the engineering team could execute against its development schedule with a number of one-off requests. So we asked management to analyze the problem and report back to the board. The first place to look was product management to determine whether these customer requirements were one-off adjustments or features that were significant market needs that product management did not identify. The other place to look was sales to determine if sales reps were selling what we didn’t have and promising the world to close deals. As you may know, a healthy tension between sales and product management will always exist. Sales will always want any and every feature to close that big deal and product management should only want features that will address broader market needs.
After a week, management reported back to the board and determined that the problem eminated from sales. More specifically, it was pretty clear that the sales reps were not properly trained or equipped to sell the product. When not armed with the knowledge and sales tools to properly sell, it was quite easy for the reps to get derailed during sales presentations, flail when addressing customer objections to the product, and agree to add one-off features to close a deal. To address this problem, management presented a plan to get the sales reps properly trained, equipped, and managed. In addition, management would have to play an ongoing role stressing the importance of closing the right deals and walking away from the wrong deals. So the next time engineering misses a release date, make sure you understand why because most likely it is a symptom of a much larger problem.
Well that sounds like a report from our early (venture-driven) times. 😉
However, the big question is: Does product management really know the “broader market needs”? Or do they stew in their own juice?
Finaly the success of any product determines from how good you target the market needs. From my experience, nobody is closer to the understanding of market needs than those fellows, who have to implement solutions in the customer field. Unfortunately they often have to take the can for the tension between product management and sales.
Great analysis by your board. I wonder if there is too serious a divide between sales and product teams here…I’ve found that strong technical salespeople with solid links to both sales and engineering makes all the difference here…Great salespeople and great engineering teams still operate too differently to play well together without strong links.
Allllright! Ed’s back.
Hi there (wave). Great post!
Oh, the startups I’ve seen.
I’m impressed that such insight reached up to board level. In my experience such insight hardly ever reaches above the VP of Engineering level (if that), and the higher ups are scared of bringing those problems to the board.
Another factor, though, is that often in a start up the sales guys are in a position of selling something that demos well but it isn’t a “whole product” leading to them having invent or promise features to make a sale.
Then you get the death spiral swirling so fast you need a complete strategic realignment (often precipitated by a major product release failure), or you end up (if your are lucky) in CustomWare (see Joel on Software http://www.joelonsoftware.com/items/2005/10/12.html ).
The solution: whole company focus on very iterative development in the early days, with clearly separated custom development (aka Applications/Post Sales Engineering) as the company matures. And *every one* has to be drinking that Kool-Aid.
Chris-I can feel your pain and I agree with your points