As indicated, you need a way to manage game states. A game state represents a given "phase" of the game's execution: playing the intro video/splash screens for one, displaying and interacting with the opening menu, playing the game. Each of these states includes their own code/data for doing what they do. States typically encapsulate a set of input/update/render operations. (Though some state management can get more difficult than that, it amounts to about the same idea.)

A commonly-used paradigm is that the update routine of a given state, when called, will return a pointer to the state that should be executing next.

Consider the following rough interface for a game state:

class BaseState
{
	public:
	virtual ~BaseState();
	
	BaseState *update(float dt)=0;
	BaseState *handleInput()=0;
	void render()=0;
	bool shouldExit()=0;

};

Any given game state would derive from this interface and implement update, handleInput and render. In the case of intro/splash stuff, the update method would advance the movies, advance timers on the splash screen, or whatever; render would draw the image, and handleInput would listen for Escape or other keys that can be used to early-cancel the splash and dump you to menu. Either of update or handleInput can return a new state. In the case of the splash state, update would return a pointer to a new instance of a MainMenu state as soon as the internal timer runs down to 0 (meaning the splash sequence is ended). handleInput would return a pointer to a new instance of a MainMenu state whenever it indicates that a key press is received to cancel the splash sequence.

Similarly, the MainMenu state would implement its own versions of those three methods. Update wouldn't really do a whole lot, since there isn't much in the way of action going on in a main menu. Update some animations if you have an animated scene for your background. Update some particle effects, whatever. render, of course, would draw the menu. handleInput would listen for mouse clicks, and pass appropriate input to the various UI widgets comprising the main menu and any associated sub-menus or screens. The Start Game menu button (or equivalent) would be attached to a process that would, when clicked and handled in handleInput, construct a new Game state. The Exit Game button would similarly construct an ExitGame state that would shut down all systems and terminate the loop.

And so on.

At the heart of the system is your game loop which operates something like this:

void loop(BaseState *startingstate)
	BaseState *currentstate=startingstate;
	Timer timer;
	
	if(!currentstate) return;
	
	float currenttime=timer.getCurrentTime();
	float elapsedtime=0;
	while(currentstate && !currentstate->shouldExit())
	{
		BaseState *newstate=currentstate->update(elapsedtime);
		if(newstate) currentstate=newstate;
		
		newstate=currentstate->handleInput();
		if(newstate) currentstate=newstate;
		
		currentstate->render();
		
		float nexttime=timer.getCurrentTime();
		elapsedtime=nexttime-currenttime;
		currenttime=nexttime;
	}
}

It's rough, but that's the gist of it. The loop just executes until it's told to stop, and each time through it calls update and handleInput on the current state. If those methods indicate that the state needs to change (a button was pressed, a timer ran out, whatever) then they will return a pointer to the state that should be executing next. Otherwise, they return 0.

After that, it's really just a simple matter of implementing your handleInput, render, update, and shouldExit methods appropriately for the state they represent.