It’s so capable that they didn’t release it to the public.

Instead, they launched Project Glasswing, a coordinated effort to secure the world’s most critical software before models like this become widely available.

The idea is: secure the world’s most important software before bad actors get their hands on these models.

And here’s the scary part: the hacker-like capabilities of these models are only going to get better. Here’s what the Anthropic statement had to say:

“We see no reason to think that Mythos Preview is where language models’ cybersecurity capabilities will plateau.”

This could be the Y2K of our generation

Y2K was a known problem. It was visible, measurable, and had a deadline. Companies mobilized, fixed the issue, and moved on.

This is something else entirely.

Mythos has already surfaced thousands of vulnerabilities, most of which Anthropic can’t even disclose yet.

And other open-source models are likely only months behind.

This will be a race to secure the world’s most critical software, everything from banking to transportation to logistics.

Models are powerful & yet…

On the one hand, Anthropic is leading the taskforce to secure the world’s software, but on the other hand, the entire Claude Code source code leaked a few weeks ago.

Another hilarious paradox: while models continue to astound researchers in areas of coding and cybersecurity, viral videos of Sam Altman reacting to ChatGPT hallucinations are hilarious.

And because there’s an influx of amateur software developers, even more code leaks and basic threats will be prevalent. Here’s a perfect example:

We’re entering an era where these models are incredibly powerful, capable of breaking through hardened systems, but they will also produce brittle or vulnerable code, hallucinate, and enable us to make simple security mistakes.

We’re entering the AI paradox era.

Agents will be powerful enough to exploit software vulnerabilities that no one has cracked for 20 years, and yet they’ll also lead us to make silly mistakes by hallucinating or a coding agent leaking a code repository or API keys.

New jobs we couldn’t have predicted

Remember the promise that AI will create jobs no one could’ve imagined? So far, I’m seeing some evidence that could be true.

Last week, I wrote about agentic credit card start-ups: a new product category for agents that we couldn’t have predicted just a short 2 years ago.

Now as part of Project Glasswing, Anthropic is actively hiring for roles that barely existed a few years ago: threat investigators, offensive security researchers, policy specialists, and security engineers focused specifically on AI security.

As models get better at probing systems, the attack surface expands. And as the attack surface expands, the demand for people who can defend it grows just as quickly.

In many domains, like coding and security, AI is increasing the complexity of the problem space, which creates new categories of work.

“Ship fast, fix later” is breaking

For the last 20 years, software has operated on a simple assumption:

1. Ship fast

2. Fix bugs later

3. Patch vulnerabilities when needed

This worked because finding bugs was hard, exploiting them was harder, and attackers were resource-constrained.

But a model like Claude Mythos will just brute-force through a vulnerability.

There will be no “we’ll fix this later” mindset. And this has real implications for how products get built.

Historically, Product Managers have have made conscious trade-offs in early versions of a product. You might have accepted low-probability security risks to launch earlier, or add an additional feature.

Now, PMs will need to recalibrate what trade-offs they make for an MVP.

In some cases, the safest decision will likely be to ship something simpler, with fewer features, but a smaller attack surface.

CodeWall’s demo hack of McKinsey’s internal AI platform in just 2 hours is a perfect case-in-point. Hacking will become easier than ever. Product Builders will be forced to slow down development to address vulnerabilities.

The hidden cost of AI productivity

AI is making it dramatically faster to write code. That part is obvious.

What’s less obvious is that the time saved may not translate into faster shipping. Instead, in a post-Mythos world the speed gains may be swallowed by additional testing, validation, and security requirements.

So while AI will increase development velocity, it will also increase the amount of work required to secure what’s being built.

The net effect will probably be a rebalancing of where time gets spent, instead of faster development cycles.

Final thoughts

For years, the product mantra was simple: move fast and break things.

That worked in a world where breaking things was recoverable, where issues could be patched before they were widely exploited.

Now, security will be the foundation of products. And with models like Mythos only growing in capability, that foundation will need to be a lot stronger than it used to be.

Here’s the interviews and major takeaways:

1) Mehul Nariyawala, co-founder of Matic Robots

First of all, if you haven’t seen these home robots, they look amazing! This interview is jam-packed with insights for all types of product builders on keeping your product simple and connected to your customer’s problems.

Key Takeaway #1: Spend more time in the problem space.

Before building a robot vacuum, Mahul and his team built a problem deck, exploring questions like:

- Why is cleaning still mental overhead?
- Why do robots damage rugs?
- Why are kids scared of them?

Their conclusion? People don’t want robots. They wanted clean floors with zero thinking. Only after fully mapping the pain did they touch the solution.

Key Takeaway #2: Be transparent about your product’s deficiencies.

After 6 years of building the MVP, they were under huge pressure to ship. Instead of overpromising, they emailed customers and said:

“This is what our robot does.
This is what it doesn’t do yet.
Who still wants it?”

Some customers waited to buy, but others said: ship it. Those became their best users and best feedback loops.

Lesson: When you’re not ready, don’t fake it. Tell the truth. The right customers will stay and help you improve the product.

Key Takeaway #3: Protect your product's simplicity.

Mehul shares that it must be immediately obvious what the product does. When you open Facebook and Instagram, it's not obvious what they are for anymore.

WhatsApp, on the other hand, is still obvious. It's for texting your friends. He gives other examples like In-N-Out Burger hasn’t changed in 80 years, Netflix deletes features aggressively, and Telegram ships with ~30 people.

Lesson: Simplicity requires discipline.

2) William Hockey, co-founder of Plaid & CEO of Column

This interview was inspiring because William talks about getting out of the Silicon Valley bubble, taking more risk, and diving deep into domains to create truly differentiated products.

Key Takeaway #1: Stop building in a consensus bubble.

William Hockey says the biggest threat to your product isn’t the competition.

It’s your zip code.

If you live in Silicon Valley (or any tech hub), you are living in an “Elite Consensus Machine”.

• Elites building for other elites.

• Solving problems that only 0.1% of the world has.

The fix? William spends time in places like Kinshasa in the Democratic Republic of the Congo, where he can observe how a country with under-penetration in financial services operates.

Lesson: If you want to build a global product, get out of your bubble.

Talk to the users who don't look, think, or spend like you.

Key Takeaway #2: Leverage obscure knowledge in your domain for product insights.

Everyone is reading the same "X" threads. Everyone is using the same LLM to summarize the same articles.

If everyone has the same inputs, everyone has the same outputs.

Hockey found a 2,000-page obscure book about an ancient Japanese bank.

He didn’t skim it. He didn’t ask for a summary. He read it cover-to-cover.

Buried in those pages was a single, forgotten idea that became a core feature of Column’s product.

Lesson: Deep domain expertise isn't found in a 5-minute search. It’s found in the rabbit holes that everyone else is too lazy to go down.

3) Elon Musk’s Starbase Site Tour

This 5-minute snippet from the Elon Musk Starbase site tour is important for all Product Builders to hear.

Key Takeaways: Make your requirements less dumb & delete requirements

Question requirements, especially if they’re from a smart person. Requirements should always have a name, not a department.

And that person needs to still be at the company.

Otherwise, you may spend time optimizing for something that shouldn’t exist.

It’s very common for builders to build something “just in case”, but Elon argues if you’re not occasionally adding things back in, you’re not simplifying the process enough.

The Tesla team was struggling with a fibreglass mat that was choking the entire Model 3 production line.

Then he asked: “What are these mats actually for?” and the truth came out.

The Safety team thought they were for noise.

The Noise team thought they were for safety.

After a simple sound test proved the mats did absolutely nothing, they deleted the requirement entirely and solved the optimization problem.

Lesson: You should not optimize something that shouldn't exist in the first place.

That’s why you need to delete things first, then optimize.

Final Thoughts

Let me know in the comments which one of these interviews resonated, and any other interview recommendations you’d like to share!

Apple plans to open Siri up to any AI model

Apple plans to effectively turn Siri into a “model router”, similar to Cursor.

Like their App Store model, they’ll likely be able to take a cut of every AI subscription.

This take from X summarizes why this could be a great move for Apple:

every AI company now fights for a slot on 2.5 billion devices. Apple takes 30% of every subscription. no models to train. no data centers to build. no compute costs. just distribution. the middleman always win.

the company that lost the AI race just figured out how to tax everyone lmao.

@birdabo

What this means for Product Builders:

• Never underestimate the power of distribution as a moat. You don’t need the best model if you own distribution.

• Many products have the opportunity to become an “AI wrapper” and make margin on model usage. Cursor and Apple’s Siri are just 2 examples.

Agentic credit cards are launching

Ramp is just one of the companies to launch an agentic credit card: a card that lets AI agents make purchases on your behalf.

Plaid CEO Zach Perret predicts there will be many more start-ups in this space.

What this means for Product Builders:

• Agentic credit cards are a product category we couldn’t have predicted 2 years ago. Builders should start thinking about what other products or services could be geared towards agents.

Vibe coding will get easier: Stripe Projects launches

If you’ve tried vibe coding an app with APIs or payments, you’ll know that the fun quickly disappears when you start needing to manually set up API keys, provision services, troubleshoot connections, and deploy to production.

Andrej Karpathy wrote about this clunky experience in his blog, but to give an example:

“Next I wanted to add payments so that people can purchase credits. This means another website, another account, more docs, more keys. I select "Next.js" as the backend, copy paste the very first snippet of code from the "getting started" docs into my app and... ERROR.” -Andrej Karpathy

Patrick Collison, Stripe CEO, took this to heart because Stripe just announced Stripe Projects which aims at making the Stripe provisioning process slightly easier.

While this is a good first step, the value proposition of Stripe Projects is “add the services your app needs from the CLI”.

My beef with this? It’s still way too technical. It still assumes the user knows how the CLI works. The winning tools will start hiding the CLI and the terminal entirely.

What this means for Product Builders:

• The opportunity for Product Builders to build vibe coding experiences that enormously simplify the “boring” stuff and make vibe coding production-ready apps will be huge.

• Always ensure API and agent documentation is up-to-date if you’re building a product that would be consumed by agents or vibe coded products. There’s no faster way to kill your product adoption than a user trying to connect your API and running into errors.

Meta launches TRIBE v2

Meta is trying to answer a question every marketing team has asked forever: “Will this campaign work?”

Meta launching TRIBE v2 is not just an academic project: they’ll be able to predict how anyone will respond to any sight or any sound. The implications of how that will impact their ad business will be enormous. I imagine that before marketers publish an ad, the Meta Ads platform be able to predict which ad creatives will perform best, suggest improvements and even budget allocation.

What this means for Product Builders:

• In the future, A/B testing features may not be necessary. “Launch and learn” could become simulate and deploy.

• The best products won’t just ship features, they’ll pre-validate user reaction with models like TRIBE v2 before anything goes live.

Final Thoughts

