The Product Boss

Abstract

No one owns a product end to end. That is the central finding from the discovery interview series conducted as a semiconductor module organization moves from a functional swimlane structure to Product Delivery Teams organized around four module product families. The swimlane model works as a planning framework and fails as an execution model, because no single person carries a product through NPI, qualification, and volume ramp. The Product Boss closes that gap. Their overriding mission is to take a product from concept to market as fast as possible, and they are the single point of accountability for making it happen. They are the CEO of their product, owning the business outcome, the customer relationship, the technical trade-offs, and the execution schedule. Every decision is weighed against its impact on time to market, because late products destroy profitability and growth far more than any additional development cost. The role enforces the operational product strategy for their product: roadmap lock, change control, NPI compliance audits, and stage-gate passage. This document defines the role: what the Product Boss owns, how they operate, how they relate to the PDT Program Manager, the Embedded Leads, and the Functional Managers, and what the hiring profile looks like. Two appendices carry the supporting frameworks. Appendix A defines the Freedom Scale used throughout. Appendix B separates the Product Boss from the Program Manager using the CEO and COO analogy, the boundary most often blurred in practice. This revision renames the role. Earlier editions used the title Product Delivery Leader (PDL); the organization has adopted Product Boss, with the Product Director serving as the boss of Product Bosses. The mandate is unchanged. Six stakeholders independently validated the concept during the discovery interview series. The name itself is older than this model. lateralworks first encountered it at Sun Microsystems during the original best-practice research behind FTTM, where a product boss held lateral ownership of a product line from concept through manufacturing and delivery — one person accountable across the functions rather than a committee of them. The term appears in first-hand accounts of Sun from that period. This edition adopts the name because the accountability it describes has not changed. Why the title matters. "Leader" describes a behavior. "Boss" describes an accountability. The rename was not cosmetic: it settled who the Embedded Leads take direction from, and it made the reporting line to the Product Director legible to the rest of the organization. On the origin of the term: lateralworks best-practice research at Sun Microsystems, and the first-hand account in Cockcroft. Fast Time To Market (FTTM) is the lateralworks methodology, in practice since 1988. Full references on page 23.

Section one — Role definition

The Product Boss takes a product from concept to market as fast as possible. They are the single point of accountability for the entire product from NPI through volume ramp, and every part of the role serves that speed mandate: team leadership, customer alignment, technical trade-offs, and NPI gate enforcement. The Product Boss is the CEO of their product. They own the business outcome, the customer relationship, and the execution schedule, and they enforce the operational product strategy for their product. Speed requires authority. Late products destroy profitability and growth far more than any additional development cost, so the Product Boss is empowered to make the trade-off decisions that accelerate time to market: choosing parallel paths over sequential ones, killing low-value work to concentrate resources on the critical path, resolving cross-functional conflicts in real time rather than escalating through a committee, and enforcing schedule discipline across the PDT. The cost of delay is the Product Boss’s compass. One stakeholder called this a “unicorn” role: someone who makes quick decisions, commands respect, has skin in the game, and is close to the business, the customer, and the execution teams. The Product Boss is not an expert in every field. They are an expert generalist who can see the complete system end to end and connect the dots across packaging, test, yield, supply chain, and customer requirements. Six stakeholders independently validated the concept from different vantage points. One proposed the same idea under the name Product Lifecycle Manager. One identified the program management gap. One described the product line manager model they had seen work at scale in a large analog and embedded semiconductor business. One flagged the manufacturing flow architect gap, one supported the restructuring outright, and one endorsed the product-owner separation principle.

At a glance The role in five dimensions Dimension Description Reports to The Product Director (the boss of Product Bosses), who reports to the Program General Manager. The Product Boss keeps direct access to the PGM for strategic and customer escalations. Decision authority 80% of product decisions are made by the Product Boss and the core team. Corporate functions retain a 20% veto on enterprise-level decisions such as major fab CAPEX and corporate quality standards. Team structure Leads a dedicated, heavyweight PDT core team: a Program Manager plus embedded functional leads, 11 seats in the current model, with a conditional 12th seat (driver design for programs carrying new driver IP, component vendor management for module programs). No shared resources. Performance influence 50–100% of Embedded Lead performance reviews are conducted or influenced by the Product Boss. FTTM model Heavyweight team structure per lateralworks Best Practice 2.8, the fastest proven model for strategically critical programs. The title changed; the role did not. Documents that reference the Product Delivery Leader (PDL) describe this role. The renaming reflects how the organization actually talks about the position and pairs naturally with the Product Director title above it.

