I was one of the people who started and set up Sun Microsystems' first sponsored open source project, NetBeans, wrote most of its original governance rules and web site, and since have dealt with issues around open source in both corporate and startup environments, as well is open sourcing quite a bit of my own work.
It's not clear what your product is, so it's hard to say much about what the best choice is for you. Since you mention consultation and troubleshooting, I'll assume that it's either software or hardware+software.
The first thing I'd say is that you need to know *why* you're open-sourcing it. That does require some work (at a minimum you need to think carefully about choice of license, and do the due diligence to be sure you own the rights to all of it, and that your choice of license is usable in concert with the licenses of whatever open source components it uses - for example, the GPL and its variants can limit your choices).
You do not open source something thinking "I'm going to get free code out of this" because open source developers tend to scratch their own itch, and it's rare (though not impossible) that they have the same itch as you. And it has a cost in terms of the time you'll spend interacting with any development community that springs up around it.
If your product is a software product - particularly one that requires technical expertise, then it's probably quite advantageous for it to be open-source, for a number of reasons:
I wouldn't rely on the business model of "it's hard to set up and people will pay me to do it", because that suggests that the product is a little bit broken and there's space for a competitor to swoop in with a better user experience and gobble up your customers. What works for this sort of thing is a "platform play" (or "razors and blades") - where people pay for extensions to the product (your license needs to allow that), or for customizations. Would you pay for consulting to set up or troubleshoot an app on your phone? Because whatever your product is, if you want users to love it, you want the user experience of setting it up to be about as difficult as installing an app.
- Customers know if you were hit by a bus, the product doesn't go away and they can self-service to meet their needs - this is why, for example, Brazil mandates that all software used by government employees be open-source
- Expertise in the product is marketable, motivating people to learn it
- Especially if it is used by software developers or startups, and it is something you have to install on-premises, you can forget that market entirely if it is not open source - most investors strongly discourage dependence on software that has to be licensed, because it means a third-party vendor has your survival in their hands and can extort what they want once you're thoroughly dependent on it - that's how they will look at it. As a case in point, Microsoft SQL Server is a vastly better database than MySQL in just about every way, but I worked for a startup that ripped it out at the behest of their VCs.
I think with investors, it might scare away ones who don't understand open source, or think keeping things top-secret makes them more valuable (usually it makes them irrelevant). Those are not the investors you want weighing in on how you spend their money anyway, and at this point there are plenty of enlightened ones.
- Regarding the "charge for feature requests" model, I'd strongly suggest making the product a pluggable platform (if I'm understanding what the product is at all correctly), so "features" are modules that are bolted on to the core platform. You do not want every customer to have their own unique, modified version of your product - if you got successful and had a lot of customers, that would become an expensive maintenance nightmare. There are also patterns and best-practices for how to make things pluggable. It's easy to paint yourself into a corner with backward compatibility issues to the point that you can't change anything without breaking some customer's install, and there are patterns for how to avoid those kinds of problems, and not all of them are obvious (I used to train people in how to design APIs to avoid those sorts of problems when I was at Sun - if you want help with that see the contact info on my website, http://timboudreau.com ).
Be prepared for pushback from people who don't understand open source; and don't think that it's magic success-pixie-dust, because the product has to be good and have a market. But with the right business model, it can definitely be an asset, especially in a space where the competition is not open.