Venn and the art of PM,

TPM, and SDM

Intent
PM, PM-T, SDM, and TPM are roles that intentionally overlap. We
don’t require all of them to be present to successfully deliver a
product. We also don’t want anyone to view the high level matrix or the
contents of a Role Guideline as a narrow definition of what they own. 
Given the wide variety of businesses and technologies at Amazon, no
guideline can capture all expectations. No two teams are alike and by
necessity each will develop their own approach to delighting their
customers. These realities alter the way each employee is expected to
operate and what constitutes success.
What an SDM isn’t
• PM, PM-T, and TPM influencing without authority.
• Which is another way of saying they have no direct ownership of the
teams that deliver the results they are responsible for.
What is different about a TPM
• TPMs may be assigned to own a business or technology ‘goal’
• They may be the point of contact for a business or technology
process, workflow, system that to operate crosses multiple teams or
organizations.
• TPMs are expected to optimize work. Their job is to make engineering
easier, faster, and more efficient.
• They may be accountable for product development, but only in the
context of their program goals.
 Product Development Comparison
Product Management/Development Use Cases PM PMT TPM SDM
Customer Need – Voice of the Customer (VoC). What Core Core responsibility Core responsibility Not a core
problem are we solving? Is there a market opportunity? responsibility. (for PMT product use (related to program). responsibility
How is what we want different from existing products? cases).
Where can we invent? Performs competitor analysis. Does not assess
Works with Customers and Business Development to “market opportunity”.
identify integrated product solutions.

Product Vision – PR/FAQ, feature value proposition, game- Core Core responsibility Core responsibility Core responsibility
changing ideas, evolution. Focuses on customer delight. responsibility. (for PMT product use (related to program)
Defines functional, regional, legal, compliance and other cases).
business requirements. Has OP1/OP2 input. Works with UX
on mockups.

Product Ownership – Single threaded owner for the entire Core Core responsibility Not a core Core responsibility
product. End-to-end accountability. May own Profit and responsibility. (for PMT product use responsibility. for small products.
Loss (P/L).   cases).
Overlap: SDM,   Large products may
GM, Director, etc. Overlap: SDM, GM, be owned by a
Director, etc. Director/GM, or VP
 Product Development Comparison
Product Management/Development Use Cases PM PMT TPM SDM
Product/Feature Marketing – Branding, packaging, placement, Involved in pricing, Involved in pricing, Not a core Not a core
pricing, promotions, deals. Develops business metrics (e.g., forecasting, and forecasting, and responsibility. responsibility
funnels, conversion, awareness) to increase adoption. product messaging. product messaging.
Determines degree that we are paying for customers. Product
forecasting. Creates product messaging. May extend into Marketing is a Marketing is a
product marketing, evangelism, training sales. different job. different job.

Product/Feature Roadmap – Feature priority, works with Core responsibility. Core responsibility. Utilized for Core
business entities/customers to understand compliance, legal,     products with responsibility.
internationalization, accessibility, and other ongoing needs Overlap: SDM, Overlap: SDM, significant cross-
(VoC). Helps engineering and UX design make the right CX Program Manager, Program Manager, functional dev and Overlap: SDM,
trade-offs. Involved in product launch/release. Troubleshoots TPM. TPM. engineering Program Manager,
user problems when product is in production. engagement. TPM.
Product Development Comparison
Product Management/Development Use Cases PM PMT TPM SDM

Product/Feature Technical Design – Works closely with Not a core Core responsibility. Utilized for products SDM owns (may
engineering. Weighs in on technology choices and helps responsibility. with significant delegate to TPM).
them make the right architecture trade-offs. Defines Does not write cross-functional dev
technical requirements. Builds consensus with developers Good area for PM technical and engineering
on technical approach. Can assess when on growth path to specifications. engagement.
design/implementation choices pose a risk to our ability to PMT. Conveys higher level
innovate/deliver future value. technical
requirements.

Product/Feature Build – Active involvement with Not a core Not a core Core responsibility. SDM owns (may
engineering teams as part of the development process. responsibility. responsibility.   delegate to TPM).
Manages projects, identifies and mitigates risks, clear Overlap: SDM/PMT
project blockers, holds engineering teams accountable for Has ability to assess
delivery, ensures features are tested and meet quality code.
definitions, handles releases, and post launch monitoring.

