Better Product Managers, and Product Management

The best laid schemes of product managers and sales
Go often askew,
And leaves us nothing but grief and pain,
For promised impressive product forecasts!

With apologies to Robert Burns, I’ve seen a lot of product forecasts go askew, even for fairly mature product/market matches.

The forecasts seemed to have a strong foundation – take data-backed estimates of the addressable and attainable market size, then chop off a good chunk to be conservative.  Working with sales to get their estimate of what they can sell, then chop off a good chunk of that to be conservative.  Make sure that there’s nothing blocking engineering from meeting demand.

And yet, six months later, the actual numbers fall far short of even the conservative plan.

Why?  Because forecasting isn’t all about you and your company.

Even if your product is effective, priced appropriately, and solves a problem for your customer, that doesn’t guarantee a sale.

There are 5 strong decision points that happen on the customer side.  Some of these you can influence; some you just have to plan around.

What’s more important than this product?

Years ago, the Sarbanes-Oxley Act introduced huge delays into the sales of the products I was working with then.  The conversation went something like, “will you help us be SOX-compliant? no, you’re completely unrelated? OK, we’ll get back to you next year.”  This works both ways – I also saw customers speed up purchases and upgrades when we were able to help them achieve ADA/accessibility compliance.  When legal or IT compliance issues arise, customers will have tunnel vision and only see the vendors/products that help them settle those issues.

Product Manager: It’s probably not in your control to make your product help with whatever the critical issue of the moment is, but you can plan for how it will speed or slow adoption.

Whose budget does it come out of?

Is there a clear division owner who will be paying for this product?  If the benefits of your product span multiple divisions within a company, that seems like it would be an objectively good thing, right?   But more than likely, it creates tension over who pays for it and slows down your sales process.

Does their budget have enough “liquidity” to make this purchase?  The division you’re selling into may have a large budget … that has already been allocated to fixed expenses.   It’s not uncommon to see companies spending tens of thousands on contractors but be unable to justify spending half that amount on software.

Product Manager: Understand how your customers’ budgets work.  If there’s a way to restructure pricing to make it easier for them to get a check signed, explore those options.  If there’s a way to more clearly target a single division, do it.

How long will this take to deploy? / How long until we see results?

Like you, your customers have goals and objectives that they are evaluated on.  It’s in their best interest to prioritize projects that they can complete and show success on in time for their performance review.  If it’s unclear that your product will be deployed in that time period, you become a less attractive option to back.

Product Manager: Identify the variables that affect deployment time. Look for places where your company can offer services to shorten that time.  Explore incentives or a guarantee if certain parts of the deployment exceed X period of time.

Who else is using this? What results have they seen?

Assuming you have beta customers, has enough time elapsed for them to see results yet?  Most companies aren’t ready to make a change until they’ve seen it work for someone else.   You may have deployed the product with Beta Customer X, but have they seen results yet?  Cost-saving and time-saving products in particular may require a few months’ ramp-up before the savings are obvious.

You can’t assume that Beta Customer X is a reference customer as soon as their software is deployed; you have to wait until the results are in.

Product Manager: Plan for a delay if it will take 3 months for Beta Customer X to show those awesome cost-savings.  Look for ways to accelerate the time between installation and results.

When is our next upgrade planned for?

At larger companies, planned upgrades are rare and set in stone.  Many of the customers I worked with at Yodlee had 1-2 upgrade releases per year.  If you missed the window, you were on ice for another six months, regardless of how awesome your product was.

Upgrade cycles are getting shorter, thankfully.  But smaller companies who upgrade more frequently are also more likely to constrain the size of each release.  This puts you back to the first question, What’s more important than this product? You may still be in a queue.

Product Manager: Know your customers’ upgrade cycles.  Know their release sizes.  If your product is larger than what they’re comfortable they’re comfortable releasing, find a way to break it up into pieces.  If your customer isn’t going to release for another five months, look for ways that you can help them prepare (training, data migration, etc.) so that you’re set when the time comes.

Popularity: 1% [?]

Popularity: 1% [?] blog comments powered by Disqus