Section two — Core responsibilities

Every responsibility below flows from one mandate: take the product from concept to market as fast as possible while meeting customer quality and reliability requirements. Concept-to-market speed – Owns the product from concept through NPI, qualification, production release, and volume ramp to the billion-unit target, and is accountable for the elapsed time of each phase. – Drives before-the-fact urgency: knows the gap between the target schedule and the real schedule at all times, and uses that gap to force trade-off decisions early, while there is still time to change the approach. – Kills low-value work and concentrates resources on the critical path. Does not let the team pursue everything in parallel when resources are constrained. – Treats the cost of delay as the primary decision-making metric.

End-to-end product ownership – Accountable for all product milestones: WS (Working Sample), ES (Engineering Sample), CS (Customer Sample), Qualification, and Production Release. – Enforces operational product strategy governance for their product: roadmap lock, change control, NPI compliance audits, and stage-gate passage. – Owns the NPI phase gate process (six phases, seven gates) as the quality backbone for their product. No exceptions, no bypasses. – Makes Start/Stop/Continue decisions at the product level and recommends portfolio-level decisions to the Program General Manager. Business and customer accountability – Owns the P&L for their product, including COGS targets, yield economics, and CAPEX/OPEX justification. – Serves as the internal voice of the customer, translating customer specification requests into actionable engineering requirements. – Manages the customer’s quality and reliability expectations, including contractual liability terms and extended mission-profile reliability requirements at hyperscale. – Makes the trade-off decisions that optimize the total product system rather than sub-optimizing individual components. Cross-functional team leadership – Leads the PDT core team as a heavyweight team leader. All Embedded Leads take primary direction from the Product Boss, not their functional hierarchy. – Conducts or influences 50–100% of Embedded Lead performance reviews. – Resolves inter-functional conflicts inside the PDT without escalating to the Program General Manager. – Turns ambiguity into executable critical-path plans. When something is undefined, the Product Boss drives it to resolution rather than waiting for someone else to decide. Provisioning and obstacle clearing Two responsibilities deserve their own heading because they are what the CEO of a product actually does day to day. First, the Product Boss provisions the team: they make sure the core team has the people, tools, budget, information, and decisions it needs before the lack of them becomes a delay. A team that waits is a team that slips. Second, the Product Boss clears obstacles: they remove the blockers the team cannot remove for itself, absorb organizational noise before it reaches the team, and spend their own authority to keep the path open. Appendix B develops both responsibilities in the CEO and COO frame.

The mandate The Product Boss north star Concept to market, as fast as possible. lateralworks FTTM methodology Product Delivery Team organizational model · July 2026

Section three — Operating principles

Six principles govern how the Product Boss operates. They are listed in priority order; when two conflict, the earlier one wins. 1. Concept to market as fast as possible. This is the north star. Every decision, trade-off, and staffing choice is evaluated against its impact on time to market. The cost of delay, the lost profit from missing market windows, far exceeds any additional OPEX spent on acceleration. Speed over control. 2. Decision authority is 80/20 inside the PDT. 80% of decisions are made by the Product Boss and the core team. Corporate functions retain a 20% veto on enterprise-level decisions. Fast decisions require that authority lives inside the team, not in the functional hierarchy. 3. The Product Boss is an expert generalist. Not an expert in every field, but able to see the complete system end to end and connect its domains, packaging through customer requirements. They make the trade-offs the end product needs to succeed on time.