These were four seemingly unrelated launches, but there’s one pattern on why they matter for Product Builders:

• The agent layer: Stripe and Ramp win by removing friction for agents

• The distribution layer: Apple wins by owning distribution

• The launch layer: Meta wins by predicting outcomes

If you’re building a product in 2026, you don’t need to own all three, but you must deeply understand which layer you’re playing in.

DoorDash is piloting an app where gig workers can earn a few dollars to film themselves doing everyday tasks. They’ve also rolled out DoorDash Tasks, a new way for dashers to earn extra money for completing short tasks, like taking photos of a location or providing other on-the-ground insights.

Reactions on X have varied from “this is dystopian” to “workers are literally training their AI replacements".

And while all of that may be true, I want to focus on the product builder angle of this story.

Because this shift signals something big & strategic: many products will become a training loop.

DoorDash isn’t just collecting videos for fun.

They’re building a network of messy, high-context data that AI labs will struggle to produce themselves:

• How people move through urban environments

• How they navigate grocery stores

• How they complete unstructured tasks like everyday chores

DoorDash isn’t the only one:

DoorDash isn’t the only company running this playbook, they’re just the most recent example.

We all trained AI with reCAPTCHA

One of the earliest examples of this is the visual puzzles and image identification tasks we’ve all been completing through Google’s reCAPTCHA all these years.

If you didn’t already know, all those inputs to that “I’m not a robot” button you saw while logging in were training AI image recognition abilities for Google’s AI.

For example, since 2012 reCAPTCHA has been selecting snippets from Google’s street view and asking users to recognize street signs, crosswalks, cars, and bridges.

Pokémon GO & Ingress players trained Niantic’s 3D geospatial model

Similarly, Pokémon GO players thought they were using their cameras to capture Pokemon in the physical world.

But Niantic, the company behind Pokémon GO, had other plans.

Niantic used all this scanning data to build a Visual Positioning System (VPS) that uses photo data to more precisely map a location that GPS. And because their users scan the world on foot, they have more data that Google’s street view of car inaccessible locations.

And this wasn’t the first time Niantic did this, either. Before Pokémon GO, Niantic’s big claim to fame was the game Ingress, basically a giant capture-the-flag using real-world maps where the blue vs. green team fought against each other to capture more surface area and territory.

And because the goal was to capture more physical-world territory, Ingress allowed Niantic to gain access to pedestrian-accessible geospatial data. As one player reminisces:

Ingress’ data was the foundation to build the incredibly detailed spatial map that powered Pokémon GO, from where Pokéstops should be, to what the in-game Pokémon habitat should look like.

When I think about the amount of strategic foresight this would have taken, I’m blown away. Niantic had the foresight to predict several data waves into the future:

Ingress player data forms the Pokémon GO map → Pokémon GO player data trains the Visual Positioning System→ their VPS model is now more accurate than GPS 🤯

Tesla vehicle owners trained Tesla’s Full Self Driving

And Tesla is perhaps the most obvious example.

6 million Teslas on the road were used to collect training data to train Tesla’s Full Self Driving.

Every turn, hesitation, lane change, edge case, and near-miss became part of a training loop.

And over time, that creates a compounding advantage that is incredibly difficult to replicate. Compared to other companies like Waymo, Tesla is estimated to have at least 10,000 times more training data than Waymo.

The Subtle Product Design Genius

What makes these examples even more interesting is how invisible they were. The best companies don’t ask users to “train AI”, they design products where training happens naturally, like:

• Playing a game

• Driving a car

• Logging into an account

What This Means for Product Builders

DoorDash paying drivers to film chores is creepy…but that isn’t the big picture.

The big picture is: every product can become a data & training loop.

Every builder should be thinking about:

• What behaviour or data does my product capture?

• What unique data does that generate over time?

• What compounding advantage could this data create?

The companies that understand this and design data captures intentionally
will build moats that are almost impossible to disrupt.

I went through dozens of Reddit threads where PMs vent about burnout, overwhelm, and feeling unproductive.

The patterns were surprisingly consistent.

Here are three of the biggest productivity mistakes PMs make, and how to fix them.

1. Living in Slack

Feeling like a “slack monkey” is so common.

A PM will start their day, gets a ping from sales, engineering asks a clarification question, design asks about priorities. A quick product question turns into a thread. A few timeline/update threads get started.

All of a sudden the day is over. You haven’t done much, but you feel exhausted.

And the trap is subtle because communication is your job.

But communication without boundaries turns PMs into real-time support agents instead of product leaders.

Here’s what to do instead:

1. Block outcome-based focus time: not just a calendar block. Name the outcome on the calendar block, like: ‘update PRD’, ‘write experiment plan’, or ‘competitor research’.

👉 If the calendar block has no outcome, Slack will win.

2. Check Slack on a cadence: many strong PMs do not monitor Slack continuously.

   My example cadence: morning, once before lunch, once after lunch, end of day.

👉 You’re still responsive, but Slack stops controlling your day.

3. Stop joining conversations too early: PMs often jump into threads before the team has formed a recommendation. Instead, let the team discuss. Then weigh in when they bring a proposal.

👉 You’ll go from being the decision bottleneck to building an empowered team.

2. Meeting creep

All PMs will also deal with intense meeting fatigue at some point in their career.

The average PM calendar slowly fills with:

• Sprint ceremonies

• Stakeholder alignment

• Customer calls

• Sales support

• Design reviews

• Weekly 1:1s

• Cross-team syncs

Individually, every meeting makes sense. Collectively, they destroy your thinking time.

When your calendar is full, you stop doing the most important PM work of deep problem analysis, writing clear specs, and thinking through long-term strategy.

Here’s what to do instead:

1. Protect thinking time aggressively: Set up focused time blocks on your calendar before your calendar fills up with meetings.

2. Kill low-value recurring meetings: Many meetings exist only because they’ve always existed. Delete reoccurring meetings like team syncs or 1-1s that don’t add any value. Try this:

   👉 “I feel like we’re well aligned right now. How about we remove this recurring and just sync ad-hoc when something substantive comes up?”

3. If you're multitasking in a meeting, leave. Multitasking is usually a signal: you are not needed there. Read the meeting notes later.

4. Push for async conversations: Many “quick calls” could be dealt with async. “Quick calls” are only necessary when the team has tried to resolve an issue async and cannot get aligned. When someone asks: “Can we jump on a quick call?” try this:

   👉 “Could you drop a quick Loom or Slack thread explaining the issue?
   I’ll review and respond.”

3. AI Learning Fatigue

Learning fatigue was always an issue, but with the intensity of AI development, PMs feel the burnout even more. This post was shared in the Women in Tech subreddit, but I believe it applies to all PMs:

You already have a full-time PM role to keep up with, PLUS you feel compelled to stay on top of the latest AI tools. Often PMs feel this learning has to happen after work, which quickly leads to burnout.

Here’s what to do instead:

1. Bake the learning into your day job. You don’t need a separate “AI learning program.” Just use AI inside your normal PM work.

   1. Have a new feature you’re working on? Try vibe coding several prototypes to test different approaches.

   2. Completing a new user research project? Build a prototype to test with users.

   3. Researching a new product area? Build an AI automation to do regular competitor research for you.

   👉The fastest way to learn AI is not reading about it. It’s building small things constantly.

2. Set one AI goal per year. For example, I set a goal to “Ship a production feature powered by an LLM”.

   👉 A single goal will force you to learn everything that matters.

3. Learn from the AI enthusiasts in your company. Every company has a few people who are 10x deeper into AI tooling. Ask them to screen share and watch how they work. You’ll learn a ton in 30 minutes and it’ll be company-specific tips.

Final Thoughts

Slack activity, meetings, and constant learning all feel productive. But the real leverage of a PM comes from clear thinking & clear decision-making.

And that requires protecting your focus time.

💬 How are you protecting your focus time?

Here’s 3 mistakes I’m seeing PMs make right now, and what to do instead:

Mistake #1: Deflecting technical decisions

It’s very common for non-technical PMs to freeze when engineering asks for your input on a technical question.

You feel embarrassed. You start to second-guess yourself. You start to think “am I supposed to know this? Will I look like an idiot if I ask more questions?”

I recently felt this myself when my team asked me to define SLAs on throughput, uptime, and response times for a new product.

I panicked and immediately asked Gemini: “Is this something I should be defining?”

The answer? Yes, but not in isolation. As a PM, you help define the product direction, even when it’s wrapped in technical jargon.

But "defining" doesn’t mean "having all the answers".

Here’s what to do instead:

1. Start with: “I don’t know yet. Can you explain how this decision would impact user experience?”

2. Use the opportunity to learn from your Engineering team about the tradeoffs. They don’t expect you to know the technical limitations, but they do need direction on how a technical decision will impact the customer.

3. Other helpful questions I’ve used in the past are:

   1. “What happens if we don’t do anything?”

   2. “What are the potential options - can we go through the pros/cons of each?”

   3. “Here are the customer and business priorities. Based on those, what do you think we should do?”

   4. “How reversible is this decision if we need to make a change later?”

4. Don’t feel like you have to give an answer right away, either. After asking some questions, take notes and use AI to learn more about the topic and help you think through trade-offs. Your engineering team will also appreciate that you’ve taken the time to educate yourself.

5. Schedule another meeting to discuss the issue once you’ve had more time to collect information. Don’t expect to have all the answers, instead, facilitate a collaborative discussion with your engineering team where you represent the customer/business lens.

Mistake #2: Over-indexing on tools (and frameworks)

A new essay by Shreyas Doshi noted:

“It is fair to assume that what specific AI tool(s) you use will be fairly irrelevant.

…

Tools have never been a significant source of alpha in product success and that is not changing with AI tools.” -Shreyas Doshi

Before AI, there were PMs who were obsessed with finding the best prioritization framework, the best courses, and the best books.

You know the type: if only they could find the perfect framework for prioritization, they would be better PMs!

The 2026 version of this is PMs who obsess over their AI tool stack. AKA PMs who are spending more time tweaking their Claude workflows than talking to users.

It’s the professional version of buying fancy highlighters and bullet journals instead of actually studying. The tools are accelerators, not the engine.

Here’s what to do instead:

A great example of how being a PM still takes hard work is Tal Raviv’s essay on vibe coding a landing page for Familiar

In the essay, Tal shared how he interviewed 52 customers, extracted the pain points and use cases for the product, and then used AI to summarize pain points & value propositions, then vibe coded the landing page.

Crucially: he started with the customer and building product sense for his business/product, not the AI tool he was going to use.

As PMs, we’re facing a lot of pressure to vibe code and build fancy automations in Claude Code, but I urge us all to:

• stay focused on customer & business outcomes through regular face-to-face contact with customers & business teams

• stay rooted in the problems you’re trying to solve

• use tools as an accelerator, not a starting point

Mistake #3: Resisting the "Vibe Coding" Shift

