In a small software company (including SaaS/B2B but also B2C too), it's been my experience that the ideal reporting structure for the senior product person is to report directly to the CEO. Full disclosure: I'm a VP Product reporting to a CEO, so I'm a little biased. ;-)

But my favorite PM experts like the Silicon Valley Product Group seem to agree, e.g. from The VP Product Role:

Organizationally, this role typically manages the product owners/product managers and the user experience designers, and generally reports to the CEO. With some exceptions, it it is important that this role be a peer to the CTO and the VP Marketing.

Product Management is inherently a balancing act. The product needs to be something that customers want to buy, that Sales can sell, that Dev can build, that Support can support, etc. Having Product as an independent org with strong CEO support helps PM achieve that balance without one internal constituency like Sales or Engineering crowding out the voice of the customer or other internal teams.

That said, there are lots of ways to build an orgchart. Other options I've seen include:

• The most common case is when a CEO wants to delegate all product and engineering responsibility to one executive. This person is often called "VP Products" (the "s" is important!) and has both Engineering and PM reporting to them. The pros of this approach is that it insulates the product+engineering folks from the randomization that happens at the executive level. The cons depend on who the VP Products is, because it takes a special skillset to manage cross-functional teams including both product and engineering. If the manager is over-focused on engineering, then PM may not get enough attention and the company's products will suffer.
• As tech companies grow, they often don't have a single head of product. Instead, each business unit may have its own VP Product. There does seem to be a trend against this approach in today's Valley companies, however, arguing that having a shared product organization can help unify the company's products and generate cross-product synergy.
• Another case is if the executive team is much more senior than the head of product, then the CEO may not want a junior person on the executive team and/or doesn't have the time or inclination to manage that junior person. In this case, the head of product may report to VP Marketing or VP Engineering who can champion and mentor them better than the CEO can. Of course, the better approach may be to hire a more senior PM!
  
• Less commonly, the VP Marketing may have an unusually broad set of skills and can handle managing both traditional marketing (lead generation, PR, sales support, etc.) and PM (roadmap, project management, working closely with engineers) in the same org.
• In older tech companies, there was no Product org separate from Marketing. Standalone Product teams are a recent invention. In the '80s and '90s, the Product role was usually a part of Marketing, which in turn often reported into Sales & Marketing. Given the speedup in the pace of business, today's startups move faster by being more "flat", with Marketing and PM roles generally broken out and reporting to the CEO. But if the CEO or executive team came from a more traditional environment, they may be expecting the same kind of traditional structure.

I've seldom seen Product reporting into Sales, because the temperaments of great VP Sales and VP Product don't usually overlap much. They typically get along well as peers but don't have a lot to offer each other as managers.

Great sales managers are laser-focused on the *current* product and empowering the sales team. Great PMs focus on the future, on carefully building the best product that will last. But this approach is infuriating from the perspective of a VP Sales whose job is on the line if he doesn't meet this quarter's numbers. Regardless of reporting relationship, Sales will inevitably push PM into short-term, tactical work that will randomize the dev team, just like developers will push PM into letting them write better code at the expense of short-term deliverables. By having Product be peer to Engineering and Sales and Marketing, you make it more likely that those conflicting forces can be kept in balance.