To pursue a high-risk internal tool, the engineer explicitly negotiated a 2-3 month "exploration" period with his manager. This aligned expectations, framing the work as a calculated risk rather than a guaranteed deliverable, which protected his performance review if the project failed.
Related Insights
Surprising your manager with a major failure is one of the worst mistakes you can make. You must proactively communicate risks as soon as they arise. This gives your leader time to manage expectations up the chain and prevents them from being blindsided.
In ROI-focused cultures like financial services, protect innovation by dedicating a formal budget (e.g., 20% of team bandwidth) to experiments. These initiatives are explicitly exempt from the rigorous ROI calculations applied to the rest of the roadmap, which fosters necessary risk-taking.
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.
When leaders demand high-fidelity prototypes too early, don't react defensively. Instead, frame your pushback around resource allocation and preventing waste. Use phrases like "I want to make sure I'm investing my energy appropriately" to align with leadership goals and steer the conversation back to core concepts.
When facing internal resistance to a big idea, the tendency is to make the idea smaller and safer. The better approach is to protect the ambitious vision but shrink the steps to validate it, using small, targeted experiments to build evidence and momentum.
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.
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.
When stakeholders want to ship a high-fidelity prototype immediately, counter by explaining the required effort using numbers. Frame the work in terms of scale (e.g., "This must support 200 products, each requiring a week of testing") to manage expectations and justify proper engineering.
Unlike a corporate setting where failure has high stakes, solo projects allow you to take big swings and fail without career repercussions. The key is to treat these failures professionally by conducting post-mortems or root cause analyses to internalize learnings that are directly transferable.
Executives often see "discovery" as a slow, academic exercise. To overcome this, reframe the process as "derisking" the initiative. By referencing past projects that failed due to unvetted assumptions, you can position research not as a delay, but as a crucial step to prevent costly mistakes.