Sufficient vs. Necessary

 

When reflecting on all the past successful and failed projects that our team had invested in. I wanted to find some common patterns, some framework for me to reason about the success and the failures, such that I can establish some principles to determine how to invest in a project in the future. Then the very simple concept of necessity vs sufficiency came to my mind.

Using plain English, if we have a Goal A, where A can be very concrete things like launching a product or hitting a KPI. It can also be abstract concepts like "enable contextualized AI for all humans".

• If X is Necessary for Goal A, then A can not be achieved without X.
• If X is Sufficient for Goal A, then if X is achieved, Goal A is guaranteed to be achieved.

If we use them to divide the space into the 4 quadrants (a method that I described in this note), I can map some of our past work into them. Through this process I have had some very interesting reflections that I thought might be useful to share.

Sufficient and Necessary

The interesting nuance in this quadrant is that you might think if the goal is trivial, then it's usually easy to find sufficient and necessary solutions to the goal. But it's quite the opposite, when the goal is trivial, there are usually multiple ways to go about it, therefore all of the options are sufficient but not necessary. As the goal becomes more ambitious, the option space will become smaller and smaller and at some point, it will reduce to a single solution, and that solution is both sufficient and necessary.

For example, (assuming the world-locked rendering is a solved problem) if the goal is to "Render anchored AR content on a poster" (trivial), then there are many potential solutions that are all sufficient: homography tracking, open-loop VIO or a full-on SLAM system etc. However, when the goal becomes "being able to render anchored AR content everywhere in the open world" (ambitious), then always-on location technology becomes sufficient and necessary.

Takeaway: jointly optimize the definition of the north-star goal and the technology investment such that the investment is both sufficient and necessary.

Not Sufficient but Necessary

This is the quadrant that we usually overlook, since usually work that falls in this quadrant is not the most shiny thing. However, by definition, these are the work if not done, the goal can not be achieved. The Necessities are the root nodes of a dependency graph, so priority-wise, they should be nailed as early as possible, before moving to solving any downstream problems. Bypassing, or not fully solving a necessary step will almost always lead to a substantially harder if not unsolvable problem downstream.

For example, sensor calibration is a necessary problem to be solved for almost any machine perception task. Without proper calibration, the downward tasks either need to simultaneously solve for the calibration or the task just can not be achieved at all. 

Takeaway: always pick the necessary "low-hanging fruit" first before jumping on the shiny things.

Sufficient but not Necessary

This is the space where system 2 thinking is needed the most. It's easier if the team only aims for the north-star and doesn't care about near-term proxy goals and milestones: they just aim for the sufficient technology. But without an interactive process to gain knowledge and measure progress, the team might run into random walk. Therefore near-term, concrete goal definitions are very valuable for long-term research. As described previously, near-term goals usually have multiple solutions that are sufficient. How should we pick which one to go about? Well, the answer seems obvious: aim for the solution that is both sufficient for the near-term goal, as well as aligned with the long-term goal.

Using the example in the first section, for rendering AR content on a poster, the long-term extension of the goal will be to be able to anchor AR content on anything. Therefore we should lean towards not choosing the homography tracking solution, since it's not aligned with the long-term goal (unless there is additional shipping time constraint that makes it both sufficient and necessary). We should instead aim for solutions that have a path towards the long-term, like using VIO + relocalization or a full-on SLAM system.

Takeaway: Pick the good "Overkill" solution that is sufficient to the near-term goal, and is aligned with the long-term goal.

Not Sufficient AND not Necessary

Obviously, no one wants to work on things that are neither sufficient nor necessary, but .... is it really obvious that something is neither sufficient nor necessary? From my experience, the answer is no. As an R&D team, we are naturally excited about building new things, the confirmation bias usually drives us to use the future speculative state of a technology to justify the investment. A typical failure pattern is to claim that the future form of a tech will be both sufficient and necessary for the ultimate goal, but the near-term state of that tech is neither necessary nor sufficient for any proxy goals that are on the path to the north-star goal.

For example, my team had invested in building general services and platform features that was meant to be used by many teams across many use cases, they are meant to be both sufficient and necessary in the future, in its ultimate form. However, many projects have died in the bootstrapping phase since they are neither sufficient nor necessary for any near-term customer needs.

Takeaway: Avoid the misstep. Critically look at whether a project is sufficient or necessary. Don't use the future speculative state of the project to justify the investment. A tech needs to be at least sufficient for a near-term proxy goal (which is on the path to the long-term goal) to be worth investing in.