4. No shared resources within the PDT. All core team members are fully dedicated to one product. Multiplexing across PDTs is the single largest source of schedule bloat and hidden waiting time in normal organizations. 5. The schedule is king. The Product Boss owns milestone commitments to the customer and the PGM. No macro schedule slippage is permitted; when the micro schedule moves, the team pulls it back before the macro is affected. Bank time when ahead, recover immediately when behind. 6. Report through the Product Director. The Product Boss reports to the Product Director for cross-PDT coordination, so the PDTs do not compete for the same factory capacity or supplier allocations, and keeps direct access to the Program General Manager for strategic and customer escalations.

Empowerment The Product Boss freedom scale The table below sets the recommended autonomy level for the Product Boss by decision area. The target operating state is predominantly Level 1–2, matching the heavyweight authority the role requires. Appendix A defines the scale. Decision area Level Rationale Product technical trade-offs 1 Act, routine reporting only. The Product Boss owns all product-level technical and business trade-offs. This is their core authority domain. NPI gate compliance 1 Act, routine reporting only. The Product Boss enforces stage-gate passage and the phase gate process for their product. No bypass authority exists outside the Product Boss. Start/Stop/Continue (product level) 2 Act, advise at once. Product-level decisions are made and the PGM advised immediately. Portfolio-level decisions are recommended upward. Customer commitment changes 2 Act, advise at once. The Product Boss owns the customer relationship and adjusts commitments within product scope, advising the PGM of changes. Embedded Lead performance reviews 1 Act, routine reporting only. 50–100% of review input comes from the Product Boss; the Functional Manager contributes the technical competency assessment. Cross-PDT resource conflicts 3 Recommend, then act. When PDTs compete for shared capacity in fab, test, or reliability equipment, the Product Boss recommends resolution to the Product Director. Enterprise standard exceptions 3 Recommend, then act. Product-specific deviations from corporate standards are evaluated jointly with the Functional Manager and recommended upward. CAPEX and headcount requests 2 Act, advise at once. The Product Boss justifies product-specific CAPEX and headcount, advises the PGM, and coordinates with corporate finance and operations for approval.

Section four — Working with the rest of the PDT

The Product Boss operates inside a five-layer model. The boundaries between layers are what make the PDT model work; when a boundary blurs, the organization reverts to the swimlane behavior the model exists to replace. Role Relationship to the Product Boss Boundary PDT Program Manager Execution partner. Owns the how and when (the integrated FTTM schedule) while the Product Boss owns the what and why (the product outcome). The Product Boss owns milestone commitments; the PM owns the schedule mechanics. The PM does not override product decisions; the Product Boss does not micro-manage the schedule. See Appendix B. Embedded Leads Core team members who take primary direction from the Product Boss. Dedicated 100% to the product. Embedded Leads report operationally (solid line) to the Product Boss, with a dotted line to their Functional Manager for technical standards and career development. Functional Managers Provision talent, set enterprise standards, and hold the 20% veto on enterprise decisions. Functional Managers do not direct the daily work of Embedded Leads, override Product Boss decisions, or impose functional timelines on the PDT schedule. Product Director The boss of Product Bosses. Coordinates across the PDTs and owns portfolio-level alignment, escalating to the PGM. The Product Director resolves cross-PDT contention and does not override product-level decisions inside a PDT. Program General Manager Owns portfolio-level decisions. The Product Boss retains direct access for strategic and customer escalations. Portfolio Start/Stop/Continue decisions and cross-PDT resource conflicts land here when the Product Director cannot resolve them.

The core team What the Product Boss directs The roster below matches the current core team matrix, which defines the specific functions represented on each core team. The Product Boss and Program Manager lead the team; the remaining seats are embedded functional leads, two of them conditional on product type. Each seat is dedicated to one product. Core team seat What the Product Boss directs 1. Product Boss The seat this document defines. Leads the core team and owns the product end to end. Product Boss in Training Development scope and shadow assignments. Holds no independent accountability until a dated transition (Appendix A). 2. Program Manager Priorities for the integrated schedule, recovery-plan decisions, and scope trade-offs. The PM runs the schedule; see Appendix B. 3. Module Design Module architecture priorities, substrate optimization trade-offs, and silicon-package co-design decisions. 4. Component Vendor Management (module programs only) Passive component vendor technical and commercial priorities, split between a technical lead and a business lead. 5. Driver Design Lead (programs with new driver IP only) Driver IC architecture trade-offs, tape-out timing, and silicon-package co-design for the driver. 6. Product Engineer Qualification plan scope, production release readiness calls, and change notification impact decisions. 7. Test Engineer Test coverage versus cost trade-offs and test hardware investment timing. 8. Validation Validation scope per milestone and readiness sign-off standards for WS, ES, and CS. 9. Applications Customer application priorities, evaluation support, and spec alignment decisions. 10. Package Development Coordinator Package design priorities and package qualification trade-offs. 11. Quality Lead Product qualification scope, customer quality commitments, and NPI gate readiness calls. 12. Embedded Substrate / Laminate Embedded substrate technology direction and supplier qualification priorities.