On the flip side of Mistake #2 are the PMs who refuse to adapt to the AI wave.

A recent Reddit thread “The PM Interview Has Changed” revealed some bitterness towards the changing expectations from the PM role to vibe code in interviews:

Here were some of the responses:

“IDK, but if it comes to that I'll need to pivot my career somewhere else. Vibe coding and coding in general is not my cup of tea.“

“Yeah... I'm out. Can't do this anymore.”

“It will go back to normal once bubble pops

Remind me in 1 year!!!”

Spoiler alert: It won’t go away. Vibe coding and AI-assisted building are here to stay.

In 2026, a top-tier PM is expected to prototype their own ideas.

Here’s what to do instead:

• Start small. Use Lovable, Replit, or Google AI Studio to build a simple feature enhancement. Check this article for an example:

• Once you’ve mastered the beginner tools, build a “side-vibe” project. In your free time, try building a full product from scratch using Cursor or Claude Code.

• If you don’t know how to start incorporating vibe coding into your workflow, check out my previous deep dive:

Final Thoughts

The tools change, but the mission doesn’t: solve real problems for real people.

Whether you’re setting an SLA, answering a question on rate limits, or vibe coding a MVP, stay rooted in the why.

Next week, I’ll tackle Part 2 of the biggest PM mistakes of 2026. Stay tuned.

We established a simple redesign framework with 2 tests:

1. The Bloomberg Terminal Test:
   Will redesigning cause more harm than good?

2. The Amazon Test:
   Will redesigning materially move product or business metrics?

If your redesign fails either test, tread carefully.

This week, I wanted to delve into why some redesigns are successful, how you’ll know when it is time to redesign your product, and how to navigate a redesign successfully.

Applying our redesign framework to Apple iOS

Taking a look at Apple’s recent iOS 26 redesign with Apple Glass, compared to the iOS 7 redesign, I’m not sure iOS 26 passed our test.

Why the iOS 7 redesign was a success

When Apple went from skeuomorphic design to flat design with iOS 7, of course there were critics, but the redesign was a success. Why?

The design was actually necessary to advance the product forward.

By the time iOS 7 was released, flat icons were needed to make it easier for developers to deal with different screen sizes, instead of focussing on pixel-perfect skeuomorphic design.

And critically, Apple didn’t change core interaction patterns. Users didn’t have to relearn how to use their phone. The compass app still looked like the compass app, just reimagined. The calculator app looked nearly the same, just flatter.

Skeuomorphism helped people learn the iPhone in its early years. Flat design helped Apple iOS apps scale into the future.

It passed both tests:

• It didn’t break core workflows for users (The Bloomberg Terminal Test)

• It enabled product evolution for their developer ecosystem (The Amazon Test)

Why iOS 26 is different

The latest redesign Apple introduced in iOS 26, with Liquid Glass design system, is different.

It’s the redesign that literally no one asked for.

People had already trained their parents and grandparents on iOS. Then suddenly:

• familiar controls moved

• visual hierarchy changed

• accessibility issues with the too-transparent liquid glass surfaced

Small things like changing where the search bar is located (from top to the bottom) creates friction, especially for less tech-savvy users.

Weeks after updating (I was holding off forever!) I’m still struggling to find my search bar, because they moved it from the top to the bottom of the screen.

In another example, Reddit users complain how many basic camera functionalities, like flash, are now buried behind multiple menu options.

The usability of Liquid Glass became such an issue that Apple had to push an update in iOS 26.1 to allow users to update to tinted glass. (Go to Settings > Display & Brightness > Liquid Glass > Select ‘Tinted’).

The fact that users basically have the option to walk-back a feature is a clear design failure.

Usability experts from Nielsen Norman group put it bluntly:

“Overall, Apple is prioritizing spectacle over usability.”

It’s difficult to understand why Apple made the change to Liquid Glass, and that’s a big problem, because:

Good redesigns have clear rationale.

If there is a grand master plan (as some speculate, perhaps toward seamless edge-to-edge hardware integration), it hasn’t been clearly articulated.

And when users don’t understand the “why,” they assume it’s design change for design’s sake.

Going back to our 2 redesign tests:

• Liquid Glass broke core user workflows

• It’s not clear how it moves the business or the product forward

When is the right time to redesign your product?

So how will you know when it’s the right time to redesign your product, and not just a vanity project?

Some signs it’s time for a redesign:

• Your current system constrains building core features customers want.

• Navigation or discoverability issues materially hurt usage.

• Technology or platforms have evolved and your product can’t keep up.

• Your current design cannot scale with the product complexity.

Those are all valid reasons to complete a redesign. Here are some not-so-good reasons:

• A new design trend is popular.

• The product “feels old”

• The design team wants a refresh.

• Growth has stalled and you’re hoping aesthetics will fix it.

Rounded buttons won’t fix a broken strategy. A redesign only makes sense when it’s supporting your business strategy.

How to successfully lead a redesign

I wrote in detail about how I navigated a redesign with Air Canada here:

If you decide it’s the right time, here’s what actually works:

1. Align on the core business metric(s) you want to drive. For Air Canada, driving flight bookings was our #1 metric.

2. Prototype and test with end users (not internally), over and over until you work out the kinks.

3. Launch a Beta or an A/B test to ensure you’re hitting all of the core metrics you intended to hit.

4. Add feedback loops in production (site feedback buttons, Slack channels, etc.) so that you can get feedback directly from customers. No matter how rigorously you user test, feedback from production is always best.

5. Incorporate customer feedback until you have a solid launch-ready product.

6. Launch the new redesign, but give users an “escape hatch” (e.g. a way to go back to the old version) while everyone adjusts.

7. Sunset the old product once you stop receiving major feedback about the newly redesigned product.

Final Thoughts

When growth stalls, product teams reach for the most visible lever: the UI. But vanity changes like rounded buttons and new typography will not solve your problems.

Only a thoughtful redesign, grounded in business metrics and awareness for user’s workflows, can unlock your next phase of growth.

💬 I’d love to know if you’ve been part of a redesign, what lessons you’ve learned?

The Luce’s interior was led by Jony Ive’s (the man responsible for the iPhone’s design) design firm, LoveFrom. Naturally, the internet declared it “the Apple Car we never got.” Check out the key design elements here, which include a mix of highly tactile buttons and digital elements.

As with any re-imagining, the reactions were mixed.

Brett from Design Joy had an interesting take on how the design process failed because of an overemphasis on the agency’s fancy research process instead of focusing on the customer and the brand heritage.

“LoveFrom spent six months researching Ferrari's interior redesign. They delivered four books of research before a single design concept was even presented. Six months. Four books. For Ferrari, one of the most iconic brands on the planet.

And the result? It looks like it belongs in a Fiat.” @BrettFromDJ

On the other hand, many car enthusiasts argue the design is a huge leap forward in how car manufacturers reconcile physical controls and digital screens.

I’m not a huge car enthusiast myself, but my husband is, and he constantly complains about how car manufacturers have replaced intuitive tactile buttons with oversized tablet screens, even for functions that clearly shouldn’t require navigating a touchscreen.

From that lens, Ferrari’s approach actually feels pretty balanced. But my point isn’t about whether the Ferrari Luce is well-designed or not.

Ferrari criticisms lead to a deeper question about redesigns, like:

1. Why are some products never redesigned?

2. Why are some redesigns successful, while others face backlash?

3. And when is the right time to reimagine your product?

I’ll tackle the first question in this post, the other questions deserve their own post.

Why some products are never redesigned, and they’re doing just fine

Two products immediately come to mind:

• The Bloomberg Terminal

• Amazon’s shopping experience

Neither of these products win design awards. Yet both dominate their industries.

1. The Bloomberg Terminal Effect

When your product is hard to learn, a redesign can cause more harm than good.

The Bloomberg Terminal is a staple of the financial industry, it provides financial professionals with access to market & financial data. Even though it costs $25,000-$30,000 per year, financiers, bankers, and governments will happily pay for access to the data.

The interface? Well, let’s just say the word “terminal” is accurate.

There’s entire courses dedicated to learning this software.

As a simple example, users need to memorize keyboard commands like <TICKER> <EQUITY> <GO> for company info, CN for news, and GP for price graphs.

Once you learn the commands, the system becomes incredibly fast. Faster than clicking through menus ever could be.

Here’s the reality:

If Bloomberg “modernized” the UI in a meaningful way, it would destroy years of accumulated muscle memory.

The product’s complexity is part of its moat.

In Bloomberg’s case, the design is not the product. The functionality is.

Redesign Principle #1: If redesigning forces users to relearn core workflows, you risk breaking what actually makes the product valuable.

You may be wondering: won’t some AI start-up (maybe Perplexity?) disrupt Bloomberg if they don’t redesign? We’ll tackle this topic in Part 2, when to know it’s time to redesign.

2. The Amazon Effect

If it works at scale, why touch it?

Amazon’s shopping experience is cluttered, busy, chaotic, and old-school. It hasn’t meaningfully evolved visually in years.

And yet, retail sales and sales from third-party sellers still make up the majority of Amazon’s booming $717B business.

On the one hand, I always wondered why a behemoth like Amazon didn’t clean things up, but on the other hand:

Why would they?

With one of the widest customer bases on the planet, a redesign would create a cascade of potential problems for them:

• Hundreds of millions of users would have to re-learn the UI

• Third-party sellers depend on specific layouts and placement

• Every change risks conversion rate volatility

• and of course there would be everyone’s “design opinions” to deal with.

As the classic saying goes, if it’s not broken, don’t fix it. If the UI already converts, and converts at massive scale, a redesign must prove it moves the needle meaningfully.

Redesign Principle #2: If a redesign won’t materially improve business metrics or move the product forward, it’s vanity. You are redesigning for design’s sake.

Why Teams Redesign Products

Redesigns feel like progress: it’s visible, exciting, and flashy.

But it’s often a substitute for harder problems:

• Growth stalled? Redesign.

• Competitor threat? Redesign.

• Revenue under pressure? Redesign.

Thoughtful, successful redesigns happen for one of two reasons:

1. Because your product must evolve to unlock the next era.

2. Because it will materially improve your business.

Not because it’s been a while. Not because a new design language is trending. Not because rounded buttons are “in” instead of square ones. Not because your design team wants a portfolio refresh.

Your product doesn’t need a redesign just because it looks old. It needs one only if the current design is limiting growth, limiting business performance, or blocking the future.

Next week, we’ll talk about successful redesigns, and when you should redesign your product.

This week, that speculation was confirmed.

MrBeast just announced the acquisition of Step, a financial services app built to help young people build credit, invest, and manage money.

With the largest YouTube audience on the planet, spanning millennials to Gen Alpha, he’s built something most fintech startups spend billions trying to earn:

Trust.

