The Litmus framework encourages sourcing solutions from teams like customer success, operations, or data science, not just engineering, product, and design. This expands the pool of problem-solvers, increases cross-functional buy-in, and allows the organization to test more ideas faster.

Related Insights

Instead of a traditional product roadmap, give engineers ownership of a broad "problem space." This high-agency model pushes them to get "forward deployed" with customers, uncover real needs, and build solutions directly. This ensures product development is tied to actual pain points and fosters a strong sense of ownership.

To create a cohesive product across multiple teams, GitHub uses a framework that forces alignment upfront. By ensuring all teams first deeply understand the problem and collectively identify solutions, the final execution is naturally integrated, preventing a disjointed experience that mirrors the org structure.

Instead of siloing roles, encourage engineers to design and designers to code. This cross-functional approach breaks down artificial barriers and helps the entire team think more holistically about the end-to-end user experience, as a real user does not see these internal divisions.

The common product development process is a sequential handoff model. A better approach is a "jazz band" model where cross-functional teams collaborate harmoniously from the start. This fosters creativity and reduces rework by including engineers in early ideation, rather than treating them as a final step.

Instead of over-analyzing and philosophizing about process improvements, simply force the team to increase its cadence and ship faster. This discomfort forces quicker, more natural problem-solving, causing many underlying inefficiencies to self-correct without needing a formal change initiative.

Chess.com's goal of 1,000 experiments isn't about the number. It’s a forcing function to expose systemic blockers and drive conversations about what's truly needed to increase velocity, like no-code tools and empowering non-product teams to test ideas.

The debate between being product-led vs. sales-led is a false dichotomy that creates friction. Instead, frame all functions as fundamentally 'customer-driven.' This reframing encourages product teams to view sales requests not as distractions, but as valuable, direct insights into customer needs.

Dara Khosrowshahi describes a two-step innovation process. First, let teams compete to rapidly "hack" a solution and find product-market fit. Second, once a winner emerges, the organization must systematize and automate that solution through engineering to make it scalable and part of the core platform.

Siphoning off cutting-edge work to a separate 'labs' group demotivates core teams and disconnects innovation from those who own the customer. Instead, foster 'innovating teams' by making innovation the responsibility of the core product teams themselves.

When pursuing a long-term strategic solution, dedicate product management time to high-level discovery and partner alignment first. This doesn't consume engineering resources, allowing the dev team to remain focused on mitigating the immediate, more visceral aspects of the problem.

The Litmus Framework Speeds Up Execution by Spreading Solution Ownership Beyond Engineering | RiffOn