Product Management: low-hanging fruits are poisoned

A quick guide for Product Managers and Business people to get priorities right and avoid playing a lose-lose game

Some expressions, jokes, and ways of working are part of company slang and just feel normal “corporate life”, doesn’t matter the company or industry you work for. One of those expressions is “Low hanging fruit” (LHF). 

Let me say it straight, I have a big issue with this expression. In this note, I am putting together a set of thoughts and real-life examples I collected on this topic over the years. I have witnessed too many ill-fated decisions in good part taken due to a “low hanging fruit” reasoning. And for many people working in product management, this is daily business.

Low-hanging fruits and Product Management

The low-hanging fruits analogy is used in different contexts and industries. I believe those you hear about in product management and software development are the most vicious and poisoned. As a Product Manager, you’ve probably already been asked to do something just because it is a “low-hanging fruit” (LHF).

While this is a multidisciplinary topic (and strongly related to the art of prioritization) affecting product managers, decision-makers, developers, and product teams, I am intentionally organizing this article in a way that speaks to business people first. 

As a Product Manager, you’ve probably learned and hopefully mastered the art of prioritization. You know too well that trying to get too many things done at once, or tackling topics and opportunities as they come, is a recipe for disaster. You’ve probably put in place a nice framework (RICE/ICE/…) to score the opportunities and find out what to do next. Hopefully in your organization (almost) everybody understands the reasoning behind this prioritization and everybody, including business and management, is so happy that we finally can prioritize! Yeah! Great, right?

But then, all of a sudden, kind of out of the blue…. Sure, prioritization is still important. Sure, there are tons of things contributing to our metrics and goals. Sure… but… you know, this one feature is just a low-hanging fruit! You don’t want to miss it, do you? Somebody dropped the “Low hanging fruit” card and .. end of the discussion. 

As I will argue in the next paragraphs, playing the LHF is a lose-lose game, and the ones pushing for shortcuts (usually, business stakeholders) will often be shooting in their feet.

But first of all, what are “low-hanging fruits”?

The analogy with a tree is pretty straightforward: why bother getting on a ladder and get the fruits on the top, when you can get the easier-to-catch, and equally tasty, fruits hanging from the lower branches? 

Sounds pretty logical, isn’t it? Well, let’s start with the two keywords that pushed us to go for these fruits: we said, “tasty” and “easier to catch”. But is it so? 

Tasty but poisoned (aka the Value)

Let’s take an objective look at it. The classic “Value vs Effort” representation provides a formal way of prioritizing, telling apart what “brings good value” to the business and makes sense to be pursued. Pretty much everybody is familiar with a diagram like this:

By “low-hanging fruits” people usually refer to the top-left area, aka “High Value / Low Complexity & Effort”. So far, so good. Top Right is usually referred to as “Moonshots”, big opportunities that require a dedicated and significant effort, probably not what you want to start with. And of course, nobody wants to do high-effort, low-value work, right?

To be clear, this reasoning makes a lot of sense. This matrix is just a visual simplification of a more structured or quantitative prioritization frameworks like ICE (Impact / Confidence / Ease ). 

So, what’s wrong with it? Here we come. While in theory you want to be looking at Value + Effort jointly, evaluating the value is much more difficult than evaluating the effort. Or at least, that’s what our brain believes and naturally tends to do.

So, by seeking “low-hanging fruits” you’re mainly putting the accent of your evaluation on the “easiness” part. You’re postponing the evaluation of the value (is it worth it? Does it make any sense or a difference for our business?) because you get dazzled by the “How easy it is to do”. As proof of that, when somebody tries to convince you that Feature X is a low-hanging fruit… does (s)he usually start by explaining to you how valuable it is or… that it just takes so little time/effort to do? Here you have your evidence.

Again, doing easy things first is not necessarily a bad idea. It is actually a good idea in many cases (more about it later). The real problem is that here you’re just postponing (at best) or forgetting (most of the time) to take into consideration the value. Back to our matrix, your brain is now looking at the problem on one axis:

In other words, we believe that by doing low-hanging fruits we’re targeting the real “Easy Wins” that bring good value for effort, but in reality, our brain is creating a simpler model where the value (difficult to estimate) is blurred and the effort is the only thing we’re looking at. 

Easier to catch (aka the Effort)

I already mentioned that “easier to catch” is the other part of the definition that is problematic. 

But why are we so tempted by the “easy things”?  Let’s start with an observation: 

If you have a pile of different things to be done, starting with the quick & easy ones is actually good and will lead to the overall minimum average time for completion of your tasks. If you have a sequence of tasks of different lengths, starting with the easy ones will reduce the average time to completion and speed up the delivery of the value. This can even be proved mathematically, and a formal demonstration is a cornerstone element of the “queuing theory”.