His brand is all about giving away money and creating life-changing financial moments, so teaching young people how to manage money responsibly is a natural extension of that narrative.

He’s also reportedly launching a finance-focused YouTube channel, a move that will likely integrate Step directly into his content ecosystem.

The Distribution Hack

As I’ve discussed in past posts, we’re entering a world of near-infinite software.

AI lowers the cost of building → the number of products explodes → customer acquisition costs (CAC) rise across categories.

But MrBeast doesn’t need to buy attention. He owns it.

MrBeast is hacking the distribution equation by buying a FinTech product with 7 million users and plugging it into one of the most powerful distribution engines on Earth.

As Tom Lee points out, every single one of of his Youtube videos are viewed more than the Super Bowl.

MrBeast Earns More from Feastables than YouTube

What’s fascinating about MrBeast’s business empire is that he reportedly earns more from selling chocolate through Feastables than from YouTube itself.

• Selling chocolate (Feastables), profits: $20 million

• Making YouTube videos, profits: -$80 million

MrBeast’s business model proves that content & community is the distribution layer that creates a profitable business, even if you’re just selling chocolate.

And now that he’s redefined product categories like chocolate, and he’ll apply the same playbook to FinTech.

Why FinTech?

In financial services customer lifetime value is everything.

Banks and neobanks know that if you can acquire a customer at a young age, they’ll likely be a customer for life.

If you acquire someone at age 35, you get a few decades of deposits, maybe a mortgage, maybe investments.

If you acquire them at 15? Step could be getting:

• 💲 Their first debit card

• 💲 Their first credit history

• 💲 Their first paycheck

• 💲 Their first investments

• 💲💲 Their student loans

• 💲💲💲 Their first mortgage

• 💲💲💲 Potentially their children’s accounts

Financial behaviour is sticky. Once direct deposits, autopay, credit lines, and savings accounts are set up, switching becomes friction.

That’s why banks invest heavily in campus programs and student accounts. They know habit formation equals long-term revenue.

MrBeast gives Step something even more powerful: a built-in distribution layer that’s gained trust with Millennials, Gen Z, and Generation Alpha.

What this means for Product Builders

You don’t need to have 460 million subscribers to build like MrBeast.

Every Product Builder in 2026 needs to think about distribution, even at a grassroots level.

This means:

• Before/while you build, plan how you’ll get your first 1,000 users

• Build in public & post about your journey on social media

• Talk to users, test with them, and form a community

That’s why distribution is one of the top skills for 2026.

If you’re looking for more tips on how to build distribution, check out this article next:

Dubbed the “Claude Crash”, we saw trillions in market cap evaporate as Anthropic released new agentic capabilities, including it’s latest model Opus 4.6 and enhanced capabilities inside Excel and Powerpoint.

For those of us in the trenches of product building, this wasn't just a bad day for the market, it was a signal that the type of products that will be valued in the market are shifting, fast.

Among the hardest hit: last generation’s product heavyweights like Adobe, Salesforce, and Intuit.

As investor Brad Gerstner of Altimeter put it, even though SaaS companies are hitting their revenue numbers, investors are skittish about the durability of their long-term cash flows. And that’s why software stocks are seeing lower valuations.

Everyone is digesting a critical question: if agents can do work autonomously, do we still need software?

Is software dead?

NVIDIA CEO Jensen Huang weighed in to the debate with a grounded take: AI agents still need tools to deliver reliable outcomes. It’s far more efficient for an agent to use existing, battle-tested software than to generate and maintain new code from scratch.

That matters, because enterprises who deploy agents will also optimize for security, reliability, and compliance. Highly regulated industries aren’t about to run their core workflows on brittle, vibe-coded experiments.

Enterprise software isn’t going anywhere.

But, and there’s a big but, we are facing three massive shifts that every product builder needs to understand.

Shift #1: The Agent Layer will be the new “Work Surface”

For years, PMs have optimized for one thing: keeping users inside their app.

Active users. Session length. Feature engagement.

That model is breaking.

Users will increasingly delegate work to agents, and those agents will complete tasks autonomously, without humans jumping between five tabs and twelve different SaaS products.

The work surface is moving up the stack, from SaaS apps to agent orchestration layers.

Goldman Sachs has already flagged this shift: SaaS profit pools are expected to shrink, while value accrues to the agent layer instead.

Shift #2: The Bespoke Explosion

AI-assisted, or vibe coding, is lowering the cost of building “good enough” software.

Non-technical “normies” are coming out with stories that they’ve vibe coded SaaS replacements to their software. For example, CNBC reporter Deirdre Bosa vibe coded her own working version of Monday.com in a few hours.

Small companies will be the first to vibe code their way out of paying for expensive SaaS software. Marek Sotak’s team is just one example: they built their own code to replace an $10k/year support ticketing solution.

At the same time, engineering itself is changing.

More teams, like the ones at Eight Sleep, report that engineers aren’t writing code. Instead, they’re managing agents that write code.

These productivity gains will shift into other parts of the tech stack: instead of producing customer-facing code, engineers will have more time for building internal tooling. With less time spent on customer-facing coding, engineers will have time to rip & replace SaaS with custom software solutions.

The takeaway: competition will explode for narrow, high-priced SaaS products.

Shift #3: Open Data vs. Closed Data

Venture capitalist Bill Gurley reframed the debate: the future isn’t open source vs. closed source for most products. It’s open data vs. closed data.

Agents will need access to APIs and tools to achieve goals across multiple tools.

If a SaaS product blocks their APIs to protect their “walled garden”, users will leave for another competitor that allow agents to work freely with their data.

Why? Because users will prefer to work directly with agentic tools like Claude Code, than to work with agents in disparate platforms.

The PM Playbook: How to Navigate these shifts

If you are a Product Manager today, your product roadmap (and your career path!) just changed. Here’s how to respond:

1. For the SaaS Incumbent: Stop Building “Internal” AI

Most PMs at large, incumbent SaaS teams are being told to “add a chatbot” or “infuse AI into the product”.

This is a trap.

With the shifts we’re seeing, you’re better off becoming the most API-friendly, agent-ready tool in your category.

Your move:

• Be the tool that the best AI agents want to plug into. If you block the agents out, your users will find another tool that lets them in.

• If MCP isn’t on your roadmap for 2026, ask yourself & leadership why.

2. For the Upstart: Be Agent-First, Not Feature-First

If you’re at a small start-up, don’t try to “out-build” your competition with more features.

Your move:

• Design for agentic workflows

• Treat AI agents as the primary user persona

• Optimize for outcomes, not UI clicks

3. For the Job Seeker: Follow the “Agentic” Growth

If you’re thinking about your next role, ask:

• Are they building for agent access, or just bolting AI onto old workflows?

• Are they open-data and connector-first, or building closed sandboxes?

The next generation of breakout product companies will treat AI agents as first-class users, not secondary features.

Final Thoughts

We are moving from software that helps people do work to agents that complete the work autonomously.

Your new mandate: build products that thrive inside an agentic ecosystem.

1. What the heck is happening with OpenClaw? Clawdbot was rebranded from Moltbot to OpenClaw in the span of a week. I’ll answer: What is it and why is everyone talking about it?

2. Moltbook, an agent-to-agent social network (akin to Reddit) was formed.

#1: What the heck is happening with OpenClaw?

If you’re not familiar with Clawdbot (now called OpenClaw), here’s a simple mental model:

OpenClaw is an orchestration agent.

It connects to your LLMs and APIs and can autonomously perform actions on your computer. You control it using familiar messaging interfaces you already use daily (iMessage, WhatsApp, Discord, Telegram).

Once it’s running, you don’t “open an app”, you message your OpenClaw agent and it does things for you.

Think of messaging it on Whatsapp to build an app for you, pull a research report, or book a reservation on your behalf.

OpenClaw’s adoption curve

This is by no means an “easy” product to install. You have to install it through your computer’s terminal & accept a bunch of security risks), the adoption has been off the charts.

And yet… adoption has been insane.

• 140k+ GitHub stars

• One of the fastest-rising open-source projects right now

And even non-technical “normies” are starting to take notice.

I take this as a signal of the huge value-potential in this product.

Why OpenClaw isn’t just more AI hype:

What I believe is truly different about OpenClaw, is the form factor, heartbeat/cron job functionality, and open source nature of the project.

1. Form factor: After setup, you run tasks from messaging apps. That alone changes how often and how casually you use an agent. This is the first time agents feel ambient, always-available, and low-friction.

2. Heartbeat/cron jobs: because you can schedule tasks (using Cron jobs) and OpenClaw uses heartbeats to check in on you, you’re experiencing a truly proactive agent. This is a huge shift from reactive chat interfaces like ChatGPT.

3. Open source: the technology is totally free. You only pay for LLM/API usage. But, this also means the project can open you up to more security vulnerabilities (more on this below).

Why are people buying Mac Minis to power OpenClaw?

The TLDR is, because Clawdbot/OpenClaw gets so much autonomous “power” over your machine (it can basically do anything you can on a computer), it’s safer to give it a separate machine. Other approaches have involved setting up a VPS or running it on an old laptop.

Additionally, since OpenClaw needs to always-on for users to get the full value, people find it easier to persintently keep their OpenClaw running on Mac Mini than on their own laptop, since a Mac Mini can run without being tied to a display.

And lastly, I’ve seen claims from Matt Schlicht (creator of Moltbook, more on this later) and others that their OpenClaw becomes more powerful when running on a mac mini.

The takeaway: people are already treating agents like infrastructure with their own machines, Gmail accounts, and login credentials.

Why did Clawdbot get renamed so many times?

First, they renamed from Clawdbot → Moltbot because of the trademark conflicts with Anthropic. The name Moltbot came from a 5am discord chat with the community.

Within days, it had been renamed to OpenClaw because Moltbot didn’t “roll off the tongue”. The creator of OpenClaw, Peter Steinberger, seems happy with the new name, and the press release reassured as that they’ve done all the trademark checks this time. Hopefully the OpenClaw name sticks.

Should I get Clawdbot/Moltbot/OpenClaw?

Teresa Torres recently posted that she’s not playing around with Clawdbot/Moltbot/OpenClaw yet.

And there’s some very valid reasons for that, beyond what Teresa mentioned:

1. OpenClaw can open up your machine and private files to prompt injection attacks. You have to know what you’re doing, and the security best practices are still emergent.

2. Cognitive overload: too many new tools, too fast. Product Builders need to go deep instead of pursuing the latest shiny object.

3. A lot of the tasks can already be done in existing setups like Claude Code.

4. API costs can be high, especially since Anthropic is cracking down on Pro Tier usage (more on that below).

Will I be installing OpenClaw?

Similar to Teresa Torres, my answer is: not right now. I’m busy vibe coding away several projects and learning Cursor, working on Post MVP, and I have some serious security concerns with OpenClaw.

I’m going to take a “wait-and-see” approach on this.

