Never said "and". I agree that guest can be worker or manager and it's already a big advantage differenciating the two.
The game is in a very early stage and at this stage it must not be an excel sheet. Balancing a game must be done at the final stage of a development, when all features are determined and working, not so early.
For example, if you consider that there are workers giving some production and managers boosting this production it's just variables adjustement.
If at start a developper want to manage balancing when he code he will during all the dev stage run after this problem because any new feature added can break all the balance of others.
A game must alway be considered from an in-game perspective, and mainly from a "have I fun with that?" perspective, else it's no longer a game but a simulation.
First, let me clarify something. When I'm talking about balance, I'm talking about game concepts balance. Not like "workers gather 3 food/3 days". If the dev wanted to double food production, I don't really care about that. That sort of balance is small stuff that can only be judged in the end state, as you say.
What I'm really talking about are conceptual statements like "slaves and workers have the same production" or "Armor reduces damage by a flat amount" or "Armor reduces damage by a percentage". Those have much wider impacts because they directly affect how game mechanics work and how they interact with other parts of the game. As an example, the last 2 statements would impact how weapon mechanics and combat as a whole work. If armor is percentage reduction, should weapons be percentage increase to offset it? If not, how should weapons scale to keep up with armor? Or do we not care about that and let armor be way more important to combat than weapons? These are the balance questions that I'm interested in.
And the most important part of balancing this is to make sure there are no contracting concepts.
With regards to new features, there really shouldn't be any. Just planned features which have not been implemented yet. If the dev has not done so already, I would urge him (and any dev, really) to take a day or 2 or more to plan out every game mechanic they want to be in the end state of the game, and how those mechanics should interact with each other. It doesn't need to be in detail or numbers, though the general outline of formulas is important, since that will determine how different concepts interact with each other. If problems or contradictions arise from this, it's important to iron those out early on, since that's not something you can fix by simply changing numbers.