Principles for product velocity

Context and Scope

• Many note the company is tiny and builds devtools for engineers. That context makes “no PMs, no Figma, no Agile” more viable: customers resemble the builders, domain is familiar, and coordination overhead is low.
• Several warn this is not transferable to complex, regulated domains (e.g., securities, GDPR, WCAG) where cross‑functional collaboration and traceability avoid legal or financial disasters.
• Multiple comments predict that if the company grows, more process will inevitably appear.

Product, Domain Expertise, and PMs

• Some argue domain experts can work directly with engineers, making product managers unnecessary, especially when customers are technical.
• Others counter that translating thousands of pages of law, regulation, or market nuance into product decisions is a specialized job; using expensive engineers for that is wasteful.

Design and Requirements: Figma vs Prototypes

• One camp uses lightweight Figma to align engineering, ops, and legal on what will be built, but avoids pixel‑perfect specs.
• Another sees detailed mockups as a red flag: high-fidelity “never-used” UIs vs rough, functional prototypes that expose real usability issues.

Timeboxing, Velocity, and “60 Days”

• Many recognize the “fixed time, variable scope” pattern: given a quality bar, ship what fits in ~60 days.
• Supporters say this prevents work from expanding to fill arbitrary deadlines and focuses on quality.
• Critics note that people stretch work only when they have no stake or don’t believe the deadline matters; they stress accountability and using time for tests, docs, and tooling.

Process vs People; Agile and Scrum

• Strong theme: outcomes depend more on people than on methodology.
  • Good teams + light process → great results.
  • Good teams + heavy process → “barely passable.”
  • Heavy process is seen as a way to extract “passable slop” from weak teams and to increase managerial control.
• Agile/Scrum are described as originally lightweight, but often distorted into management and reporting frameworks, with standups and retros perceived either as helpful communication tools or as surveillance and velocity‑whipping.
• Several stress that every team has some process; the real issue is rigid, one‑size‑fits‑all “capital‑M Methodology.”

Safety, Security, and “Idiot Mode”

• Some are uneasy about combining “idiot mode code,” no design docs, and a security product, arguing security needs patterns and APIs that are hard to misuse.
• Others suggest small, highly skilled teams can get away with informal, fast iteration—but only up to a point.

Build vs Buy

• Many broadly agree: outsource solved, non‑core problems to vendors to move faster.
• Others recount costly vendor experiences and warn that integrations, lock‑in, and vendor failure can erase initial gains.