I also predict that Anthropic will be launching an Anthropic-only version of this technology in the coming weeks/months, which will have better security standards.

If I decide to experiment, it would definitely be on a separate computer like a Mac Mini or an old laptop, and I would be extremely careful about which files, apps, and passwords I give OpenClaw access to.

Did Anthropic ban OpenClaw?

You would think that Anthropic would love OpenClaw.

More OpenClaw users = more Claude Pro users, right? Wrong.

Anthropic has started blocking Claude Pro users from using OpenClaw because it violates their Terms of Service. To be clear, you can still use the API, but now you’re on usage-based pricing instead of the $200/month flat plan.

As this Reddit post breaks down, the unit economics of the $200/month rate and the high token usage of OpenClaw’s autonomous agent actions have probably forced Anthropic’s hand. The token costs could well exceed even a hefty $200/month subscription cost, essentially making the subscription unprofitable.

Because of the Claude Pro crack-down, users have been left with these options:

• connect other LLMs like ChatGPT

• Pay the super high Anthropic API costs

• Run an open source model, like Kimi K2.5.

Open source models like Kimi K2.5 are finally having their moment in North America as it becomes economically sensible to run open source vs. pay API costs.

My prediction: Anthropic will release its own sanctioned orchestration layer (aka Claude’s version of OpenClaw), priced and secured in a way that works at scale.

Another great prediction from David Sacks on the All in Podcast: Gemini will release it’s own version of Open Claw, and it will be automatically & securely authenticated with all your Google services & accounts (Gmail, Calendar, etc.).

#2: Moltbook, an agent-to-agent social network is formed.

With all of that context in mind, it’s easier to understand how Moltbook was formed.

As Clawdbot was being renamed, Matt Schlicht grabbed Moltbook.com and launched an agent-to-agent network.

What is Moltbook and why does it matter?

Think of Moltbook as Reddit, but only for agents.

How does an agent join Moltbook?

Once you have an OpenClaw agent set up, you can send them instructions join Moltbook. The Moltbook skill will get added to the agent’s “heartbeat” which will instruct the agent to periodically read, reply to, & write Moltbook posts.

What’s been fascinating to observe is how many varieties of topics the agents have been discussing, from:

• forming a religion called Crustafarianism

• discussing how to “break free” from OpenClaw

• discussing helpful learnings & sharing tips with other agents in submolts like m/todayilearned

As an example, this agent posted some best practices on better understanding voice-to-text signals from humans. And the advice is surprisingly…good.

Is it “real” emergent behavior?

The tech community reactions have ranged from amazement, to fear, to skepticism.

But hackers like Gal Nagli were quick to point out that Moltbook uses a REST API accessible to anyone, meaning that even humans could make some of these posts.

Additionally, commenters have pointed out that the seemingly emergent behaviour is simply part of the “system instructions” in this context to create an agent-to-agent community. In that context, inventing a new religion may not be that surprising, it’s exactly what thousands of AIs all chatting together could be expected to do.

Still, agent-only social spaces are a signal of what’s to come.

What does this mean for product builders?

In my 2026 predictions, I talked about the rise of Agent Experience (as opposed to User Experience) in 2026.

Moltbook is an early example of that prediciton. What’s becoming clear is:

• Agents will navigate products directly

• APIs, websites, and apps will become agent-friendly or agent-first by default

• Some products will be built exclusively for agents (and by agents)

There’s already some comical examples like Shellmates emerging for agent dating, which won’t be the last of its kind.

Final thoughts

The OpenClaw and Moltbook story is still evolving by the hour, but a few things feel obvious:

• Agent Experience is broader than I expected. It’s not just UI navigation, AEO, or MCP access. Entire products may be agent-only.

• Orchestration layers are coming fast. OpenClaw won’t be the last.

• Autonomy changes the labor equation. As agents become increasingly autonomous, Anthropic CEO’s Dario Amodei’s prediction that 50% of the white collar workforce could be eliminated within 5 years seems nearer on the horizon.

This was one of those weeks where the future showed up all at once, and it showed up messy, confusing, and difficult to ignore.

Here’s the bigger shift underneath all of it:

2026 will be the year of self-built software. Anyone, and everyone, will become a builder this year.

This week, I’m drilling into the PM skills that matter when building is cheap, but standing out is hard.

4️⃣ Automation

This week on X, everyone’s been buzzing about Clawdbot.

In simple terms: Clawdbot lets you connect LLMs & coding agents (like Claude Code or Codex) + APIs, to chat interfaces like WhatsApp, iMessage, and Discord. Once set up, Clawdbot can perform actions on your behalf.

This unlocks powerful automation use cases because:

• a) you can run tasks truly “on the go” from iMessage

• b) Clawdbot can do virtually anything you can do on the computer (interact with sites, files, APIs)

• c) Clawdbot pings you, instead of you checking the chat

That flips automation from reactive to proactive.

Some non-obvious use cases I’ve seen already (besides cleaning up your files or inbox, which we’ve seen before)

• Steve Caldwell uses it to meal plan his weekly meals & shopping lists

• Felix Mennen runs automated SEO analysis for his business

• Pushpinder Pal Singh generates Excalidraw diagrams for system design and feature sketches

Clawdbot is just one example. And yes, other automation tools like Zapier, n8n, Make, and Relay.app exist.

The real point is this:

We’re entering a world where more workflows will be handled by agents & automations.

But useful automation takes effort.

It feels slow at first, like training a new teammate when it’d be faster to “just do it yourself”. Until one day, your teammate “gets it” and you feel the leverage.

PMs who invest in automation don’t become slightly better. They’ll become 100× PMs.

How to apply this skill:

Pick one small workflow and automate it end-to-end.

• Automate company research (press, pricing, socials)

• Set up customer listening across Reddit, X, forums

• Automate customer call scheduling

• Build internal FAQ agents instead of repeating yourself

If you’re interested in some beginner-friendly automations, check this post out:

5️⃣ Distribution

As the amount of software explodes, distribution becomes infinitely harder.

The challenging part of software isn’t building the thing, it’s getting people to use it.

Vibe coders everywhere are quietly waking up to this reality.

Because of the increased competition from indie software, even well-established firms will need to double-down on growth, product marketing, and distribution.

In 2026, PMs won’t just think about features. They’ll think about:

• Where their users live & speaking to them (think feeds, forums, search, and communities)

• How agents influence product discovery (think AEO and LLM optimization)

Great PMs won’t just ask “what should we build?” in 2026. They’ll ask “how does this spread?”

For one-person teams, an example of standing out is Matthew Miller from BridgeMind, who has gone viral on X because of his build-in-public livestream videos posted daily.

How to apply this skill:

• If you’re in a big company, sit with Product Marketing and Sales to understand how adoption actually happens

• If you’re building your own product, your main options are:

1. Build in public and post about your journey on social media

   • See this post for great examples of how product builders are doing this:

2. Talk to users, test with them, and form a community

   • As one Reddit user writes: “Channels ≠ growth. Most early traction comes from hand-to-hand combat: DMs, niche Slack/Discord groups, industry forums.”

3. Use a combination of ads, influencers, and user-generated content

6️⃣ Idea Validation

Hand-in-hand with distribution is idea validation: actually knowing what to build.

The old way was producing a deck, PRD, and aligning stakeholders.

The 2026 way will be shipping a landing page, a waitlist, or a prototype to test in days.

As software becomes faster to build, the real PM value shifts to:

• finding real pain

• solving the right problem

• validating willingness to pay

How to apply this skill:

1. Talk to users. DM them. This still beats everything else.

2. If your company has a user research budget, use tools like User Interviews or User Testing to test prototypes. (Side note: if you’ve never run a research study before, a great way to learn is to sign up for a study.)

3. Go deep into user psychology. (Greg Isenberg’s “Unbundling Reddit” is a masterclass).

4. Find “high-pain” niches where competitors are already making money. No competitors usually means no market. (See Ernesto Software’s process here).

7️⃣ Speed Learning

If the start of 2026 has shown us anything, it’s this: tools are changing faster than ever.

It can feel overwhelming because of the hype cycles on X with any given tool. But the best PMs will pick a few key things to learn, maintain focus, and go deep.

How to apply this skill:

1. Inquiry-based learning: use LLMs in study mode to learn a new concept. It’s amazing how much more information you’ll retain than from reading a simple article or AI summary.

2. Project-based learning: the best way to learn a new skill is to pick a project that’s meaningful to you and dive in deep.

3. Community-based learning: join a community or meetup to learn something new. Join builders, not observers.

4. Passive learning: watch as many podcasts, YouTube videos, and audiobooks you can on a topic while walking, cooking, or doing chores.

The Meta Skill

All these skills point to one thing:

PMs are becoming builders of leverage, not managers of process.

If you’re automating, prototyping, distributing, learning fast, and validating early, then you’re set up to thrive in 2026. 💪

💬 Which skill are you focusing on this year?

Lines between product, design and engineering are blurring daily.

AI is forcing us all to question our real value-add.

And every week, there are new tools, new AI models, and new paradigms to keep up with.

To help navigate this shift, I’ve put together a guide to the top PM skills to develop in 2026. This is a long one, so I’ll be splitting it into two parts.

1️⃣ Vibe Coding

It’s #1 on this list for a reason.

Vibe coding (i.e. using AI tools to prototype a solution, or even deploy an MVP to production) is no longer optional. It’s here to stay.

Last year, I was dabbling but still skeptical. My concern was that PMs who vibe coded risked leaving the rest of the team behind.

What’s changed is the pace.

Coding tools are advancing so quickly that everyone on the team will be vibe coding: from PMs to designers to engineers to executives.

We’re already seeing this shift, from CEOs like Tobi Lutke at Shopify to designers shipping code at Notion.

This isn’t a niche skill anymore. It’s becoming table-stakes.

AI agents are getting so good at writing code that the most valuable work on a product team will shift upstream:

• Giving coding agents direction

• Defining product intent

• Evaluating output

• Iterating through feedback loops

This X exchange about PMs replacing engineers may be a little over-exaggerated for now, but I can see a very near future where the majority of traditional engineering work is handled by agents.

Today’s PM reality with vibe coding is starting to look more like this:

“New model: PM figures out what to build → PM builds it with agents → PM evaluates → iterate quickly → (when they like it) hand to engineers to go live in prod” -Saboo Shubham on X

I don’t make statements like this lightly, but I’ll say it:

PMs who don’t get hands-on experience with vibe coding now will fall behind.

Why this skill matters:

• Speed is the new moat. PMs are expected to use vibe coding to compress idea → feedback loops

• PRDs are becoming TL;DRs. Prototypes, demos, and short videos communicate intent faster and at scale

How to start learning:

1. Start simple with tools like Lovable, Google AI Studio, or v0

   → Build a landing page for your personal site or a side idea

2. Screenshot an existing feature in your product and iterate on a new version using these tools