Core team seat What the Product Boss directs 13. Manufacturing Engineering Assembly and test flow decisions, ramp readiness, and internalization trade-offs across both manufacturing sites. Two roles sit across the PDTs rather than inside one. The Product Director (the boss of Product Bosses) attends core team meetings to drive alignment, knowledge sharing, and priority decisions across PDTs. The engineering build request coordinator handles build request preparation and tracking as a horizontal resource; the matrix leaves its directly responsible individual open between product engineering, program management, and planning. Additional attendees join by topic rather than holding seats: packaging, test, PMO, quality, and systems as the requirements-document owner. Functional leads coordinate these attendees within their own teams.

Section five — Hiring profile

This is the hardest role to fill in the PDT model. The estimated lead time is 9 to 18 months from search initiation to productive contribution. If requisitions have not been opened, these positions will not be productive for more than a year even if the search starts today, which makes Product Boss hiring the single longest lead-time item on the organizational critical path. Required experience – Semiconductor module or power electronics product line management. – NPI through volume production at scale, above 100M units. – Cross-functional authority: has led teams where functions reported to the product leader, not just coordinated across them. – Customer-facing capability with Tier 1 hyperscale or automotive OEM accounts.

Critical competencies – Speed orientation. Instinctively treats time to market as the primary constraint and runs every decision through the lens of what gets the product to market fastest while meeting customer requirements. – Expert generalist. Connects packaging, test, yield, supply chain, and customer requirements without deep specialization in any one. – Trade-off decision-making. Comfortable making hard technical and business calls under time pressure, optimizing the total system. – Respect and authority. Commands respect from senior engineers and functional managers alike, so team members take direction from the Product Boss rather than defaulting to their functional hierarchy. – Before-the-fact urgency. Drives urgency at the start of the project, while there is still time to change the approach, not at the end when there is no time to recover. Hiring timeline Phase Duration Cumulative Executive search initiation 1–2 months 1–2 months Candidate identification and screening 3–6 months 4–8 months Interview, offer, and notice period 2–4 months 6–12 months Onboarding and ramp to productivity 3–6 months 9–18 months Critical implication. Internal development changes this math. A Product Boss in Training bench exists precisely because external hires cannot arrive in time. Growing the next Product Bosses from inside, against the freedom scale in Appendix A and with dated transitions, is the only path that beats the 9–18 month external clock.

Section six — Diagnostic signals

If the Product Boss consistently operates below the suggested freedom scale, the structure has a problem: either the individual needs development, the culture is overriding the design, or the role definition needs revisiting. These indicators show whether the model is working as designed. Healthy signals – The Product Boss makes product-level technical and business trade-offs at Freedom Level 1 without waiting for functional manager approval. – Embedded Leads take primary direction from the Product Boss and do not default to their functional hierarchy for daily priorities. – Each PDT moves at its own speed. An issue in one product family does not slow another, and each product is on its fastest path to market.

– The Product Boss knows the schedule gap and forces trade-off decisions early rather than discovering lateness at the end. – NPI gate compliance is enforced with no bypasses. The gate-bypass scenario that triggered this work does not repeat. – The Product Boss spends most of their time on product execution and customer alignment, not on coordination overhead. Warning signals – The Product Boss routinely waits for functional manager approval before making product-level decisions (Level 4–5 behavior). – Embedded Leads take direction from their functional hierarchy, fragmenting the team. – The PDT schedule is overridden by functional timelines imposed from outside the team. – The Product Boss is assigned to multiple products at once, reverting to the lightweight PMO model. The current core team mapping shows this is the live risk, not a hypothetical one. – Cross-PDT resource conflicts are not escalated through the Product Director, causing silent schedule slips.