Product Maintenance – Post-launch technology needs, code Not a core Not a core Core responsibility. SDM owns, may
maintenance, service monitoring, performance, scaling, responsibility. responsibility. delegate to TPM.
availability tuning, looks for opportunities to make Utilized for products
technology components extensible, root cause resolution, PM is advised or PMT is advised or with significant Has ability to assess
responsible for dev team adherence to SLAs, drives consulted when consulted when cross-functional code.
operational excellence. launches are launches are affected. engineering
affected. engagement
Technical Bars
• Technical and/or scientific skills required to perform the job
• It’s important to remember that these are high level statements.
Interviews test the details.
• These are minimum requirements. Teams and organizations can have
higher expectations, not lower ones.
SDM and TPM Technical Bar - Overview
• Designed to assess their ability to contribute to the technical strategy for the software they create and
effectively manage the software development process.
• Need enough knowledge/experience with design approaches and industry technologies (within their
software area) to be able to ask the right technical questions and drive the right technical solution(s).
• Should be able to contribute to technical discussions and decisions – i.e., able to understand and evaluate
end-to-end system designs for strengths and weaknesses (scalability, latency, security, performance, data
integrity, etc.) as well as balance technical requirements against business requirements.
• Need enough experience to foresee the consequences of poor technology decisions to determine if the
right trade-offs are being made.
• Need to be able to recognize when the technical information they have been given is potentially
inaccurate, inflated, or not sufficiently understood. This is not as much about possessing specific skills as
it is about having sufficient technical judgment to know when a design is complex or risky enough that it
requires further evaluation from a Principal Engineer.
• Need sufficient technical credibility to be respected by the engineering teams they will work with.
• Does not need to know how to code, but some teams will require it.
PMT Technical Bar Overview
• The PMT tech bar is designed to support PMT product use cases and not overshadow their primary
job requirements which are to manage the product. These include:
• Designing the customer intake process,
• creating the product/feature vision
• business analysis (e.g., KPIs, economic modeling, forecasting, pricing, segment adoption)
• working with design teams
• ensuring product compliance
• owning the feature roadmap and launches,
• training sales/marketing.
• Many requirements for SDM and TPM apply to PMT. However, their tech bars are higher from a
software/systems design perspective to meet job requirements to work deeply with engineering
teams on the design, implementation, and to ensure technologies delivered scale and perform
appropriately end-to-end.
• SDMs and TPMs also drive operational excellence and are expected to improve engineering efficiency
by reducing dependencies and bottlenecks.
Tech Bar Comparison
Level PMT Technical Bar TPM Technical Bar SDM
L4 No PMT I (Level 4)  Has engineering background (e.g., CS, CE, or EE degree or No SDM (Level 4)
equivalent experience).
 Understands industry technologies in their domain (e.g.,
hardware, network, software) and how to apply those
technologies to solve problems (Q. What do we need to build to
achieve X?).
 Able to dive deeply into technical details (e.g., key dependencies,
design choices, operability, etc.) with engineers and drive
constructive technical discussions.
 Can transform raw thoughts into clear technical documentation
and/or direction.
 Collects data in a self-service fashion.
 Has a broad range of techniques for conducting technical analysis
and know when to use them.
Tech Bar Comparison
Level PMT Technical Bar TPM Technical Bar SDM
L5  Understands the industry technologies utilized  Understands the system architecture within  Has engineering experience.
within their product area and how to apply program or product domain. Makes sure that  Is able to understand design
those technologies to solve customer needs dependencies are not broken by development approaches within technology
 Can explain a particular technology (its benefits changes and that program systems are not domain.
and challenges) to engineers and articulate broken by upstream changes.  Is able to spot risks. Asks the
customer pain points from a technical  Considers the larger picture (e.g., efficiency, right technical questions.
perspective. availability, operability, scalability, business  Understands industry
 Able independently assess the technical goals, customer experience, etc.) Balances technologies, engineering best
feasibility of a proposed product or feature. against the needs of engineering teams who practices, and design
 Can dive deeply into technical details with have to build, maintain and extend features for approaches.
engineers and drive constructive discussions. the life of the technology.  Knows the consequences that
 Able to spot risks and ask the right technical  Sees patterns; Can make connections to can arise from poor technical
questions to ensure appropriate trade-offs are improve project/process efficiency. decisions.
made.  Discovers solutions. Knows what solutions exist  Makes trade-offs: features vs.
 Can transform raw thoughts into clear technical elsewhere and how they can be connected. resources (time) vs. quality.