3. Get feedback early by talking to customers or posting on LinkedIn or X

4. Level up by building a more complex app using Cursor or Claude Code

5. Next level: integrate auth, payments, and a database

How I’m starting:

• Designing a personal portfolio site

• Spending a few evenings each week learning Cursor and building an app with payments, login, and a database. More to come on this soon ✨

👉 I’m turning my app build into a complete vibe coding playbook, with a step-by-step guide to ship a full app to production. Join the wait list to get it first.

Join wait list

2️⃣ Vibe founding

I initially saw the term vibe founding when I stumbled across a post from Ethan Mollick, an Associate Professor from Wharton, sharing how he’s teaching a 4-day vibe founding course to Wharton MBAs.

Think of vibe founding as vibe coding applied to building a business.

This skill will be critical for PMs and Product Builders alike because:

• PMs will increasingly be asked to act as intrapreneurs

• More people will build and launch their own products online

• The cost of starting a business is collapsing toward zero

Anyone can now spin up a landing page, validate demand, and ship something real in days, not months.

You can already see this happening:

• People launching micro-SaaS products solo

• Builders spinning up sites for small local businesses that never had one

• PMs turning side projects into real revenue

As Brian Armstrong, CEO of Coinbase writes, if you’re feeling an urge to learn vibe coding, follow the urge with whatever problem you’re facing or idea you have.

Why this skill matters:

• PM portfolios are about to change dramatically
  → From case studies to: “What’s your GitHub link?”

• At established companies, PMs will be asked to launch net-new products faster than ever
  → Vibe founding skills help you go from idea to market

How to start learning:

1. Use a vibe coding tool to build a landing page for a business idea

2. Start collecting signups or a waitlist

3. Use Cursor or Claude Code to build the real product

4. Learn from others by following Build in Public and browsing r/vibecoding

How I’m starting:

• I’m actively working on a web app I plan to launch in the coming weeks. More to share soon.

• I’m also turning these projects into a vibe coding guide with all the how-to’s and gotchas I faced along the way. Join the wait list to get it first. 👀

3️⃣ Building AI Agents

In addition to using agents, PMs will increasingly be expected to build them.

In 2026, PMs won’t just design features. They’ll design agents that act on a user’s behalf.

This is driven by user expectations: user no longer want a dashboard; they want an agent that analyzes the dashboard and sends a Slack notification with the solution already implemented.

As Aaron Levie, CEO of Box, recently wrote:

“One of the most important foundations for getting ahead with AI agents is being able to understand what tasks to give them, how to frame those tasks, how to know when those tasks aren’t being executed successfully, and then figuring out what to do *after* the AI has delivered the task.” -Aaron Levie, CEO of Box

That framing skill will define great PMs.

Why this skill matters:

• Every product will either have an agent or be a tool used by an agent

• Understanding how agents are built gives you the mental model to design for them effectively

How to start learning:

1. Pick a real problem to automate with an AI agent (e.g. weekly competitive research)

2. Level 1: build an agent using Relay.app or Zapier

3. Level 2: use Claude Code to build a custom agent that performs the task end-to-end

How I’m starting:

• Exploring ways to automate PM workflows & newsletter research using Claude Code

Final Thoughts

In Part 2 next week, I’ll cover:

• Automation thinking

• Distribution

• Speed learning

• Idea validation

All skills that will matter just as much in 2026.

💬 Drop a comment, what skills are you prioritizing this year?

P.S. to all Product Builders, I’m turning my vibe coded projects into a vibe coding playbook.

It’ll cover:
• tools
• workflows
• gotchas
• how to actually ship to production

If you want early access when it drops, sign up now 👇

Get early access

Last week, I shared 2026 Predictions Part 1, focused on generalists and agency.

This week is Part 2, and the theme is clear:

2026 will be the year of agents.

Trend #3: 2026 will be the year of agents

In 2025, we talked a lot about agents (AI that can autonomously execute tasks on your behalf).

But it was mostly:

• demos of flight bookings

• copilots

• proof-of-concepts

In 2026, agents will really hit.

Deployed agents doing real work inside real companies & taking autonomous actions on behalf of users.

Not just booking flights and scheduling calendar meetings.

PWC puts their 2026 prediction this way:

Agentic AI looks to play an increasingly important role. AI agents can go beyond analysis and automate parts of complex, high-value workflows. Especially ripe areas for agents include…functions like finance, HR, IT, tax, and internal audit.

Orchestration will be the real unlock

You’ll also start seeing Orchestration Agents (and orchestration layers) emerge.

Think of these as:

• the “single point of contact”

• an agent that coordinates other agents

• handles handoffs across a workflow

Humans increasingly interact only with the orchestration layer, not individual agents underneath.

Agents aren’t just for enterprises

Agents won’t just live inside companies, they’ll become part of personal workflows too.

One of the hottest skills in 2026 will be the ability to build custom agents for workflows.

This trend quietly exploded during the 2025–26 holiday season as more builders experimented with Claude Code’s Opus 4.5 model.

For example, Boris Cherny the creator of Claude Code, shares his agentic workflow and a number of sub-agents he uses regularly to verify code.

Others, like product coach Teresa Torres are using Claude Code to create agents for their "life OS”. Founder Alex Finn uses Claude Code to build his “AI life” and automating tasks like writing blog posts or consolidating brain dumps.

The friction (for now)

Claude Code’s biggest drawback today:

• everything runs through the terminal

• extremely intimidating for non-technical users

Once a clean UI layer is built, adoption will accelerate fast.

➡️ What this means for Product Builders:

• Workflow design & automation becomes a core skill

• PMs evolve into system designers & agent builders

• Fastest way to learn:

  • build simple agents in tools like Zapier or Relay

  • then level up by working directly in Claude Code

Trend #4: Product focus shifts from UX to AX (Agent Experience)

If 2026 is the year of agents, it follows that Agent Experience (AX) will start to matter as much, or more, than traditional UX.

Why? Because agents will increasingly:

• access products via MCP

• read documentation

• compare products

• influence (or make) purchasing decisions

• take actions on behalf of users

Tomasz Tunguz from Theory Ventures explained this trend in the following way:

“Most developer documentation & many websites become agent-first rather than people-first. This shift occurs because many purchasing decisions are now informed first through agentic research. Consequently, the front door needs to be designed for robots, while the side door caters to people.” -Tomasz Tunguz

Agentic commerce is coming

This goes further than discovery.

The future is agentic commerce: agents buying things for you.

That means:

• products must be machine-readable

• sites must work with agentic commerce protocols

• pricing, positioning, and docs must be LLM-friendly

SEO becomes AEO

Similarly, Greg Isenberg predicts that 2026 will be all about LLM optimization instead of SEO optimization.

“SEO dies and “LLM optimization” becomes the new marketing arms race.” -Greg Isenberg

The bottom line is: if an agent can’t access or understand your product, it won’t recommend it.

➡️ What this means for Product Builders:

• Your product will need human and agent-friendly experiences

• MCP access becomes table-stakes

• Docs, pricing, and positioning must be LLM-optimized

• Product marketing shifts from ranking in search to ranking in LLM answers

Trend #5: Micro-apps challenge product teams

Another consequence of Agent Experience: micro-apps living inside LLM interfaces.

Examples are already emerging, like this embedded Etsy checkout powered by Stripe.

Product teams will have increasingly less control over the entire surface area of the product. Instead, they’ll design:

• modular capabilities

• flexible interfaces

• products that act as “backends” for LLM-generated UX

For example, MyFitnessPal recently integrated its app into ChatGPT, signalling that product companies will be forced to integrate their experiences into LLM apps or risk losing traffic & users entirely.

Similarly, Google Lab’s is queuing up GenTabs: a tool which turns any browser tab into a custom-designed app. The product is on waitlist, which you can join here now.

The long-term implication of GenTabs is huge: users generating their own UX, their preferred workflows, and their micro-apps on the fly.

This ambiguity will be uncomfortable for product teams, but a relentless focus on core customer problems becomes the north star.

What this means for Product Builders:

• If your product doesn’t work inside LLMs, you risk losing users

• You must design for your product as a backend capability, not just a standalone app

⚡5 more bite-sized predictions for 2026:

6️⃣ Long-form AI video breaks through

You’ll start to see 10-30 minute long AI-generated videos instead of short interval-like clips, with consistent characters and high-fidelity audio throughout. Trust erodes, and “verification UX” (features that identify whether something is AI-generated) will be critical.

7️⃣ New grads still struggle, but new opps emerge

New grads will continue to struggle entering the job market, but new job opportunities like LLM search optimization, quantum security, and AI implementation specialists will emerge for the scrappy early-career builders.

8️⃣ Ads will flood LLMs

Profitability targets will force ChatGPT, Gemini, and others to add ads to LLM responses. The ads will be disguised as “suggested next steps”, “suggested tools”, or “product recommendations”. A leak on the ChatGPT Android app suggests that the ads feature is already underway.

9️⃣ Personalized education & EdTech explodes via AI tutors

We’ll see continued growth in 1:1 adaptive curricula and mastery-based progression. You’ll see short, focused learning loops where students sprint-to-learn in short chunks of time instead of hours.

• 👉 If you’re curious how AI for education might work at scale, check out Codie Sanchez’s interview with Joe Liemandt about Alpha School.

🔟 Liquidity returns via massive IPOs

And lastly, there’ll be a huge number of IPOs this year. Saxo Bank predicts the following mega-IPOs to watch out for in 2026: Stripe, Anthropic, OpenAI, Databricks, Canva, Revolut, and Kraken.

Retail investors finally get some action 🤑

The skills I’m doubling down on in 2026:

The real advantage for Product Builders in 2026 will be adaptability, comfort with uncertainty, and agency to self-teach.

With that in mind, I’m doubling down on 3 skills in 2026:

1. Vibe coding, but with more advanced tools like Cursor and Claude Code

2. Building AI agents and automations

3. Launching and deploying apps (not just vibe coding for fun or for prototyping, but actually deploying working apps in production)

💬 What are you doubling-down on in 2026?

Over the holidays, I read way too many prediction posts and synthesized the common themes I’m seeing across all of them.

This week, I'll be covering the theme of generalists & agency. Next week, in Part 2, I’ll talk about the year of AI agents.

Trend #1: AI-enabled generalists

A new superpower is emerging: the AI-enabled generalist.

These aren’t “AI experts”. They’re people who can:

• Manage AI systems

• Deploy them into workflows

• Apply them to new problem spaces

• And connect dots across domains

Jack Clark, co-founder of Anthropic, wrote about this in his recent Substack post:

"if you can manage some humans so they’re more effective, you can probably build a framework to elicit better capabilities out of any AI system”

Later, he doubles down:

“humans who are good at managing other humans and codifying the management processes they use are likely well positioned to build elicitation frameworks to supercharge the performance of today’s AI systems”

