Getting to 'No'

Getting to 'No'

After 12 years spent as a Product Manager working for Enterprise Software, Startups, blue-chip retailers and financial services companies and advising many more, I have been able to boil it all down to one key skill - the ability to say 'No'. This post explains why 'No' is the one word that product managers need to be able to say with authority and comfort knowing that it will be well received (October 2011)

My ultimate objective as a product manager has always been to marry up the capabilities and capacity of the product organization with the needs and schedule of the clients and prospects - and to do so profitably for the company.

If the Product(s) that I manage had a good degree of fit with the most pertinent needs of a valuable segment of the market - and we were able to deliver and position a competitive product, then we stood a good chance of growing profitable revenues. But the trick to this is the ability to say 'No'. No to customers when they asked for additional functionality. No to engineering when they didn't want to do something a certain way. No to sales and marketing when they wanted more features. But the real trick is to be able to say 'No' and have the person you say it to, leave happy.

Saying "No" to Customers

Putting my customer hat on, if I am buying packaged software, what I am looking for is software that will closely fit my business processes, ideally with zero customization. One could argue that sufficient customization to provide competitive advantage would be okay, but as long as it was cheaper to customize than to build a whole custom product.

Now putting my product manager hat back on, I'd like to build software that closely matches the needs of each and every customer - like a custom build, but if I build it for a single customer then my entire engineering effort is focused on that customer - and the software will end up too expensive for one customer and too niche to be profitable. So I choose to spread the cost over a number of customers with a similar need. My job as a product manager is to determine the common set of needs and build for a group of customers - and to do so, I need to position the product functionality somewhere at the center of the different needs (e.g. one customer wants a full Authentication and Authorization system and another customer is happy with a Facebook Connect sign-in - so I need to create a system that supports both options)

To now allow me to serve the slightly different needs of those customers with a single product, I can now get 'closer' to their needs with a generic product by adding a number of layers. These layers would range from business consulting services and app-exchanges to configuration options and APIs. Which means that I need to consider 'whole product' and determine what the boundaries of the layers are. For instance at what level in the product should I build APIs? If it is too low, then I have a set of services that need to be consumed by my internal teams, so although this service oriented architecture provides flexibility, it also comes at the price of efficiency.

I have been in Customer Advisor Meetings where a single but very strategic customer asked for functionality that nobody else needed - my response to that customer was that yes of course we could build it, but it would come at the expense of the other functions that all customers were asking for - and if we built his unique feature, then it would affect my sales revenues and in the next cycle I would get less budget to develop this product. It was easy to see why that customer should take their unique requirement and have it built as a customization - my action would be to put in place the infrastructure that allowed that customization to be functional and affordable. Happy Customer.

Saying "No" to Engineering

I take pride in protecting engineering from customers - without a product manager in place engineering would be inundated with seemingly high priority requests from customers or internal sources like support and marketing and they would quickly spin themselves into failure. But on the other hand when building software, there will always be more work than the Engineering department can handle - so Engineering will try to push back on features or to hardwire things rather than creating flexible services or customization options - just to meet their delivery targets with a limited capacity. So how do you say 'No' when Engineering wants to delivery something less extensible but faster?

If the objective is to build the most profitable / strategic product, then we need to invest a limited amount of engineering resources to deliver the maximum benefit to the customer group. I find I get the best results if the Engineering team or at least the Engineering management is involved in that prioritization process - and the most effective way of doing this I have found to be a project backlog and in particular the line in the middle that divides up the features that are 'in' from the features that are 'out'

Customers, Support, Operations, Product Marketing will all be feeding the list of requests with what they want. The Product Manager will also have their own vision and Engineering will want to add various re-factoring or housekeeping tasks. The tasks must be ranked based on Level of Benefit, Level of Effort and Strategic Importance - and qualitative scoring is a good way of leveling out opinions to arrive at a hard prioritization that everyone can agree upon. Engineering will then deliver a resource availability number for the release and this will determine where the in-scope line gets drawn. It is now Product Management's job to make sure that the line is a strong one and for every feature that is added to scope, another is removed. Now Engineering will value you as a protector.

But however good the estimating process is, I guarantee that there will be unforeseen complications or feature additions that will threaten to increase the Engineering resource requirements - that's just the nature of software - it's 'soft'. Here is where a hands-on relationship with the engineers is required during the design stage and the best way of doing that is for the product manager to work hand-in-hand with the engineering team as they write up the product specifications. If the product specifications are written up and the engineering team is able to steer those specifications based on the feasibility or difficulty of engineering a feature, the level of effort required will be more predictable and the specification can be QA'ed - a far cheaper place to find a bug in the system.

If during this joint requirements specification - engineering design phase there is a trade-off to be made, it's stops being a question of saying "No" to Engineering but rather a shared exercise in discovering a workable solution that will allow the engineers to deliver the most appropriate feature for the product. This has often resulted in rewriting the requirement for a simpler but more extensible function or going back to the customer and working around the problem or even splitting the feature delivery across multiple releases. All different solutions to the original problem, but equally effective in achieving the objectives for the product. Happy Engineering.

Saying "No" to Sales and Marketing

How many times have I heard "If we can just have this one feature, we'd be competitive and could win this deal" or "The Gartner analyst says that if we don't have this, we will not make the top-right quadrant". Feature blackmail. From a Sales or Marketing person's perspective, they are absolutely right and it's their job to make those demands. But from an organizational point of view, from a product profitability perspective and as a effective product manager, most of the time the answer should be "No" - lest you end up with a bundle of tactical features rather than a product.

We're on a ship, bound for a destination - this is the product strategy heading towards a market. On the voyage there will be islands of opportunity, but if we keep steering the ship to visit every island, we will never reach our destination. I guarantee that a long the way there will be some very big (i.e. profitable) islands that a salesperson may be able to convince the CEO that they are worth visiting, but if you concede to that, then you throw the whole product strategy out of the window. However, if the VP of Sales and the VP of Marketing were involved and take ownership of the Product Strategy as the best way to profit in the long-term, then these tangential excursions can be avoided. The "No" to the Salesforce will come from the head of Sales. The "No" to marketing will come from the CMO. If between them they decide that the excursion is worthwhile, then this will cause a revisit of the roadmap and presumably their own budgets and revenue targets.

A way around this, to continue the metaphor, would be to send out supply boats to visit the island and return - that do not take the ship off-course. This is to create additional modules that clients would pay for or that would use additional partner or marketing funding to develop. Instances where I have seen this done successfully are functions that a particular vertical segment require uniquely being funded and perhaps even resourced by channel partners in the specific segment. If you as a product manager hold your ground on the Product Roadmap there are other creative ways of delivering such requirements with Sales and Marketing. Happy Stakeholders.

Conclusions

There are of course many other skills required for successful Product Management as can be found by following the links below, but for me, the ability to say "No" authoritatively and with a well reasoned argument remains the best encapsulation of the skills required by a product manager - namely to be Strategic, Detail Orientated, Customer Centric, Collaborative and above all to be an effective Communicator.

What I read: