Tale Of The Three Trees

How to Actually Use the Three Trees Framework for Project Planning

The Three Trees framework comes from an old sermon, but if you strip away the religious framing, what's left is a genuinely useful model for mapping ambitions against constraints. I started using it about four years ago when a stakeholder kept asking me to prioritize features that were objectively misaligned with our stated mission. It turned out to be the cleanest way to say "no" without sounding difficult. For people who haven't encountered the source material, the basic structure involves three trees, each with a stated ambition. The first tree wants to carry treasures. The second wants to sail the seas. The third wants to stand tallest on the mountain. Each gets cut down and repurposed into something entirely different from what they originally intended. The moral, in its original form, is that a higher plan was at work. In practical terms for project work, the takeaway is simpler: your initial ambition and your actual output will diverge, and that divergence usually contains useful information about what you actually value versus what you think you should want. Here's the part most people skip. The framework isn't about predicting where you'll end up. It's about mapping your starting point honestly so you can spot when the drift happens and decide whether it's productive or accidental.

I had a situation last year where our product roadmap was built around three clear ambitions, modeled directly after the three trees. Tree one was user retention. Tree two was revenue growth. Tree three was platform reliability. We ran quarterly reviews using this structure and it worked fine until Q3, when I noticed that Tree two was consuming 78% of engineering bandwidth while Trees one and three were getting scraps. The framework made the imbalance visible in a way that a spreadsheet never could. We reassigned two senior engineers and rebalanced within a month.

Setting Up the Framework for Your Own Use

The process is straightforward enough that I don't recommend overcomplicating it. Each tree needs a single-sentence ambition statement. Not a paragraph. Not a mission statement. One sentence that a teenager could understand. "I want to be the fastest checkout flow in the industry." That's a tree. "We aim to leverage synergistic paradigms to drive shareholder value through omnichannel integration." That's not a tree. That's noise that sounds like a tree. I've found that three is the hard limit. When I tried five trees on a team once, nobody could hold all five in their head during a sprint review, and the exercise became performative. Stick to three.

Step two: assign current resource allocation to each tree

This is where the rubber meets the road. Take your current headcount, budget, and engineering time and break it down by percentage across your three trees. Be honest about what you're actually spending, not what you claim to be spending. If you say 33-33-33 and your actual numbers are 10-80-10, you need to figure out why before you do anything else. Every quarter, revisit the resource split. Note where it shifted and why. A shift of five percentage points is normal noise. A shift of twenty points in one direction means something is breaking and you need to address it before the next planning cycle locks in the new baseline. I should be clear about the limitations because nobody else really talks about them.

The biggest issue is that the framework assumes your three trees are worth the same relative weight. They rarely are. In practice, one of your trees will always be the revenue driver that keeps the lights on, and treating it as equal to your culture or reliability tree creates tension that the model doesn't resolve. I handle this by adding a fourth implicit category I call "must not fail," which sits alongside the three trees but operates on a different decision logic. Things in the must-not-fail category get protected regardless of resource allocation math. Another failure mode is the drift illusion. Sometimes your resource allocation shifts dramatically and nothing bad happens. Maybe the revenue tree naturally grows when the market changes. Maybe the reliability tree got more work because you shipped a big feature that needed extra support. The framework will flag this as drift, but not all drift is failure. I've learned to distinguish between structural drift, which changes your fundamental operating model, and circumstantial drift, which is just life happening. Structural drift deserves intervention. Circumstantial drift usually corrects itself.

A Practical Example

Let me walk through how I actually use this in a working session. I brought it to a team last month for a product refresh. We spent twenty minutes defining the three trees on a whiteboard. Tree one: simplest onboarding in our category. Tree two: deepest integrations. Tree three: fastest page loads. We then did a quick resource audit and found that our design team was spending roughly 60% of their time on integrations, which was Tree two. Our backend engineers were split evenly between onboarding and page loads. Nothing catastrophic, but the design imbalance was worth noting. We didn't change anything that day. We just put the numbers in a shared document and scheduled a follow-up in eight weeks. When we followed up, the balance had shifted slightly toward onboarding, which meant our earlier hiring decision was having the intended effect. The framework gave us a signal without requiring any major course correction, which is exactly the right outcome. Most of the time these reviews result in minor adjustments, not dramatic pivots.

How This Relates to the Original Story

Returning briefly to the Tale Of The Three Trees for context. The original narrative follows three trees who each express a desire, get cut down, and end up serving purposes they never imagined. The first becomes a trough. The second becomes a boat. The third becomes a cross. In the telling, each ending turns out to be more significant than the original ambition. The framework's power as a planning tool comes from accepting that your original ambition might not be your final outcome, and building the discipline to evaluate whether that transformation is intentional or accidental. If you want the source text, it's widely available online. The version most people reference is Howard W. Hunter's 1987 speech, though the underlying parable is much older. Don't let the religious origin distract you from the mechanical utility of the structure. The three trees model has been useful to me because it forces specificity. Ambition statements tend to get vague when you're under pressure. This framework doesn't allow that. You either have a clear tree or you don't, and you know immediately when you don't. That clarity is worth the extra five minutes of planning work every quarter.