Planning Vs. Action: Why a Product Team’s Best Bet Is Real-world Evidence

Stop spinning your wheels.

“We prioritize all of our work before each quarter based on our intake prioritization spreadsheet. To make it into a quarter, work must rank high enough on the scale.”

Imagine having a real, urgent customer need to solve only for it to get stuck in a prioritization intake funnel. It’s where legitimate value often goes to die.

RICE, MoSCoW, Kano, WSJF, and OKRs. You want a prioritization framework? We’ve got your prioritization framework.

Prioritizing based on perceived value feels like the right answer to achieving outcomes with limited capacity. But it’s a trap. We assume more thinking and planning up front equals better results.

Spoiler alert: it doesn’t.

As a product leader, would you bank your career on ranking your best move and hitting a home run on your first swing?

Many do. And many swing and miss. Whiff.

What’s a better way to the outcomes you desire than lengthy planning and prioritization? Keep reading. I’ll explain why action and evidence is superior and guide you step-by-step through the process that I use.

Why do we default to elaborate planning and prioritization devices?

We think that more evaluation and planning will help us hit the bullseye on the first try. But let’s be honest, this is like trying to hit a moving target in the dark.

As I write that, I’m struck by how risky perfect aiming is. But it seems reasonable to many of us in the midst of product planning. After all, it works for simple tasks. If I need to walk my dog, fix my breakfast, and change my baby’s diaper, I can easily decide what should come first. The screaming baby and unpleasant smell is a clear signal.

But software development is not so simple.

• Will the technology even work?
• How long will this take to build?
• How much will this cost to build?
• Does the team know how to do this?
• What feature will solve the user need?
• Which user’s needs should we address first?
• Which solution will a user use and keep using?
• Will our features have the desired business impact?
• Will this technology create the experience users desire?
  

Complexity and uncertainty abounds. No one has ever built the same product twice with the same team using the same technology to serve the same users.

Product work is a creative act. Every time.

Our thinking mistake comes along with our human nature.

We desire certainty. And we trust in our ability to control our path. It’s this deep-seated mindset that fools us into thinking we know what we are doing.

But with software product development, control is not an option.

We don’t know what will work until it does.

We forget that we don’t know. Our ego gets in the way and fools us into believing we can predict what will work up front.

Product work suffers the same fate as any other creative act.

Many variables out of your control play into the outcome.

Take my writing for instance.

I can spend countless hours brainstorming, outlining, and perfecting every sentence. Yet, I have no guarantee it will resonate with readers. It’s a shot in the dark.

I won’t know if my style and words will appeal to my reader beforehand. I would be a fool to bank on my effort getting praised because I tried my best. Nobody cares about my effort. What matters is how what I produce meets a reader’s need. And this is impossible to know ahead of time.

Yet, I often fall into the trap of putting too much faith in what I produce.

I forget I’m not in control of the outcome.

No matter how perfect my article, the reader (user) is the ultimate judge. And I can’t predict the verdict up front.

The same goes for product. Our users decide the worth of our effort.

Sometimes, we also put too much faith in upfront discovery and research.

To combat uncertainty, we often double down on customer research.

This makes sense. We can better understand our users’ needs through research. And if we put options in front of them, our chances improve for delivering something useful.

But it’s far from a slam dunk.

Before we know it, we fall into a trap of second-guessing every step we take. We start checking everything with our customers before making any move. The result: we freeze up in analysis paralysis and delay getting to a real answer with action.

I’ve made this mistake plenty of times.

• Spending months talking to users
• Testing out elaborate working prototypes
• Creating buzz with beautiful mock-ups and glitzy video reels.
  

My most spectacular failure was creating a 1000-page visual style guide. A major mobile phone maker had hired us for their rebranding effort. It took my team of 30 people over a year and millions of dollars to perform research and produce the guidebook. Then what happened? The economy tanked and budgets evaporated. The beautiful style guide found its place on a shelf to forever collect dust.

I learned a great lesson.No amount of upfront planning, design, research, and trial runs will get us closer to the results we seek.

Why double or triple the effort with nothing but a plan to show for it?

You won’t know if you have a hit until what you build is in the wild. The quicker and cheaper you can get there, the better.

My 3 Steps to Favor Action and Real-world Evidence Over Prioritization and Planning

The solution to avoid the trap of too much upfront aiming is simple.

But it requires us to stop our obsession with prioritization spreadsheets and planning. And this is not easy. Entire organizations exist to do this today. It’s a big beast of an engine.

Changing embedded beliefs and behaviors is never a walk in the park.

Coupled with the loss of (fake but perceived real) control, this habit will not go down easy.

But if you are willing to give evidence a try, you will see how much better it is. And your customer will delight in your ability to solve their problems sooner.

Intrigued? Let’s walk through the steps.