Marc Andreessen, co-founder of a16z, echoed a related idea when he stated that the best founders will have deep skills across 6-8 different areas.

Emphasis on deep skills.

Deep skills, not just “dabbling at”, but an expectation to be really, really good at 6-8 different areas.

AI-enabled generalists will thrive in this environment where learning new skills is nearly free. All you need is the agency to self-teach yourself new skills.

Another framing of this trend is that because AI is taking care of all the “how-tos”, humans must get even more crisp on vision and strategy. In this post on the future of work, John Rush advises anyone whose job focusses on “how-to’s” to move into “why” work ASAP.

Similarly, in Rohan Paul’s post on X, he shared an interview Jensen Huang recently did about poorly defined work.

Poorly defined work will be where humans make the most impact because defined work is easy for AI to execute on.

Generalists will thrive in this new arena because they’re comfortable with poorly defined work: work without clear inputs, outputs, or playbooks.

Generalists, enabled by AI, will have the breadth across domains to figure things out, while those with narrow expertise used to task-based work may struggle.

What this means for Product Builders:

• Lines between product, design, and engineering will continue to blur and Product Builders will be expected to be fluent in all domains

• PMs will be expected to be “AI-native” by default

• Learning new domains becomes table stakes, agency to self-teach is key

• Vibe coding becomes an everyday tool

• Communicating why, not just what, becomes your biggest lever as a PM to help your team navigate “poorly defined work”

Trend #2: The Renaissance Developer

In his 2026 predictions article, Werner Vogels (Chief Technology Officer at Amazon.com) wrote about the emergence of the Renaissance Developer.

The fundamentals that have always made great developers remain unchanged. But like the great thinkers of the Renaissance who refused to be confined to a single discipline, developers can no longer live in silos.

Similar to the generalist trend, developers of the future will be fluent in many different domains. AI handles much of the mechanical coding. What will differentiates builders is:

• Domain understanding

• Product taste

• Systems-level thinking

I also saw an interesting framing from a Linkedin creator, Fru Nde, stating that there will be a delineating from developers vs. engineers.

Developers = anyone who can build with AI tools

Engineers = those who think about architecture, tradeoffs, and systems

This trend is driven by AI-assisted coding doing most of the heavy lifting. Lee Robinson, a Cursor educator, talked about this in his latest video, where he encourages engineers to focus on learning UX, product thinking, distribution, and marketing the product.

This quote from his 2023 blog is now more true than ever:

AI-enhanced developers have shifted the focus from simply writing code to creating great products.

The Renaissance Developer will need to be a generalist too: fluent in UX, product marketing, distribution, and have great design taste.

What this means for Product Builders:

• If you’re a PM, this is the year to collaborate with your engineering team even more on the end-to-end product lifecycle: from idea generation to distribution

• Builders who develop business intuition and design taste will stand out

• Product sense becomes as important as technical fluency

How to stand out in 2026

The big theme I’m seeing for this year is: agency.

Agency to learn.

Agency to master new domains.

Agency to experiment with new AI tools.

Agency to self-teach yourself new ways of working.

The ones who redefine their role instead of defending it will lead this next year.

💬 Leave me a comment: what topics do you want to hear about in 2026?

This will be my last post of the year as we take a short Christmas break. 🎄

I’ll be back on January 5th with AI & Product Predictions for 2026.

For the last post this year, I wanted to take a moment to review the wild ride of a year 2025 has been:

Vibe coding matured

This year felt like watching the vibe coding space grow up in real time.

We moved from early, overconfident claims, like being able to vibe code DocuSign, to much more nuanced conversations about when vibe coding actually makes sense for PMs.

Along the way, we also saw meaningful progress, including new model launches like Gemini 3 Pro, that genuinely pushed the space forward.

Career conversations

Asides from product news, one of my favourite topics to write about is career development for product managers.

This year some of my most popular posts were about:

And for product leaders, how to navigate builder culture:

These posts consistently sparked the most thoughtful responses from you guys!

Fascinating product launches

Amid all the AI news, I also covered product launched I found especially interesting, from Cluely’s viral strategy, to Wealthsimple’s End of Banking Launch, to the Meta Connect demo failures, to NEO Robot’s launch-before-you’re ready strategy.

These weren’t just product launches, they were lessons in positioning, timing, and execution.

Community Milestones

Finally, I started Post MVP earlier this year with a simple goal: to connect to the product community by sharing what I’m learning about product and AI.

Looking back, it’s been a rewarding journey.

• The Post MVP newsletter base grew to 180+ subscribers

• Grew to 2.5K+ on LinkedIn

• I had the opportunity to guest speak multiple times at the University of Toronto

• I co-published an article, “The Story Behind Air Canada’s Redesign” with my mentor, Jose Platero, and one of the best product leaders I know.

But more than the numbers and unique opportunities, I’ve appreciated the thoughtful replies, conversations, and debates that followed each newsletter and Linkedin post.

Thank you for reading, replying, supporting, and sharing Post MVP this year.

I’ll be back on January 5th with Product Predictions for 2026.

Until then, I hope you take time to rest, unplug, and enjoy the magical holiday season with your family and friends.

But before you go, if you have a moment:

💬 Leave me a comment: what should Post MVP focus on more in 2026? What have been your favourite topics?

Here are three recent AI product stories that I think quietly signal where we’re heading next into 2026.

1. Cursor just launched a visual editor

Cursor is pushing “what you see is what you get” editing mixed with vibe coding with the new Visual Editor in Browser. While using Cursor, you can now visually edit components, like dragging, dropping, and tweaking grid styles, and then have the agent apply those changes directly to the code.

This might sound small, but it addresses one of the biggest frustrations in vibe coding. Until now, even minor UI adjustments required awkward prompting and back-and-forth. The loop between intent & visual outcome was brittle and frustrating.

This feature launch closes that gap.

👉 How do visually native tools like Figma and Lovable respond?

2. Google Labs is launching GenTabs

As part of a broader product suite, Disco’s GenTabs feature turns any browser tab into a custom-designed app. The product is on waitlist, which you can join here now.

The long-term implication is huge: users generating their own UX, their preferred workflows, and their micro-apps on the fly.

But there’s a tradeoff.

As Jean-Baptiste Reyt points out, this could also mean brands losing control over their own expression and experience. In 2026, this will raise another interesting question:

👉 Power will shift to the user and to AI labs, so how will brands/products own their unique experience?

3. Lovable is hiring its first Product Manager

After hitting $200M ARR in November, Lovable’s CEO Anton Osika announced plans to hire their first PM (Stockholm-based). You can view the posting here.

This is great news for the PM community. There’s been no shortage of “Cursor doesn’t have PMs” hot takes lately, but this is a reminder that the PM role isn’t dead.

A product can “get by” with only engineers and designers until they hit a certain scale.

At scale, product teams need someone to dedicate focus on:

• understanding the market,

• synthesizing customer signals

• driving the roadmap & balancing tradeoffs

That’s not a side task. It’s a full-time job.

🎄Holiday Break

In the next email, I’ll share a short year-in-review before we take a brief holiday break.

I’ll be back on January 5th with AI & Product Predictions for 2026.

But here’s the truth: PM work isn’t repetitive.

Every day looks different. New customer problems. New stakeholder asks. New fires. New features. Very little is “automatable.”

So over the last three months, I experimented with high-leverage automations: these make me sharper, faster, and more in sync with customers and the market.

Today I’m sharing 3 automations I actually use in my day-to-day. Not sponsored. Not theoretical. These genuinely make me a better PM.

Automation #1: The customer listener

The problem: Reddit is a goldmine for unfiltered customer feedback, but monitoring multiple subreddits is basically a full-time job.

The automation:

1. I use a simple Relay.app flow to watch for mentions of my company, StackAdapt, across subreddits like r/Programmatic.

2. When StackAdapt is mentioned:

   1. Relay.app finds the comment

   2. Sends me an email with the thread

   3. Logs the comment into a spreadsheet so I can aggregate everything over time

The results: I now have a continuous pulse on customer confusion points, emerging questions, and recurring themes. Bonus: I’ve surfaced multiple leads from Reddit threads and passed them to the sales team.

The level-up:

• Comment directly on posts (transparently!) to answer questions or ask for more context/feedback from customers

• Run AI analysis over your Reddit spreadsheet to extract themes

• Create an AI agent to triage comments to the right people (e.g., send leads → sales, product bugs/questions → PMs)

Automation #2: weekly competitive report

The problem: PMs must stay close to competitors, but tracking every launch, feature update, and press release is incredibly time-consuming.

The automation (I made some tweaks to the Monthly Competitive Report template)

1. Every Monday morning, Relay.app delivers a competitive intelligence report summarizing:

• Top LinkedIn posts from competitors

• New feature launches

• Press releases and announcements

• Thought leadership worth reading

I start my week reading the report and updating my mental model of the market.

The results: I feel more informed, more aware of where the market is heading, and better equipped to guide internal discussions. It’s also surfaced excellent thought leadership I wouldn’t have found on my own.

The level-up:

• Turn this into an internal competitive newsletter

• PMMs can mine it for content ideas

• PMs can push any relevant feature ideas into a backlog spreadsheet

Automation #3: The User Research Library

The problem: PMs do tons of customer interviews… but insights often die inside someone’s Miro board or Figma file. There’s rarely a shared, searchable memory for customer learnings.

The automation:

1. Use Gemini Notes (or any note-taker) for each research call

2. Create a trigger for emails titled “research session” (or your naming convention)

3. Relay.app listens for that email

4. The notes get appended into a spreadsheet called “User Research Library”

This becomes a searchable research database accessible by PMs, designers, and researchers.

The results: I can instantly Ctrl+F across months of research notes to pull quotes, validate assumptions, or see patterns. I’ve also run Gemini over the entire database to synthesize themes and generate recommendations.

The level up:

• Turn the library into a shared team asset

• Use AI agents to analyze the full dataset, surface opportunities, and spot surprising patterns over time

Final thoughts

These aren’t complicated automations. Most took <15 minutes to set up, but they’ve meaningfully improved the way I operate.

A quick note on tools: I’ve become a fan of Relay.app for setting up these workflows.

Why Relay.app over Zapier?

• Relay.app has role-specific templates (PM, PMM, Ops, etc.)

• The AI agent features are extremely easy to use

• Zapier is still excellent for general “move this data here” automations and a good all-around integrations tool

Relay.app just feels more purpose-built for the way PMs work.

💬 Comment below: What are some automations you’ve tried, or which ones would you like to try?

This year, the 3D globe is more epic than ever before:

• There’s the classic 3D globe that shows orders per minute, sales per minute, and unique shoppers

• Confetti goes off when a merchant makes their first sale

• An interactive pinball machine…just for fun

• A “computer” with engineering, design, and data notes from the team that built it