Summary

What the Product Boss owns, and does not The Product Boss owns The Product Boss does not own Concept-to-market speed for their product Integrated FTTM schedule mechanics (PDT PM) End-to-end product delivery, NPI through ramp Enterprise technical standards (Functional Mgr) P&L, COGS, and yield economics Talent pipeline and hiring (Functional Mgr) The customer relationship Cross-PDT knowledge transfer (Functional Mgr) 80% of product-level decisions Portfolio-level Start/Stop/Continue (PGM) NPI gate compliance enforcement Cross-PDT resource allocation (Product Director / PGM) Provisioning the team and clearing obstacles Major fab CAPEX approval (20% veto / PGM) Product vision, held intact under pressure

A Appendix A The Freedom Scale The Freedom Scale, adapted from Bill Oncken’s work on management leverage, quantifies empowerment: how much autonomy a person or team holds in a given decision area. The lower the level, the faster decisions are made and the more ownership people feel in the outcome. Best-in-class product organizations run their teams at Levels 1–2 on most decisions, with management satisfied by during-the-fact or after-the-fact control. Normal organizations run at Levels 3–5, where functional managers keep before-the-fact control. That is slower, creates bottlenecks, and disempowers teams. Level Definition Control type Who operates here

Act, routine reporting — only

After-the-fact Experienced professionals with demonstrated judgment. Maximum empowerment, maximum leverage for the boss.

Act, but advise at — once

During-the-fact Professionals whose decisions carry cross-functional impact where visibility matters but speed cannot wait.

Recommend, then — take action

Before-the-fact Professionals building context in a new domain. “Unless otherwise directed, I intend to…” 4 Ask what to do Before-the-fact Trainees only. Creates dependency on the boss and disempowers the individual. 5 Wait until told Before-the-fact New trainees only. Anyone at Level 5 on routine decisions has been structurally disempowered.

Levels 1–3 provide leverage and growth; experienced professionals cannot work below these levels of freedom. Levels 4–5 are behaviors reserved for training status. Freedom is delegated by the boss, earned by the subordinate, or both. Key principles – Freedom is situational, not absolute. A person may hold Level 1 on technical decisions and Level 3 on hiring. Levels attach to decision areas, not to people. – People disempower themselves by asking. The more someone asks (Level 4), the more they get told what to do, and the closer they drift to Level 5. Best practitioners break the cycle by defaulting to action. – Trust produces speed; control produces slowness. Level 1–2 teams make real-time decisions without hierarchical bottlenecks, and management gets more leverage, not less, because the team owns the outcomes. – The levels are an onboarding tool. New hires may start at Level 3 while building context, with a planned trajectory to Level 1–2 within 90 days. A role operating two or more levels below its suggested scale is a structural diagnostic, not a people problem. Adapted from the five levels of initiative in Oncken and Wass. The numbering runs the other way in the original: their level 1 is “wait until told” and their level 5 is “act independently, report routinely.” The lateralworks scale inverts this so Level 1 denotes maximum autonomy, consistent with FTTM Best Practice 2.10, Freedom Level 1 Empowerment. The behaviors described at each level are unchanged.

B Appendix B The Product Boss and the Program Manager The boundary most often blurred in practice is the one between the Product Boss and the PDT Program Manager. The cleanest way to hold it: the Product Boss is the CEO of the product, and the Program Manager is its COO. The split was circulated and aligned across product and program leadership: the Product Boss owns the business and the product; the Program Manager owns execution and delivery. The Product Boss is strategic. They set the product vision and keep it intact under pressure, when a customer pushes for scope, a function pushes for its own optimum, or a schedule crunch tempts the team to trade away what the product must be. They provision the team, making sure it has the people, tools, budget, information, and decisions it needs before the lack of any of them becomes a delay. And they clear obstacles: they remove the blockers the team cannot remove for itself, absorb organizational noise before it reaches the team, and spend their own authority and relationships to keep the path open. A Product Boss doing this well is often invisible in the daily standup and decisive everywhere around it.

