What Do We Mean by “Steering into Risks”?

There is a parable in product development about monkeys and pedestals. Your team is tasked with an ambitious goal: training a monkey to juggle flaming torches on a pedestal in a town square. It’s tempting to start with the easy part first—building the “pedestal”—but real progress comes from facing the riskiest, most uncertain challenge first—the “monkey.” If the monkey can’t juggle flaming torches, the pedestal is irrelevant. By steering into risk early, we avoid wasting resources on work that ultimately won’t matter if the core challenge remains unsolved.

At Ellevation, once we have prioritized which high-level problems to pursue, we tackle that problem by steering into the biggest risks first. This involves

• identifying potential issues;
• assessing their impact
• and developing strategies to mitigate or avoid them throughout the development process.

Key Aspects of Steering into Risks:

• 1. Early Identification:
  Identifying potential risks early on is crucial, as it allows for proactive mitigation efforts before they escalate. This includes identifying market, technical, and resource-related risks.
• 2. Risk Assessment:
  Once risks are identified, they need to be assessed based on their likelihood and potential impact on the product. This helps prioritize which risks require immediate attention and resources.
• 3. Mitigation Strategies:
  Developing and implementing strategies to mitigate or avoid identified risks is essential. This can involve various techniques, such as contingency planning, early stakeholder engagement, discovery, usability testing, and learning through testing and building.
• 4. Communication and Collaboration:
  Maintaining open communication and collaboration among team members, stakeholders, and relevant parties is vital for effective risk management. The bigger the risk, the more it should be known and talked about. Minimizing risks is an anti-pattern that should be avoided.
• 5. Monitoring and Review:
  Risk identification and ordering isn’t a historical document - it’s a living, breathing artifact. Regularly monitoring and reviewing identified risks and their associated mitigation strategies is necessary to ensure their effectiveness and adapt to evolving circumstances.

Why is Steering into Risks Important?

• Reduced Product Failure:
• Proactively managing risks can significantly reduce the likelihood of product failure, saving time, resources, and potential setbacks.
• Improved Decision-Making:
• Understanding potential risks allows for better-informed decision-making throughout the product development lifecycle.
• Enhanced Product Delivery:
• By mitigating risks, teams can deliver products more reliably and on time, leading to greater customer satisfaction.
• Cost Savings:
• Addressing risks early on can prevent costly rework, delays, and potential losses.

Examples of Risks and Mitigation Strategies:

Market Risk

What if nobody wants what we’re building—or they want it for reasons we didn’t expect?
Market risk isn’t just about whether a product will “sell”—it’s about whether it solves real problems in a real context. It’s easy to build for our own internal assumptions or the loudest stakeholder voice. It’s harder to build something people actually adopt, use, and love.

Mitigation Strategies:

• Test the problem, not just the solution. Before validating a feature, learn a lot and validate the pain point. Do users recognize it? Do they care enough to seek out a solution?
• Go and See. Talk to real users early and often. Don’t wait for a “beta launch” to learn how your product lands.
• Apply Multiple Methods. Use clickable mocks, wizard-of-oz flows/smoke and mirrors, wireframes, or other lightweight tests to get feedback fast.
• Use structured research, not gut feelings. Leverage frameworks like Jobs-to-be-Done, opportunity solution trees, or assumption mapping to reduce blind spots in your reasoning.
• Measure intent, not just opinion. Surveys and interviews are helpful—but when possible, look for behavioral signals (e.g., pilot usage, conversion from emails, demo signups) that indicate genuine interest.
• Stay Curious. Be especially cautious of confirmation bias when early data feels too validating. Steer into the risk by looking for disconfirming evidence.

Resource Risk

You might not have the people, skills, or time you think you do.
Resource risks often masquerade as over-optimism: we think we’ll get more time, better velocity, or fewer distractions than reality allows. But products are shaped by the actual team in the building—not the hypothetical one in the planning doc.

Mitigation Strategies:

• Surface constraints early. Identify critical skill gaps or bandwidth issues and make them visible to stakeholders.
• Rethink scope before you rethink people. If resourcing is tight, recalibrate the product goals rather than expecting heroics.
• Borrow, don’t build. Look for ways to reuse existing assets—code, content, processes—before committing to net-new investments.
• Deliver value in thin slices. Build small, demonstrable increments that validate assumptions and reduce the cost of technical surprises.
• Staff for the problem, not the org chart. Bring in external partners, rotate team members, or create cross-functional teams to solve specific challenges.
• Track actual velocity—not ideal velocity. Use real throughput data, not wishful thinking, to guide estimates and resourcing decisions.

Technical Risk

The technology might not work as expected—or at scale.
Technical risk can come in many flavors: new or unproven technologies, third-party integrations, brittle architecture, performance bottlenecks, or places already in need of technical investment.

Mitigation Strategies:

• Test for failure, not just success. Run resilience and edge-case testing, not just happy paths.
• Spike early and isolate the unknowns. Prioritize technical discovery and prototyping to de-risk feasibility.
  Invest in observability. Instrument the system early so issues can be detected and diagnosed quickly as the product evolves.
• Don’t go it alone. Leverage existing libraries, vendor partnerships, or proven architectural patterns rather than reinventing everything from scratch.
• Deliver value in thin slices. Build small, demonstrable increments that validate assumptions and reduce the cost of technical surprises.

Conclusion

Ultimately, steering into risks means focusing on the “monkey” first. By identifying and addressing the most significant uncertainties early in the product development lifecycle, we ensure that our efforts are directed towards solving the core challenges, rather than building elaborate “pedestals” that serve no purpose if the foundational problem remains. This proactive approach saves resources, improves decision-making, and leads to more successful and impactful products.