Product Team Structure

The best scaling approach is to get Scrum right at a single team level, and to avoid any need to scale as much as possible. It's better to descale the challenge so work can be done by single Scrum Teams.

Why not take this opportunity, in your start-up, to get Scrum right from the very beginning? For example, instead of having so-called "product managers" "playing" the role of a Product Owner, why not genuinely have PO's in the first place?

What is the best framework for scaling Scrum in your opinion? We would like to use something really simple if possible.

In my opinion, or a small organization with few products the best framework for scaling Scrum is none.  Two teams does not equate to scaling Scrum.  Especially if they are working on different products. I also am curious why it is your decision whether to split the development team. Have you asked the development team if they have opinions on how to organize in order to support 2 products? Introducing the overhead associated to scaling isn't needed in small organizations of the size you describe. In fact, I don't think scaling is necessary in organizations 4 times your size. It may be but that is dependent on the organization. 

What should be the role of the product lead in a company? How should this person manage other product managers? What is the best approach here?

The role is not to manage the product managers but to enable them.  Let them do the job you have hired them to do and support them in any way they need to do so.  Respect their decisions, encourage them to take risks, teach them to continuously inspect and adapt their plans based on information as it arrives. 

What is the best way to start a new product team? Hiring a new product manager and then creating a dedicated dev. team for him to work with?

Clearly define the problem space that all of these people will be working.  Hire someone that can be trusted to own the work to clarify the problem space to the rest of the organization. Let the existing development team determine how to organize in a manner that will support more than one product backlog.  Let them decide if more people are needed and who those people are.  Let them decide how to organize the skills they have available in a manner that will maximize the value that they can provide.

I think you see my main line of thinking.  Don't decide anything.  Define the problems that need to be addressed and then rely on the people that do the work to determine the tactics needed to address the problems. 

I'd generally agree with the other advice given above.

If you have two different products, you won't be scaling Scrum. Scaling Scrum usually refers to multiple teams working on a single product, usually with a single Product Backlog. If you have two products and one team per product, you simply have two Scrum Teams. Unless you have a portfolio of two or more closely related products that, for one reason or another, need to have some kind of coordination between how they are built, tested, and deployed, don't introduce unnecessary dependencies.

From this, it seems to follow that you may not need a "product lead". Perhaps there needs to be someone with managerial oversight over one or both of the Product Owners to account for things like performance evaluations and career development, but this wouldn't indicate product leadership, but personnel management. I don't think you'll find guidance from software or product development frameworks on how to manage people.

As far as staffing a team, there are different ways to go about it. However, if you do split the development team, you'll be changing the team dynamics. This will have a noticeable impact on their way of working. I would favor self-organization and letting the teams themselves figure out how to split themselves up. If the only role you are missing is a Product Owner, then you would hire a Product Owner and let the team figure out how to self organize around the two products that you have.