Should the product team get involved in shaping technical architecture?
In general, Product Managers (PMs) should not get too involved in making technical design decisions.
Instead, product managers can contribute by facilitating a conversation with engineering and engineering leadership around the following topics:
Principles
The PM would list the key non-functional requirements for the product. Each might imply a certain technical choice or approach. For example:
a) It must be possible for different teams and engineers to work on various parts of the system independently. This might imply a clear separation of concerns between various parts of the system.
b) We want to invent as little as possible. Instead, we want to prioritize time to market. This might imply the use of off-the-shelf cloud services or open source wherever possible.
c) We want to be able to hire from a large pool of engineers who have experience with our tech stack. Which might imply the use of popular tools rather than new, experimental tech.
d) We should know the moment something breaks or does not function as expected. Which might imply automated testing and alerting for every component.
Visibility
The PM should sit with the engineering team and walk them through the roadmap. While doing so, they should pay special attention to patterns that might repeat or features/requirements that may need to expand over time.
For example: "This concept of transforming data from X to Y happens a lot. You can see it here, here and here." or "Being able to connect to this address book for a list of user contacts is just the beginning. Over time we will want to give the user the option to connect to a wide range of 3rd party address books"
The former implies that a particular component might be generalized to handle lots of data transformations across the system. The latter implies that the address book importer will ultimately need to be designed to support multiple connectors and data types.
Time
Give engineers the time they need to do thoughtful technical designs, reviews and builds so that they can make more durable medium-term decisions. If everything is an emergency -working to a hard deadline - engineers will cut corners to get the job done for you.
Engineering reviews
Encourage the engineering team to have technical design review meetings with each other to pressure test proposed design decisions against the principles and roadmap.
Permission to refactor
Finally, remember it’s ok for engineering to refactor code later. Particularly early in a startups life where product-market fit is still a challenge. If they are not building just enough to make the user experience work well, then they risk over-engineering the solution and getting stuck building things for far too long instead of shipping new value to the market and iterating.
Collectively, this will all help the engineering team make great decisions without the product team getting too prescriptive. It will also help the engineering team avoid over-building sophisticated things that no one will use.