Principles for product velocity
A startup founder’s claim that “methodology is bullshit” and that small teams should prioritize rapid shipping with minimal process prompted a broader examination of when lightweight workflows actually work. Commenters note that this engineer-led, “just build it” style can succeed in tiny devtool or security teams with strong people and aligned context, but breaks down in larger organizations and complex, regulated domains where coordination, documentation, and domain expertise are essential. Many see formal methods like Agile and Scrum not as inherently bad, but as often misapplied management tools that either prop up weak teams or suffocate strong ones, reinforcing the view that people and context matter more than any one process.
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.