Now, the problem is that this applies when the tasks you’re performing are all of equal importance and you can predict their duration (or effort).

We already saw that evaluating effort is something our brain finds more natural and easy than estimating value. Sure he does! But this doesn’t mean that he’s actually good at it! On the contrary, people tend to be overconfident, and optimistic. We tend to underestimate complexity and effort! This has a name, “Optimistic bias”, and its implication on software engineering is proven (For more about cognitive biases in software engineering ee for instance: “R. Mohanani, I. Salman, B. Turhan, P. Rodríguez and P. Ralph, “Cognitive Biases in Software Engineering: A Systematic Mapping Study,” in IEEE Transactions on Software Engineering, vol. 46, no. 12, pp. 1318-1339, 1 Dec. 2020, doi: 10.1109/TSE.2018.2877759” https://ieeexplore.ieee.org/document/8506423 ). 

In particular for software products that are somehow abstract and intangible, we’re easily blind to the real complexity of any addition or new feature. Also, software enables us to create things easier (at least, easier than in a “hardware” world). Still, the real cost of software is not the direct “development” cost, but rather the maintenance, operation, and overall product life. In other words, even “easy to build” features create Product Debt. 

And there is more than this. Because we didn’t estimate the value right at the beginning, chances are that we will not get any value out of the first iteration. Because we don’t have a definition of success, this “failure” will not lead us to objectively re-evaluate the situation, but rather to try to organically improve the solution. Rather than reconsidering the opportunity, we’re in reality increasing, even more, the effort. All in all, what was supposed to be a low-effort task, will most likely prove to be longer and more complex than anticipated. We’re shifting to the bottom-right quadrant, and doing what we would never have done if we had been considering the prioritization of the low-hanging fruit with a cold mind. 

Let’s put all this together. What is the consequence of our lack of judgment for effort, on top of the deferred judgment of value? At this point, you can’t trust th effort axis either and the prioritization decisions you were taking on the grounds of “easy and valuable” are likely to be neither of them. 

That’s what our mental prioritization schema looks like at this point:

We’re indeed blurring both scales; there are no borders anymore between what is an easy-win, and what is something else, potentially a plain waste of time.

Missing the point

There is another, less evident reason why the LHF card shall not win too easily. Optimizing for easy and valuable tasks or features is in general ok: but the reality is that a lot of what is NOT valuable but not easy is much more important in the long run. These may be entry barriers to your competitors. You don’t want to become a champion at easy things, but to start easy to build muscles for more difficult ones.

Prioritizing low-hanging fruit can be a hideout for more severe issues, such as the lack of a strong product strategy (moonshot): in this case, you will find yourself falling back on simpler topics. It is also possible that you do have a product strategy, but are still failing to break down (Pareto) your moonshot well enough to create easy wins that you can test iteratively.

Some practical tips to address the Low hanging fruits discussion. 

All this theory sounds reasonable and you’re most likely happy to apply it to your prioritization work. Nevertheless, you will still be confronted with situations where people (as in “business people ”, company leadership, sales, and customers ) will ask (more or less gently) to “do feature X because “it’s a low-hanging fruit”. So, what can you do?

First of all, you can bring a few of the elements you’ve read in this articleto the discussion.

In particular:

• Are we sure about the positive impact? Let’s imagine we have done it and now we have this feature: how is it impacting (positively our business)? And how are we ensuring people are using it? Pro Tip: Go the extra mile and start by creating 3 scenarios  (pessimistic, optimistic, probable) with real numbers.
• Is it really that easy? Perhaps it’s easy to do, but did we factor in the cost to maintain it (see my article on Product Debt)? Pro Tip: If you don’t have internal benchmarks, as a rule of thumb you can reasonably double the cost of your feature (this would help you take into consideration the additional 20%/year (industry accepted average) of maintenance cost) over a few years. 
• What do we do if after one week it proves not to be so… low hanging? Would we still do it if it took 2x the time/effort/money? When do we stop? Pro Tip: have a “kill by default” rule, where you decide before starting when to pull the plug.
• If this doesn’t work, you can try to move the conversation away from a “do or not do X”, in the direction of “X vs Y”. In other words, share the full reasoning about: “what if we do Y instead”? Would it bring more value?

Finally, and most importantly, sit back and relax. You’re not alone! But now you’re better equipped to handle these painful discussions and do something meaningful for your product instead. Next time somebody asks you to do something because it’s a “low-hanging fruit”… feel free to point him or her to these notes!

---

A big thanks to Julien and Eric for their review and countless suggestions for this article. 

---