I came across the narrative of putting monkey first when I read Ozan Varol's Think Like a Rocket Scientist book. It means tackling hard problems first (or early), instead of focusing on the easy and obvious parts of the problem and deferring hard problems for later. The "monkey first" narrative originally came from Astro Teller: https://blog.x.company/tackle-the-monkey-first-90fd6223e04d. Here are more details if you haven’t heard of it before:

You have just been put in charge of a particularly audacious project at work. Your boss says you have to get a monkey to stand on a pedestal and train it to recite passages from Shakespeare. How do you begin?

If you are like most people, you begin with building a pedestal. At some point, "the boss is going to pop by and ask for a status update," as Teller explains, "and you want to be able to show off something other than a long list of reasons why teaching a monkey to talk is really, really hard." You would rather have the boss give you a pat on the back and say, "Hey, nice pedestal, great job!" So you build the pedestal and wait for a Shakespeare-reciting monkey to magically materialize.

But here's the problem: Building the pedestal is the easiest part. "You can always build the pedestal," Teller says. All the risk and the learning comes from the extremely hard work of first training the monkey. If the project has an Achilles heel—if the monkey cannot be trained to talk, let alone recite Shakespeare—you want to know that upfront.

What's more, the more time you spend building the pedestal, the harder it becomes to walk away from moonshots that shouldn't be pursued. This is called the sunk-cost fallacy. Humans are irrationally attached to their investments. The more we invest time, effort, or money, the harder it becomes to change course. To counter the sunk-cost fallacy, put the monkey first—tackle the hardest part of the moonshot up front.

My team owns an internal platform used by thousands of internal teams. When we build things, we focus on finding the biggest and most complex customers so we can prove the product's value early on. Sometimes, these big customers won't prefer being the first (as it might be risky), so we will create the fastest way to convince them. We achieve this by rolling out critical functionality such that most of the risks they were worried about are addressed, and the value is proven. The obsession with going after the most complex problems requires courage, but it has a resounding impact and builds trust with customers, which is hard to earn iteratively. It also gave a lot of leverage early (proving the most complex use case early meant other partners had no excuse not to join forces with us).

If we had played safe, it would have easily taken a few more years for some projects to complete, and many other innovations would have slowed down across our ecosystem. Of course, it is easier said than done as someone (and in reality, multiple leaders in the team) needs to lead from the front and have deep conviction. Then, you need a team that is not afraid of taking risks and tackling hard problems. This approach creates a positive flywheel in the long run and boosts the team's morale and confidence, enabling them to tackle even harder problems. This is where there is also a tenet around "Technically Fearless" for the Principal Engineer role at Amazon.

Now, there is also the opposite side to it, which is called "chasing ghosts." I have found the best way to balance against that is to define a vision and ground it with real customer requirements (working backward) so you are not chasing mythical ghosts but real delightful things for our customers.

So, tackle the hard problems first.