Remember the good ole’ days, the days of the dot.coms? People didn’t just build software. They set out to build the best transformational software ever.

Development groups held meetings that never had action items and talked excitedly about how they were going to apply cutting edge technologies. They didn’t plan to upgrade the existing software (when there was any existing software). They planned to tear up the code and throw it in the trash, and replace it with a whole new set of code, built from the ground up to be technically awesome.

And it all was going to take two years, at least, but you could be sure they were going to do it right!

But the luckiest programmer of all was the one whose project was officially designated “Research”. He got to sit in an office by himself all day, and work without deadlines. His project was to build a user interface that took the form of a life-size hologram of Princess Leia, who functioned using self-learning neural-networked artificial intelligence with fuzzy logic and speech recognition.

Imagine how amazed the market for warehouse software was going to be when all inventory transfers could be conducted by speaking to Princess Leia, who would carry out your commands, and even supply helpful recommendations on how you could work more efficiently.

(Like I really want to hear yet another opinion about how I should do my job!)

Well, that was a time when the rallying cry could easily have been “Reality be damned!” But reality reared its ugly head, and here’s the reality for software companies of all sizes, just like it was long before the dot.coms:

It’s hard, hard work to improve your product. And your first priority is to make sure you bring enough money in through new sales and maintenance fees to keep afloat. That means that many times, your company must dedicate its resources to whatever it has successfully sold. Some of those great ideas are going to have to wait.

Yes, if you did things differently, you’d be better off in the long term. But there isn’t going to be a long term if you don’t survive in the short term.

And that means doing whatever you can sell.

But this leads to a product direction that wanders all over the map, including one-off cul-de-sacs and reversals of direction. It’s an unfortunate but necessary situation.

So what can a Product Manager do to shepherd the product towards improvements that continue to push it in the best direction long-term, when it’s vital to build based on the short term? Read on for some ideas.