The Program Manager is operational. They run the daily details of driving the project: the integrated FTTM schedule, weekly refresh planning, the critical path and the 10–20 secondary paths behind it, pull-in modeling, and the systematic elimination of interrupts. Where the Product Boss asks whether the team is building the right product fast enough, the Program Manager asks what must move this week for the answer to stay yes. Both operate at Freedom Level 1 in their own domain. Dimension Product Boss (CEO) Program Manager (COO) Focus The what and the why: product outcome, customer, P&L. The how and the when: schedule, dependencies, execution. Horizon The market window, from concept to volume ramp. The next six weeks, in tasks of ten days or less. Primary instrument Cost of delay. Critical path. Characteristic acts Provision the team. Clear obstacles. Hold the vision. Decide the trade-offs. Refresh the schedule. Model pull-in. Eliminate interrupts. Drive the weekly drumbeat. Relationship to the team Leads it; directs the Embedded Leads; reviews performance. Facilitates it; the team builds and owns the schedule together. Trade-offs Makes the trade-off decisions. Provides the impact analysis. Barriers Removes organizational barriers. Removes execution barriers. Failure mode when absent A starved team with no vision: well-run schedules toward the wrong product. A drifting schedule that reports status instead of driving work. Freedom scale Level 1–2 on product decisions. Level 1 on schedule decisions. The boundary cuts both ways. A Product Boss who micro-manages the schedule is doing COO work, which means no one is doing CEO work: the vision goes unguarded, the team goes unprovisioned, and the obstacles stay standing. A Program Manager who makes product trade-offs is doing CEO work without the accountability, the customer relationship, or the P&L. The partnership works when each trusts the other’s domain: the Product Boss provides air cover for the PM’s schedule authority, and the PM gives the Product Boss an honest gap, every week, with no happy schedules. The operating rhythm makes the split visible. In the product deep-dive reviews, the Product Boss presents the product and the Program Manager runs the tool. The shortest version of the boundary: the Product Boss owns the product; the Program Manager owns the plan. Document prepared by lateralworks. Based on discovery interviews, swimlane documentation, module readiness workshop materials, the current core team mapping, and FTTM Best Practices research. Company, customer, program, and individual names have been removed for external publication.

Sources

References

1. Cockcroft, A. “What Adrian Did Next — Part 2: Sun Microsystems.” Medium, June 2022. First-hand account of the product boss role at Sun. adrianco.medium.com/what-adrian-did-next-part-2-sun-microsystems-c1a512c8284
2. Clark, K. B., and Wheelwright, S. C. “Organizing and Leading ‘Heavyweight’ Development Teams.” California Management Review, Vol. 34, No. 3, Spring 1992, pp. 9–28. cmr.berkeley.edu/1992/05/34-3-organizing-and-leading-heavyweight-development-teams
3. Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality. Free Press, 1992.
4. Oncken, W., Jr., and Wass, D. L. “Management Time: Who’s Got the Monkey?” Harvard Business Review, Vol. 52, No. 6, November–December 1974, pp. 75–80. Reissued November–December 1999. hbr.org/1999/11/management-time-whos-got-the-monkey
5. House, C. H., and Price, R. L. “The Return Map: Tracking Product Teams.” Harvard Business Review, January–February 1991. Reports a McKinsey study finding that companies lose 33% of after-tax profit when they ship six months late, against 3.5% when they overspend development by 50%. The McKinsey study itself was not separately published; House and Price is the citable source. hbr.org/1991/01/the-return-map-tracking-product-teams
6. Smith, P. G., and Reinertsen, D. G. Developing Products in Half the Time. Van Nostrand Reinhold, 1991.
7. Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. Source for cost of delay as the primary economic metric, the cost of queues and work in process, and decentralized control.
8. lateralworks. “Internal assessment database.” Engagement and best-practice research data across client programs, 1988–2026. Framework attributions above are external. FTTM, the Product Delivery Team model, the core team roster, and the Freedom Scale numbering used in this paper are lateralworks material and are not claimed by the cited authors.