Navigating the JFDI Problem: What to do when you’re told to design and build a preconceived solution

A gut-punch for product teams

In my coaching conversations and workshops with Product and UX people, one challenge crops up more than any other - the “JFDI” problem.

This usually occurs when a senior individual, outside of the product team, prescribes a solution to be designed and built — no discovery research, no exploration of alternatives. Just get it done, and the sooner the better.

For the product team, this is far from ideal,  for several reasons:

1. It’s likely to be a waste of time. It’s an inconvenient truth that most ideas for new products, features, or enhancements, won’t have the desired impact - especially if they don’t originate from insight into users and their needs. That’s why we do discovery work to improve the odds.

2. It’s stopping you from doing that other thing. There's an opportunity cost - other important work will need to wait while you accommodate the new initiative.

3. It undermines the team’s autonomy. Good product people prefer to be tasked with delivering business outcomes, not solutions specified by others. Being told what to do feels belittling and demotivating.

So how should we respond when the dreaded “JFDI” rears its ugly head?

Focus on what's in your control

Firstly, it’s good to remember that you are not alone. It’s a common challenge, particularly in less mature product organisations.

It’s also understandable. Founders find it hard to let go of product decisions. And executives are bound to propose strategies and ideas which sometimes impact the product roadmap.

As product organisations mature it should happen less often, but it takes time to build trust and change ingrained habits.

So we have to be stoic about it, and consider what’s in our control and how we can best respond.

Try these steps

While every situation has its nuances (feel free to book a call with me to discuss yours), here are some steps I recommend:

1. Identify the goal 

There has to be a reason someone wants you to build this thing. So make sure it’s explicit. 

Ask “What do we expect to achieve by building this?”

They may look at you funny and say something like “Well, sales obviously”. 

But don’t give-up there. 

“Of course. But join the dots for me. What specifically do we expect to happen as a result of this change that will result in more sales?”

Ideally you’ll get as far as metrics. 

“OK, so we’d expect to see the average basket size increase? What change would we hope to see in that metric over, say, the first 6 months?”

How hard you push is up to you. But try and get to some concrete predictions about the difference this initiative is expected to make.

By shifting attention to the goal rather than the solution you are then able to 

a) check that the goal is indeed top priority right now   

b) open up a discussion about other potential solutions that may be less disruptive

It also tees up the next step…

2. Highlight assumptions

For a solution to succeed, lots of things need to happen. You’ll need to design and build it in a reasonable amount of time, and enough users will need to interact with it in a certain way - reading, sharing, buying etc.

Run a short session to identify and map out these assumptions, and highlight the most risky ones.

Note - This exercise should be standard practice, regardless of where the solution idea originated.

3. Remind them of the opportunity cost

People outside the product team will forget about all the good stuff you already had planned and the benefits you expect to see from it. So remind them what they’re giving up. You might say something like

“Taking this project on will delay X project by Y time, meaning we won’t see Z benefits until Q2 next year. Are we all comfortable with that?

The decision may stand, but at least the tradeoffs are understood and expectations are managed.    

4. Get a formal go-ahead

Assuming your stakeholder is still committed, summarise all the above in a project brief and ask for formal agreement to proceed. 

In doing so, you are asking them to take their share of the responsibility for whatever happens next.

In conclusion 

The JFDI is never welcome, but it does happen, and sometimes for good reason. What matters is how you handle it. 

By clarifying goals, highlighting assumptions, reminding people of the opportunity costs, and ensuring responsibilities are clear, you'll make people think more carefully about the decision. And you might find some ideas are quietly shelved.

But even when they aren’t, taking these steps will provide your stakeholders a better understanding of good product development practice. This will build your team’s credibility and perhaps reduce the likelihood of the JFDI happening again.