By Marty Cagan · svpg.com · LinkedIn
Marty Cagan argues that a product manager's core job is discovering products that are valuable, usable and feasible, and that engineering must be involved early to achieve feasibility. Waiting until engineering sees a finished spec leads to costly, late-stage trade-offs and ideas that cannot be built. He also describes the architect as a holistic systems role, often organized into a centralized team of about five percent of engineering, that keeps the system healthy, preserves institutional knowledge, and offers a senior technical path outside management. The piece matters because it reframes product work as a collaborative triad with designers and architects rather than a PRD handoff.
01Key takeaways
- Bring engineers and architects into product discovery early so feasibility shapes ideas before they are committed to.
- Ask engineering for early, rough cost and complexity estimates on prototypes, not polished schedules after the spec is final.
- Plan a few hours per week of engineering time for reviewing ideas during discovery, rising to firm estimates as ideas mature.
- In growing organizations, consider a centralized architecture team of roughly five percent of engineering to keep the system scalable and maintainable.
- Give senior engineers a technical career path like architect so top talent need not move into management to advance.
- Choose architects the engineering team trusts, since their feasibility statements speak for the whole team.
02Key sections
- Why engineering belongs in discovery
- Engineers and architects know what is technically possible and can suggest, evaluate and refine solutions. Their early cost and complexity estimates are essential inputs for deciding which features are worth including.
- The problem with late engineering involvement
- Handing a finished idea to engineering often reveals it is too expensive or infeasible when there is no time left to test alternatives with users. Cagan notes this happens both when PMs see defining the product as their sole job and when engineering is too busy to participate.
- The architect role in larger organizations
- As products scale, architects take a holistic view of architecture, operations, performance and release management. A centralized architecture team helps prioritize technical initiatives and competes for scarce engineering resources.
- Architects as institutional knowledge
- Because documentation is often outdated, architects serve as living documentation, onboard new engineers, and attend code and design reviews to catch problems early. They also help evaluate third-party integrations and acquisitions.
- Building trust in the architect
- Architects should be promoted from senior engineers or hired for their credibility, since their feasibility judgments represent the whole engineering team. PMs should identify their designer and architect partners at the start of each project.
03From the post
“A partnership dedicated to teaching best practices to product teams and product leaders”
04Frameworks mentioned
Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.