First, it's useful to distinguish between Technical PROGRAM Manager (TPROG) from Technical PROJECT manager (TPROJ). TPROGs are a bridge between inside teams and the outside, including customers and partners. The TPROG works with developers, DevOps, product managers, sales to bring the company's solutions to real world deployment. TPROGs own delivery of products and services to customers, possibly, through partners, using people and resources not directly under their control. Key skills: deep technical knowledge of the product and its deployment to the customer, close working with the customer about what they need by when, trust of the internal business and technical teams, even though, typically, TPROGs don't have administrative authority for a the teams, ability to write and implement governance policies to guide all stakeholders in the the successful delivery.
TPROJs, on the other hand, are usually part of the development team and manage completion of development projects. This usually has deep responsibilities for the technical aspects of products.
Each company has their own unique definition of these roles, so you need to understand exactly your responsibilities and the metrics by which your performance will be evaluated in the particular situation.
If the TPROG role is defined as above, you will NOT have direct responsibility for coding and software development. But remaining abreast of the internal structure of the product or service will be a huge advantage. But you will be too busy with all of the complex challenges of product delivery to have any time for coding.
I hope this helps a little...
My first advice is that you should consider pricing mechanics as secondary. The primary issue is business model; whether and how you can work in the very different worlds at the same time. You need to sort through the issues carefully. The SaaS model is very different from the more traditional license-based software offers. I won't repeat the abundance of thinking on this here other than to say that (a) metrics you use to measure and guide your success for the SaaS offering are very different from what you will need for a license model, (b) the deployment model for SaaS is very different from source-based licenses. For SaaS, you have complete control over your code base, how and when to issue revisions to your cloud-based services. You have zero control over the source distribution, (c) product support processes are very different between the models, because in the source code model you need to understand the customer's code too! etc., etc...
Let me suggest that you DO NOT offer the source license model alongside of your SaaS subscription model. They are different enough to make it very hard to manage the baseline jointly for both offers. And, the significant additional complication of source-based licensing will make it nearly impossible to manage together. I think this "opportunity" is a sure way to kill your SaaS company.
Rather, you can consider for the particular customer a ONE-TIME SOURCE CODE LICENSING deal, where you sell the source as-is. To make is easier for the customer you can provide some nice documentation on internal frameworks and interfaces. Make sure that you write careful language in the contract to ensure that the customer will not compete with you in your primary business areas (this may not be trivial). Pricing must have NO RELATIONSHIP whatsoever with your SaaS pricing model. It should be based on value of the solution to the particular customer. Once you have this number, double it. Then include pricing for 1 year support (with some bounds, e.g., not more than, say, 10 hours per month) for a fixed fee and an option for the customer to buy additional support for $$ per hour beyond the built-in 10 hours.
If you want to eat Indian food, don't go to an Italian restaurant.
good luck
How about if we insist that all browsers force ALL embedded videos (including ADs) to be by default autoplay=off. So we don't suffer page load delays for video content and hidden cost of background buffering? We are paying our ISP for these usually unwanted bytes.