Striking a balance between sales feature demands and product development

One of the biggest frustrations product guys have is other teams lobbying to prioritise product features outside of the critical path. If you’ve ever seen product guys in the zone, you’d think they were planning a colony on the moon… and with good cause, developing a product isn’t as simple and fitting together lego pieces, it required an expansive understanding of how each component fits with the wider architecture of the product.

On the flip, its also common that sales guys will get frustrated that the product their selling isn’t all-encompassing enough, lacking in certain features that might result in a sale being missed.

So, how do you reconcile? the reality is, more often than not, the sporadic requests from sales, are likely to be low in priority or distractions to the core product, but, conversely, the revenue of these sales might be too large to ignore. so, how do you find a path through two opposing points of view.

Ray Dalio – “you can have anything you want, but not everything you want”

This quote is one of my favourites, it highlights the concept of opportunity cost explicitly. And the reality is that the choice of what to build and which sales to close is an opportunity cost consideration.

In product we have a simple framework called ICE – impact, Confidence, Ease – which is a quick ranking system to help prioritise features in a backlog. Obviously we focus on the ones that have the largest impact, we have the most confidence in and will find the easiest to do. The problem with this framework however, is only product guys use it. but the fact is that all parts of the organisation who wish to impact product should be adhering to the same frame work, they have an obligation to use the same framework to help support and justify the request they have. The framework emphasises the opportunity cost considerations of the feature requests.

We now need to dig in deeper, ICE are nice concepts, but scoring on a scale of 1-10 is subjective at best, and inconsistent, so rather than simply putting a biased number, instead the emphasis is on the submitter to find evidence to show Impact, Confidence or Ease.

so how does this look for they dynamic between sales and product? if Sales wants to fast track a new feature, they need to find evidence of the impact – such as letters of intent, commercial impact/value; This should also be based on confirmed data rather than wishful thinking, if you want Feature X to be build, show me Letters of intent from a number of companies and how much they are willing to pay for this feature, how much they are willing to pay is important since, that revenue can be balanced against the ‘Ease’. Ease is a function of time, since the harder something is to build, the more time-cost it will take, therefore the more revenue impact is required to justify the production of that feature.

Here’s how it looks in practice – sales guy wants a new feature made, the product guys review it and its hard to do, but they’re sure that if they do build it, it’ll be useable over several clients not just one. so the trade off is the cost of the initial development versus how much new business this feature would bring in. So the sales guy needs to find some assurances that a minimum number of clients generating a minimum target revenue (based on the production cost) can be achieved, before feature will be fast tracked.

Leave a Reply

Your email address will not be published. Required fields are marked *