Technically, it doesn't matter.
Look at Netflix. How many products do you see? Only one. And yet, Netflix is a conglomerate of dozens of services which can be developed and deployed independently, using an independent technology stack.
Now look at a random SquareSpace website. And then pick another one. They may have nothing in common. Two different products, using two different sets of features. And still, the underlying programming code is the same for both.
So if the question is not technical, what is it, and, more importantly, who decides?
The actual point is how do you present your product to a customer. It may make sense to present a series of features as a single product. Or it may be more useful to present the system as multiple products.
Take Microsoft Office. Shared code (except Excel), multiple products. You have PowerPoint, and you have Word, not because it would be technically impossible to combine both features of a text editor and a presentation editor into one software product, but rather because users wouldn't understand how to use such product (according to Microsoft).
Now consider Visual Studio. If I write C# code for server applications, and that's all I do, I don't really care about Visual Basic or F# or C++. And I don't even care about Silverlight or WPF or Windows Forms. Nevertheless, it's all in Visual Studio, in a form of features. All in one place. An interesting point is that it wasn't always like this. In the nineties, you had to install different IDEs for different languages: if you used two languages, you ended up with both Microsoft Visual Basic and Microsoft Visual C++ applications on your machine.
Therefore, the decision belongs exclusively to marketing. Once the decision is made, it's up to you to develop the software product in a way that ensures enough cohesion between the parts of the system and avoids code duplication.