documentation and/or direction.  Can convey detailed technical knowledge
 Can convey detailed technical knowledge (verbally, in writing, and via diagram) to
(verbally, in writing, and via diagram) to engineering team(s)
engineering teams and/or technical customers.  Assesses engineering practices for testing,
triage and maintenance and work with
manager(s) to establish the right methods for
effective project delivery.
Tech Bar Comparison
Level PMT Technical Bar
L6  Understands the reasons for architecture
decisions behind a product/feature
 Capable of holding an engineering team to a
high standard for product solutions. They can
recognize when the technical design of a feature
limits performance, scale, extensibility, and/or
our ability innovate in the future (similar to a
technical manager).
 Understands the impact a technical backlog has
on the future of a product and how to prioritize
operational excellence work alongside feature
delivery on product roadmap.
 Able to recognize emerging technologies and
how to apply them to product/feature use
cases.
TPM Technical Bar
 Understands system limitations, scaling  Can identify risks and complexity
factors, boundary conditions, and/or the
reasons for architectural decisions (Q. Why
did we build X in this way? What business
assumptions were made? What technical
assumptions were made? Do we need to
build something else– if so why?).
 Can decouple dependencies (e.g., SOA best  Understands team systems and
practice) and prevent duplicate efforts,
collisions/outages, etc.
 Has a larger business and architecture view.
Uses technical judgment to inform technology
and business trade-offs.
 Can hold an engineering team to a high
standard for both solutions and engineering
practices (similar to a senior engineer or
technical manager).
 Able to simplify concurrent project delivery,
including development and testing processes
for projects that cross team boundaries.
SDM
in architectures. Able to unblock
engineers/ teams.
 Can identify where to simplify,
optimize, reduce overhead,
and/or where solutions may be
extensible.
its effect on larger architecture.
 Makes trade-offs: short-term
team needs and long-term
business needs.
 Knows how to scope a project. Is
able to discern which features
are essential, can be triaged, or
omitted.
 Tech Bar Comparison
Level PMT Technical Bar
L7  Deep knowledge of the core
technologies utilized in their product
domain and how to apply these
technologies to invent, evolve, improve,
simplify, etc.
 Can identify gaps/opportunities within
or between features, regions, system
architectures (e.g., services, workflows,
tools, etc.) to satisfy the needs of
product customers.
 Able to decompose significantly complex
problems into straightforward solutions.
 Consistently brings strong, CX, data-
driven business, and technical judgment
to decisions.
 Recognizes when designs/solutions
require additional technical guidance
(e.g., from senior engineers or subject
matter experts).
 Has strong, data-driven business and
technical judgment Able to make the
case for a technology product and can
influence teams to dedicate resources.
TPM Technical Bar
 Deep knowledge of core technologies in program domain
and/or broad understanding of company systems and
technologies and how to apply this knowledge to invent,
evolve, improve, simplify, etc.
 Able to drive large-scale engineering efforts to solve
significantly complex or endemic problems.
 Can identify gaps/opportunities within/between regions,
architectures, and organizations (e.g., services, workflows,
tools, etc.).
 Able to decompose significantly complex problems into
straight-forward solutions.
 Has strong, data-driven business and technical judgment.
Recognizes when designs/solutions require additional
technical guidance.
 Able to make the case for technology programs. Can
influence teams to dedicate resources and lead the effort.
 Reduces coupling between teams. Able to see where we
apply the same engineering effort year-over-year to
determine what requires us to exert that effort.
 Knows how to drive architecture or organization changes
to enable teams to work independently and/or achieve a
significant efficiency improvement.
SDM
 Can identify opportunities in
technical strategy or with team
structure(s).
 Understands how to empower
engineering team(s) to evolve/create
architectures that are exemplary in
terms of robustness, stability,
scalability, cost-effectiveness.
 Understands strategic importance to
larger business. Influences larger
priorities/trade-offs.
 Makes trade-offs: resources vs. risk
vs. sustainability.
 Makes decisions on the future of a
product or system architecture future
(improve, invent, deprecate, simplify)
Observations and Conclusions
• A 2 pizza team typically utilizes 1 or 2 of these roles.
• Focus on the job expectations and skills that you need. Use the job
title that is closest to those expectations.
• When there is overlap, clarify who is accountable for what using a
RACI - https://w.amazon.com/index.php/RACI