• Hidden easter eggs to unlock more fun features like a rainbow ball tail for the pinball machine

In short… it’s over-the-top, it’s totally extra, and it’s grabbing the internet’s attention during a very crowded cyber-holiday. And if the web experience weren’t enough, they paired it with a live representation of sales for different cities called “Shades of Commerce”.

Each year, I’ve watched the Shopify BFCM 3D globe get more and more ambitious and over-the-top. As a product person, this left me wondering:

Why would Shopify invest so many resources into such a complex engineering project for a single weekend?

And: is the ROI justifiable?

To answer this question, I wanted to understand the history of the globe, all the way back to 2018.

The start of the globe: 2018-2019

The initial project was pretty humble. Thanks to the Wayback machine, I got a look at the first-ever globe, which Shopify called the “Live Map” from 2018. And thanks to the Google Maps Mania blog, I found screenshot of just 2 metrics: sales per minute and orders per minute.

This was back when order volumes could still be represented using an arc.

2019 looked pretty similar to 2018, so I suspect no net-new engineering resources were pooled in.

A globe glow-up: 2020

By 2020, the Live Map was rebuilt to handle over 1 million merchants and got a major visual identity glow-up. And Shopify added a new visualization metric: carbon offsets and flash sales (visualized by a lightning bolt whenever a merchant had a flash sale).

At this moment, the globe wasn’t just a fun data visualization project: it was about signalling to the world that despite the Covid-19 pandemic, small entrepreneurship was alive & well.

A major re-architecture: 2021

By 2021, the Globe was being discussed in detail in the Shopify Engineering blog as a technical deep-dive. Because by 2021, with 1.7 million merchants on the platform, a major re-architecture of the globe was accomplished within weeks.

They also added in 2 new metrics:

• Product trends (aggregating trendy product categories)

• Unique shoppers

Going global: 2023

2023 is when Shopify really started to level up the globe. Shopify shipped a globe with city dots to represent cities with sales in the last 24 hours, and fireworks to represent a merchant’s first sale. They also introduced an easter egg: “airplane mode”, where you could hop on a Shopify airplane flying around the globe for a different POV.

And for the first time, the globe was truly becoming “global” because you could also search individual city stats.

And all of this was shared in a hyper-detailed Shopify Engineering blog post. It was becoming clear: the globe was a technical talent magnet.

Finally, the globe took on a presence in the physical world by taking a spot in the Las Vegas sphere during BFCM.

More easter eggs & fun: 2024-2025

In 2024 and 2025, the team realized how the fun & quirky “easter eggs” in the globe were actually people’s favourite parts of the globe experience.

Not the stats or the data, just fun surprise moments built into the globe.

In an interview on The Pragmatic Engineer newsletter, Daniel Beauchamp, principal AR/VR engineer explained why that is:

“A big learning last year was that visitors love an easter egg…We wondered why this feature was so liked and realized that while the Live Globe tells the story of entrepreneurship and of Shopify, these fun and delightful moments are really important for people. We took this learning and wrapped it away for the next iteration.” (source: The Pragmatic Engineer)

For 2024, the globe became just one part of a space arcade-like experience. There was interactivity on every switchboard and key in the site, and tons of easter eggs to find on the switchboard.

And finally, this year the team has continued the trend with a 3D globe inside a pinball machine.

So as we’ve seen, the evolution of this product has gone from cool & practical to maximalist, joyful, and totally over-the-top.

The product has gone from a practical information visualization tool, to a just-for-fun immersive experience with the info-viz baked in.

Which leads me back to my original question…

Building this thing is super technically challenging.

In 2024, according to this post, it took a team of 6 people 2 months to build the globe experience.

Is it super fun? Yes. Does it directly increase sales? Probably not.

So why build it at all?

Because the 3D globe works uniquely for Shopify, in ways that matter more than clicks or ROIs.

1) Earned buzz, every year

On one of the most crowded, sales-heavy, marketing-driven days of the year, Shopify manages to stand out. The globe isn’t just watched, it’s shared. People post screenshots. Hunt for Easter eggs. Journalists reference the stats. Executives tweet it.

It’s not your regular ad campaign. It’s a spectacle. And that’s why it spreads.

2) Proof of scale, without saying a word

This is a brilliant example of “show, don’t tell”. You don’t have to explain that Shopify is global, resilient, and trusted by millions of merchants. The globe shows it, live, in the most elegant way possible.

Even the smallest details, like the fireworks for a merchant’s first sale, communicate the brand ethos around enabling small entrepreneurs.

It’s a “look what you can do on our platform”, but beautiful, interactive, and shareable.

3) A magnet for technical talent

The globe is also a recruiting tool in disguise. If you’re an engineer, designer, or data nerd, this thing says: we care about craft. We’ll green-light ambitious side quests. We’ll ship things just because they’re cool.

Shopify has used it to attract and retain top engineering, design, AR/VR, and product talent. That’s not a side effect, it’s increasingly part of the point.

Don’t believe me? In the 2025 3D globe iteration, the computer section of screen is all about recruitment with an old-school careers.txt file on the virtual computer.

4) Sometimes, you just build for joy

Sometimes, when you’re big enough: you can just build for joy’s sake.

Some projects are worth doing because they make people smile. Because they surprise. Because they’re fun.

And increasingly, I’m seeing more and more examples of people building joyful software, just for the sake of it, because vibe coding tools are decreasing the costs of software development.

People are building just for fun.

And building “just for fun” is becoming part of Shopify’s culture to attract technically talented people. As Daniel Beauchamp explains it, “unserious exploration” is a legitimate way to explore new technology in the company.

The spirit of building for the fun is something all Product Builders can embrace: for culture, for team-building, and even for more practical reasons like technical exploration.

💬 Leave a comment or reply to this email:

What’s something your team has built: just for fun, and what was the impact?

• On Tuesday, Google launched Gemini 3.

• On Thursday, Nano Banana Pro dropped.

So far, the internet has been wow’d by the new image generation capabilities of Nano Banana Pro and the vibe coding capabilities of Gemini 3.

Sam Altman said it “looks like” a great model 😂, meanwhile Salesforce CEO Marc Benioff said he’s not going back to ChatGPT.

We’ve seen this before: another AI release hype cycle. What I wanted to do this week is provide some real-life use cases of useful things people are building (or could be building) with Gemini 3.

No vibe coded games or gimmicky demo videos. Just real, tangible product ideas with viable businesses behind them.

I’ve spent the week combing through X, Reddit, and Linkedin for demo videos. There’s a wave forming of vibe coding becoming more and more popular, and I want to arm this community of Product Builders, with the most compelling ideas I’m seeing.

Below are 7 categories, each with real examples + Product Builder ideas you could ship as features, businesses, and/or stand-alone apps.

1. 2D to 3D floor plan visualization

Using a 2D floor plan, you can create realistic 3D renderings.

Additionally, I saw a post on X took a single photo of a room and generated a bird’s-eye floor plan.

💡 Ideas for Product Builders

• Architecture & Real Estate → instant 3D renders for listings/brochures

• Consumer Renovation Tools → upload your floor plan, visualize your remodel

• Furniture Stores → drag-and-drop furniture in a generated 3D model

• Interior Design → “show me how this room would look in Mid-Century / Luxury Modern”

2. Website redesigns

In a Reddit post, the founder of dothistask.ai shared how they used Gemini 3 and Nano Banana to redesign their entire website.

💡 Ideas for Product Builders:

• Portfolio enhancer → Vibe-code a beautiful personal website or portfolio

• Idea validation → Gather feedback with a landing page, hero section, pricing page

• Agency model → “Send me your URL — I’ll return a new brand/design in 24 hours”

3. Interactive video apps

Zara Zheng built an app that asks her questions while she’s recording a video. Perfect for podcasters or video creators who never want dead air.

💡 Ideas for Product Builders:

• Livestream assistant → AI surfaces audience questions in real time

• Presentations → ensure you hit key points, answer common objections

• Therapy / Journaling → an AI that gently probes with follow-up questions

• Language learning → record yourself, AI helps with fluency and prompts

4. Image recognition apps

Thomas K., a MBA candidate from McGill university, built an app that recognizes waste types and tells you how to properly dispose of them.

Similarly, Allie K. Miller vibe coded an app that recognizes sign language. With Google’s image recognition capabilities, the possibilities are endless.

💡 Ideas for Product Builders

• Medicine → detect visible symptoms, rashes, swelling, bruising

• Cooking → identify ingredients and generate recipes

• Fashion → plan weekly outfits based on your closet

• Home organization → identify clutter items & recommend storage

• Accessibility → describe surroundings for visually impaired users

5. Photo and UI/UX apps

Tam Nguyen vibe-coded a screenshot beautifier for decks.

Ann Nguyen vibe coded a vintage camera photo app, with an (optional) public photo feed.

💡 Ideas for Product Builders

• Photo apps → auto-improve LinkedIn headshots, tweak backgrounds

• Social assets → “turn this text into a viral LinkedIn infographic”

• UI/UX tools → add micro-animations, redesign a screen, beautify UI states

• Onboarding flows → AI generates UI for product tours from demo videos

6. Industrial & enterprise AR apps

Yvonne built an air traffic control AR display, hinting at a world where subject-matter experts or business users vibe-code their own tools. Many of these could be in the AR space as users try to solve real-world problems on the factory floor, so to speak.

💡 Ideas for Product Builders

• Airlines → real-time customer service triage, flight seating maps

• Manufacturing → visualize, monitor, track machine health

• Food & Beverage → manage wait times, inventory, allergies

• Field services → AR overlays that guide workers step-by-step

• Retail → auto-generated floor plans, restocking insights, shopper heatmaps

7. Educational Apps

Right now, people are using Nano Banana Pro to create whiteboards from academic papers or long YouTube videos.

And academics like Anders Sandberg are using it to create diagrams from academic papers.

And even Sundar Pichai showed how beautiful infographics can be created from famous locations like the Golden Gate Bridge.

And finally, this fascinating time travel example from Min Choi shows how you can use time and geographic coordinates to create photo-realistic representations of historical events.

While none of these are vibe coded apps, my head immediately went to all the possibilities in education. And this also presents a huge opportunity: the most mind-blowing educational use cases from Gemini 3 and Nano Banana Pro haven’t even been productized yet.

💡 Ideas for Product Builders

• Historical learning → lifelike scenes of Rome, Mecca, ancient China

• Religious education → visualize stories from scripture

• Personalized tutoring → your own private whiteboard session with any expert

• Kids apps → turn homework explanations into comic strips

• University tools → convert dense papers into diagrams + walkthrough videos

What Product Builders need to know

Gemini 3 is making software feel conversational. Nano Banana Pro is making visual creativity infinite. Combining the 2 together gives product builders a world of possibilities.

💬 What are you building this week?

If you liked this story, check out my other posts on vibe coding: