One of my favourite things from the month has been the launch of Google DeepMind’s Nano Banana. Aside from an awesome name, it has been called a Photoshop killer due to its advanced image editing capabilities.
Yeah, those capabilities are phenomenal, but I think they distract from what is truly mind-blowing: Nano Banana has an understanding of the way the world works, that is being expressed via images, but goes much deeper.
For example, here is a Google Maps image of the MISSION+ Singapore office with an arrow drawn on it. Nano Banana is then asked to generate the image that would be seen by someone standing in the map and looking along the arrow:
The details are wrong - but it’s still pretty clearly Singapore heritage buildings (which is correct).
Or we can provide a picture of someone in an outfit, then ask the model to isolate the various pieces of clothing and generate an aerial image of the pieces folded up on a table.
This isn’t just image editing, there is a sense of hidden understanding - we’re a long way from the stochastic parrot. Yes, these models don’t “understand” the world in a conventional sense, but their world-modelling demands a new word. The noesis? The gestalt?
You can feel the understanding-but-obviously-it’s-not-real-understanding - the noesis - when GPT reframes a complex topic with a metaphor that makes more sense to you. In my mind, Nano Banana shows the strongest noesis yet - truly a different animal.
Want more examples? Here you go: Google Nano Banana is WILD - 50+ Use Cases
MISSION+ Update
We’re very excited to announce that our office covering the GCC region is now fully operational in the Dubai International Financial Center Innovation Hub.
Come along to our Launch Day - we’ll be discussing the MISSION+ Principles, the future of work, and a showcase of AI in action.
Reflections On The Mission
Take a look under the hood of most newly successful products, and the tech is usually less sophisticated than one would expect. In some - many, even - cases, it is downright scrappy. Why is that?
During World War II, the US Military analysed bullet holes on returning planes to see which areas were being hit, and therefore where they should add reinforcing armour for protection.
The reasoning was flawed. They were only analysing the planes which had survived - perhaps the areas with no bullet holes were because those planes were always destroyed. This is called ‘survivorship bias’.
In the same way, when we look at successfully scaling products, we may assume their messy stacks are mistakes to avoid - when in fact, they might be partly the very reason they survived. A lot of our “best practices” are lessons learnt from companies that have had to adapt to massive scale. They simply do not apply to many other companies and products.
The language we use sometimes betrays us. We talk about being careful to not apply them “too early” - this presupposes that they are the correct lessons, it’s just a question of timing. This is not true - there are some use cases that should always have a simple architecture. We should celebrate that for as long as possible, not itchingly await when we can finally split up into microservices.
The overhead of doing everything with “best practices” is larger than we imagine - just like the communication overhead of large teams can overwhelm any sort of progress. If the product is for a startup, there is a good chance you will run out of money and simply die before you get there. If the product is for a large company, the risk is a delay in “time to value” - which may lead to the project being cancelled, or a loss in faith from leadership.
I previously wrote about some of this in Uncomfortably Simple - and here are some of the common arguments given:
The flip side to “best practice” always being good is “technical debt” always being bad. Not so. Many companies borrow capital in order to grow, it’s good business. You just need to make sure the interest payments are manageable.
That debt might be the key to user acquisition, which leads to growth, and in turn profitability. The debt free product that dies with no users may well as never have existed at all.
If you’re building a skyscraper, it is imperative to make mature architectural choices from the beginning - there is no way to redo the foundations. But most of us are not building skyscrapers (as much as we like to believe we are), and will necessarily pivot and adapt to user feedback. For this simplicity is key - and if users start onboarding faster than can be solved by just throwing larger hardware? An investor will pay you to solve that problem.
So the next time you see a rapidly scaling product’s tech stack and scoff at how you would have done it better - remember survivorship bias and that survival itself is proof that they did something right.
Interesting Articles
- AWS in 2025: The Stuff You Think You Know That's Now Wrong - A nice summary of things about AWS which everyone knows… but are wrong.
- DevGenius - AWS Solution Generator - describe your problem, and get a suggested AWS architecture in return.
- In honour of Airbnb co-founder Joe Gebbia joining the US government to redesign their web sites, here are Government Design systems from:
This Is The Way
Feature A Fractional
We’re On A Mission
Until next month. Together, We Build {+}
Ned & the MISSION+ team
P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to [email protected]!
