1

I have been asked to give a 45 minute talk on my team's system architecture to an incoming product manager (PM). Well, this PM's "mentor" highly recommended asking for one.

I'm comfortable giving this talk to a room of engineers—we use gRPC, microservices, GCP—we own some of the source of truth in a Postgres database, while the rest resides in a third-party source we acquired but we abstract that away, interfacing with that data via a GraphQL API—we are the upstream to a public API layer, etc. But I'm not sure what aspects of this are relevant to a PM (or indirectly relevant to their growth as a PM-in-training). We are a tech company, so PMs are expected to be at least somewhat technical.

Are things like "source of truth" and "ownership" relevant to a PM? Or, would it be more useful for me to roughly map out what "systems" are related to what "features" and then what teams own those systems or features? Or do I talk about why making changes to our public API can take a long time (and so we need to frontload that work in any project)? I'm even thinking about ditching system architecture altogether and sharing stories about projects that went wrong and why (based on our retros). But that's what made me think—Do I even understand what about system architecture is important to a PM? Maybe I should treat this more like I am giving the talk to an engineer? (Because maybe PMs need to learn to follow to technical discussions to some level, and this is an exercise?)

I don't know the PM's mentor (or if they even work in my company), and I kind of feel like if I ask, "What would you like to learn from this?", they likely won't really know themselves—they're new to the field I believe. So, to the Product-leaning software engineers or those who've even dabbled in Product—any advice on what to drop and what to share, that would help a budding PM the most?

1
  • Even if you think "What would you like to learn from this?" is the wrong question, you can always ask "What do you already know about our product?" and "At what technical level would you like to have this talk?".
    – Doc Brown
    Commented Mar 13 at 17:05

3 Answers 3

3

The rough map of what "systems" there are, how the features are allocated and which systems interact with each other would be valuable information for a PM to understand what the larger system does.

That some data is owned by us and that we are the source of truth for that data and that other data is retrieved from a third-party is also relevant information, but that you use a Postgres database is not. To give you an idea of what level of abstraction is likely expected.

If you have time left in you 45 minute timeslot after explaining how the system looks like and what it does, you can certainly add some extras about process "deficiencies" that would affect the PM's work, like why public API changes need to be frontloaded.

Also, don't just take our advise. If there are existing PMs in your company, ask them exactly the question you posted here. They should be in the best position to know what level of detail is relevant for their work.

2

You need to ask the organizer of the meeting what the purpose of the meeting is, and tailor your presentation to the focus at hand. That may sound like an obvious answer but you need to dig deeper than you currently have on understanding what the PM is hoping to get out of it.

  • Are they trying to understand your specific tech stack because they have some technical experience?
  • Are they looking for a high level overview to understand the main components that make up your ecosystem?
  • Are they looking for ongoing issues to identify work for the near future?
  • Are they vetting that your overall architecture is well-researched?
  • Are they looking for vulnerabilities or gaps in the current ecosystem?
  • Are they trying to build up an understanding of how the dev team should interact with the support and product teams, to better understand the current separation of roles and responsibilities?

Each of these would yield a significantly different presentation. I can't tell you what was in the mind of the organizer of the meeting, you should ask them.

1

"source of truth" and "ownership"

we own

we acquired

we abstract

we are the upstream

Those are cues about the culture built around the product, they are syntactic sugar, at best they could be the architectural view of the culture.

From an actor with a shallow product management experience a relevant presentation could include: the audience profile, the information flow through the application, the automated and the manual transformation of the information (what modules are performing it, what actors have acces to the modules).

...or maybe have a feel of arch42 that is a template for architecture communication and documentation recommending...

  1. Introduction and Goals
    Short description of the requirements, driving forces, extract (or abstract) of requirements. Top three (max five) quality goals for the architecture which have highest priority for the major stakeholders. A table of important stakeholders with their expectation regarding architecture.
  1. Constraints
    Anything that constrains teams in design and implementation decisions or decision about related processes. Can sometimes go beyond individual systems and are valid for whole organizations and companies.
  1. Context and Scope
    Delimits your system from its (external) communication partners (neighboring systems and users). Specifies the external interfaces. Shown from a business/domain perspective (always) or a technical perspective (optional)
  1. Solution Strategy
    Summary of the fundamental decisions and solution strategies that shape the architecture. Can include technology, top-level decomposition, approaches to achieve top quality goals and relevant organizational decisions.
  1. Building Block View
    Static decomposition of the system, abstractions of source-code, shown as hierarchy of white boxes (containing black boxes), up to the appropriate level of detail.
  1. Runtime View
    Behavior of building blocks as scenarios, covering important use cases or features, interactions at critical external interfaces, operation and administration plus error and exception behavior.
  1. Deployment View
    Technical infrastructure with environments, computers, processors, topologies. Mapping of (software) building blocks to infrastructure elements.
  1. Crosscutting Concepts
    Overall, principal regulations and solution approaches relevant in multiple parts (→ cross-cutting) of the system. Concepts are often related to multiple building blocks. Include different topics like domain models, architecture patterns and -styles, rules for using specific technology and implementation rules.
  1. Architectural Decisions
    Important, expensive, critical, large scale or risky architecture decisions including rationales.
  1. Quality Requirements
    Quality requirements as scenarios, with quality tree to provide high-level overview.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.