The plan is maybe accurate, but probably not. The act of planning is a useful time to step back, evaluate strategic position and rethink investment. Using financial targets is a mechanism. If target is thirty percent growth, does the product org have a realistic answer for how that will happen? If that answer is couched in details like “in eleven months we’ll ship the grand frobulator version 2.13.32.005”, then it’s maybe not so realistic. 

For a non-SaaS software offering it takes a quarter for product changes to affect sales numbers, and a year to know if you’re going to get renewals or just have a flash in the pan. It takes a quarter to deliver a change to an existing product. So if you have to make product changes to affect this year’s numbers and you’re just planning them now in May, you’ve got all your eggs in Q4. It’s key to realize that product time scales are very different from sales time scales. And if your team isn’t already big enough or properly skilled to deliver the features, you’re even worse off because hiring and developing engineers is even slower than making features.

Whatever plan you offer for making product in the second half of this year is setting up for next year’s sales. Why can’t you just parallelize those efforts? Well, customers are rightly suspicious of features that are planned but not shipped. The world of enterprise software sales is also still relatively small and interconnected, so your own team cares about their reputations. They won’t be happy selling unachievable sizzle ahead of today’s steak.

Software as a Service doesn’t change those dynamics as much as people might assume that it does, but it does help to smooth out a spiky cash flow. Whether you’re selling term or perm, on-prem or as a service, trying to move your current revenue numbers with expected product features is very prone to forecast failure.