When facing a major technical unknown or skill gap, don't just push forward. Give the engineering team a dedicated timebox, like a full sprint, to research, prototype, and recommend a path forward. This empowers the team, improves the solution, and provides clear data for build-vs-buy decisions.
To de-risk innovation, teams must avoid the trap of building easy foundational parts (the "pedestal") first. Drawing on Alphabet X's model, they should instead tackle the hardest, most uncertain challenge (the "monkey"). If the core problem is unsolvable, the pedestal is worthless.
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.
AI initiatives often require significant learning and iteration, which can derail a roadmap. To combat this, PMs should dedicate a fixed percentage of development bandwidth (e.g., 5-10%) specifically for iteration on high-priority AI projects. This creates a structured buffer for discovery without compromising the entire plan.
Spend significant time debating and mapping out a project's feasibility with a trusted group before starting to build. This internal stress-test is crucial for de-risking massive undertakings by ensuring there's a clear, plausible path to the end goal.
Effective, fast research isn't about skipping steps but about rightsizing the effort. Instead of defaulting to a previous method like "10 interviews," teams should determine the minimum insight needed to mitigate the specific risk at hand, using that to define the research scope and approach.
When an engineering team is hesitant about a new feature due to unfamiliarity (e.g., mobile development), a product leader can use AI tools to build a functional prototype. This proves feasibility and shifts the conversation from a deadlock to a collaborative discussion about productionizing the code.
To make risk management tangible, build specific tests for Value, Usability, Feasibility, and Business Viability directly into each epic. This moves risk assessment from a separate, ignored artifact into the core development workflow, preventing it from becoming a waterfall-style gate.
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.
Instead of arguing for more time, product leaders should get stakeholder buy-in on a standardized decision-making process. The depth and rigor of each step can then be adjusted based on available time, from a two-day workshop to an eight-month study, without skipping agreed-upon stages.
The misconception that discovery slows down delivery is dangerous. Like stretching before a race prevents injury, proper, time-boxed discovery prevents building the wrong thing. This avoids costly code rewrites and iterative launches that miss the mark, ultimately speeding up the delivery of a successful product.