As the father of young children, I can tell you that there is a special place in my heart for restaurants that provide puzzles and crayons for small children to pass the time.

On a recent trip out to The Counter in Mountain View, Jordan (who is 8) was really struggling with a large maze puzzle on one of these activity sheets. It was a fairly large maze, and he was frustrated by his inability to see the dead ends ahead, forcing him to retrace his somewhat tortured crayon path.

I told him to try to solve the maze backwards.

As you can probably guess, he began at the end, and was able to find a path back to the beginning in just a few seconds . He was delighted, and a bit surprised, to see how simple the puzzle looked like from a different perspective.

Surprisingly, I find that both entrepreneurs & product leaders miss this important lesson when evaluating ideas for either their company or their products.

Three Questions in Product Prioritization

In my experience, there are three common questions that often come up when product features are being debated:

1. Should we build this?
2. When should we build this?
3. How should should we build this?

Unfortunately, even highly talented teams can become get bogged down in debate and uncertainty when all of these questions become entangled. As engineers & designers are professionally trained to answer the question of “How,” the worst debates tend to happen around the questions of “Should” and “When.”

Too often, when debating what feature to work on next, debates around timing quickly devolve into debates about whether the feature is needed at all.

Solving the maze backwards does a fantastic job of disentangling these two questions. Simply asking the question of “If we are successful, will we have this feature in 3 years?” tends to illuminate whether the debate is about “Should” or “When.”

If the answer is yes, you will have that feature, then the question is simple. You are just debating priority.

Avoid the Local Maximum

One of the well known issues with iterative processes for delivering product features is the “local maximum” problem.

The assumption is that where ever you start with your product, your team keeps working on improvements. Each improvement is measured to ensure it is “better” than the product before the change. However, you can reach a point where every change you make hurts the metrics that you measure. The fear is that there is a better version of your product (the absolute maximum), but it requires a change bigger than you can get to from the current design.

It’s called a local maximum problem because of the similarity to the concept in mathematics when you are traveling along the curve. From the local maximum, every move is down, even though the curve ends up higher eventually.

Solving the maze backwards can help.

By asking the simple question about whether or not your product in the far future has a given capability, it can unblock your thinking about what leaps and changes will be necessary. Whether the limitations are in technical architecture or product design, clarity on your long term vision can help your team visualize a future not trapped by their current constraints.

Too often, the real limitation is not related to either technical or design constraints, but rather a lack of clarity and imagination about what might be possible. Just like a maze, it is easy to get lost in the middle. Thinking backwards from the end goal can help the team escape a Zeno’s paradox of minor feature improvements.

Founders Can Solve the Maze Backwards, Too

It may seem hard to believe, but in early 2009 when I took over LinkedIn’s mobile efforts, there was still active debate within the company about whether to dedicate significant effort to mobile. Why? Well, back in 2009, the Blackberry was still hitting record sales, the app store was a year old, and from a web metrics point of view, mobile views represented less than 1% of LinkedIn’s traffic. Like every hypergrowth startup, LinkedIn had a huge number of initiatives it wanted to pursue around growth, engagement & revenue, and it wasn’t obvious that mobile would move any of these needles for the company in the next few years.

Solving the maze backwards helped.

What was fairly obvious in 2009 was that the growth rate of mobile engagement was compounding at a phenomenal rate. LinkedIn, as a professional use case, might have been slightly behind social use cases for mobile adoption, but it was fairly clear that within 5 years (by 2014), mobile should represent a majority (over 50%) of all visits to LinkedIn.

Thinking backwards helped give us the confidence to invest in both talent and technology that had little short term payoff, but would become essential to engagement over the next five years as those predictions came true.

Fast forward to 2017. I was recently meeting with a founder who was debating whether they should hire a Vice President of Marketing. As he walked me through his thinking, the argument wandered, and became more focused on whether or not the company “needed” marketing.

I asked him if there was any way, if the company hit their numbers over the next three years, that the company would not need marketing, or an experienced marketing leader?

The CEO quickly responded that marketing would be essential to hit the numbers they were looking for in three years. All of a sudden, the conversation changed. The question wasn’t whether or not to invest in marketing, but more a question of when they need to. Was this a 2017 or a 2018 problem? Is this something they would need to hit the milestones to raise their next round of funding, or something that they would invest in during the next cycle?

It was now a question of when.

Questions of “Should” vs. Questions of “When”

“The essence of strategy is choosing what not to do.” — Michael Porter

Being clear about what your product will and won’t do is a critical element of product strategy. However, because it is so important, even well-meaning teams can turn almost any feature into an existential debate.

Thinking backwards can help differentiate questions of “should” from questions of “when,” and that can be incredibly productive in moving the discussion to prioritization.

This is not intended to be dismissive of questions of prioritization. Phasing decisions are some of the most important decisions start ups make. Financing for startups is phased. Small teams can only work on a few projects at a time. Customers can only absorb so many new features at once. As a result, prioritization decisions are incredibly difficult to make.

Greedy algorithms are very good, but can be traps if you are working against competitors and an ecosystem that is willing to make bets that lie across the gap from your product’s current local maximum. Thinking backwards can help illuminate long term goals that are across the gap.

When you are building a product roadmap, and get stuck on debates about a short term feature that doesn’t move the numbers, I encourage founders to take a moment and try to solve the maze backwards.

It worked for Jordan, right?