Step 1: Go observe your customer in action before you take action.

Even though it’s not foolproof, you should still engage with your customer first. Otherwise, you will be throwing spaghetti at the wall to find what sticks.

You need to dive into your customer’s world to gain valuable insights.

If you know what you’re solving, you’ll improve your chances of delivering something useful,

Knowing your user means standing in their shoes.

I like to immerse in the world of my users.

To do this, I’ve used three levels of engagement, each building richer context than the prior:

1. Asking them to walk through their process and pain.
2. Sitting beside them for a day and observing their struggles.
3. Performing their job for a few days to gain extreme context.
   

While level 3 is the most helpful (by a mile), any of these beats having no user exposure before building. If you stand in your user’s shoes and feel the pain, you’ll know better what will work and what won’t. Your solutions will be more useful.

You aim better by experiencing your customer’s pain.

But you shouldn’t become too confident and make the mistake of overbuilding, which leads us to step 2.

Step 2: Try out a good solution in a small, cheap way.

Your initial brush with experiencing a day in the life of your user is great, but it’s only one data point.

You likely have hundreds or even thousands of users. Each has unique situations and preferences. So, the answer is to start modest, and see what works.

Good beats perfect as your starting point.

Start with a small, low-cost experiment. Think of it as a minimum viable attempt.

This way, you contain the risk of wasting your effort by delivering the wrong thing. And it’s much easier to discard the wrong move when you haven’t poured your heart and soul into “betting the farm” on a solution.

Avoid the perilous prototype path.

I’m not a big believer in building prototypes. Prototypes have several deficiencies:

• Most aren’t built with internal quality in mind, so they are throwaway.
• You’ll burn effort and time, guaranteed, because you discard them.
• They don’t match what it’s like to use a real system in the wild.
  

Why would I build a prototype when I know it’s a pale substitute?

Don’t get me wrong. Some lightweight “paper” prototypes can help you test out ideas quick with your users. They are easy to make and easy to toss once you have the learning.

But I’ve seen many prototypes take weeks or months to build. That’s a ton of effort and time to burn, knowing we will trash it at the end. I’ve come to avoid elaborate prototypes for these reasons.

Instead, I build a working version from the start.

My teams build the first version of a feature good enough to work and for actual use in the real world.

It won’t have all the bells and whistles. But it works for a common use case.

This way, our effort has a chance to be usable, used, and useful. And if it’s not, we don’t mind throwing it away because we did not swing for the fences out of the gate. This puts learning first and saves us from burning our precious time and energy on a prototype.

Build it for real, but keep it simple and malleable from the start.

This leads us to our final step—iteration.

Step 3: Iterate based on real-world results, and then stop when good enough.

Expect to iterate many times. Even the best ideas need refining before they hit the mark.

This is the harsh reality many of us don’t consider when we are toiling over prioritization and planning. Even if we know our users and the pain they face, we still have this uncertainty.

Remember, we don’t know what will work until it does.

And don’t forget about luck.

Being in the right place at the right time plays a big part in your success.

We don’t like to hear this, because it means we don’t have control. But it’s our reality.

Being ready for luck means not wasting time on intricate prioritization and plans. If luck comes around and all you have is a prioritized backlog, you just missed the boat. All you can do is wave and jump around pointing at your spreadsheet while your ship sails to the horizon.

You want working solutions. These have a chance to meet luck when it arrives.

My teams are often shocked at what ends up working and being “enough.”

In our minds, we imagine a palace on the hill and fancy awards for our skilled craftsmanship.

But in reality, our users don’t need a palace. They want basic shelter and something that makes their work less painful. And this often requires much less than we think it will.

Remember, the best thing we can imagine is often not right. It’s not what our users need in the time that they need it. You can always add more. But it’s much harder to undo excess.

So, start small.

Make many tiny moves until you find what works.

Evolve it until good enough.

And stop.

---

That’s it. This is how I bet on reality instead of upfront prioritization and planning.

Many organizations spend more time planning and prioritizing than evolving real things. Don’t waste time attempting upfront precision to measure twice and cut once. Product work is not as simple as woodworking.

Three simple steps can help you use humility to arrive at the right solution sooner:

1. Step in your customer’s shoes.
2. Build a simple, cheap, working, first solution.
3. Find what works, iterate, and stop when good enough.
   

A learning-forward approach like this helps you be ready when luck shines your way.

Are you courageous enough to leave prioritization and planning behind? Can you take that first simple step into action so you can find what works? Will you be ready to meet luck when it arrives?

I know it’s scary. But it’s worth it for getting to useful solutions sooner with less wasted effort. It’s a better path for you, your team, your customers, and your organization.

Simple, real, repeated action, evidence, and learning win in the end. Good luck out there.

---

➡️ Sign up for weekly tips like this on doing more with less while respecting people.