Key Takeaways

  • Josh Woodward runs Google Labs with an internal document containing 82 predictions, each beginning with “we believe the future is” or "we predict."
  • Scheduled design sprints rarely generate breakthrough software, because high-impact ideas cannot be microwaved on a calendar invite.
  • Google Labs monitors an "almost possible" list to catch the phase shifts where emerging technical capabilities suddenly turn viable.
  • Early product-market fit in AI prototypes registers in physical eye reactions during live tests rather than lagging dashboard metrics.
  • Sustainable AI products require pairing newly unlocked technical capabilities with authentic user problems people will pay to solve.

Stop Microwaving Ideas on Google Calendar

Woodward has watched corporate teams repeatedly try to schedule creativity. They block out an offsite, run a four-day sprint, and expect a category-defining product by Friday afternoon. It almost never works. As Woodward puts it: “They very rarely, at least in my experience, have come from design sprints or times where you set aside on a calendar, okay, this is where we're going to go come up with our next idea.”

Great concepts arrive through unstructured tinkering by curious builders chasing weird technical edges. “You can't microwave good ideas,” Woodward says. When engineers build passion projects late at night, they collide with technical realities faster than any product manager writing a strategy brief.

Track Phase Shifts with the 'Almost Possible' List

Instead of scheduling brainstorms, Google Labs tracks the frontier. The team keeps a running document of 82 predictions that all begin with "we believe the future is" or "we predict." Alongside those predictions sits an active list of what Woodward terms "almost possible" capabilities.

The framework mirrors physics. A gas does not become a liquid through gradual persuasion; it crosses a threshold temperature and changes state. Software capabilities work the exact same way. “We have a phrase on the team we talk about what's almost possible and we just have a list actually where we're trying to track those things,” Woodward explains. “When one crosses over it's almost like a phase shift when something goes from like solid to gas or liquid to gas or something.”

Tracking the frontier this way prevents you from building six months too early or two years too late. If you build before the model capability crosses that threshold, your product feels brittle and fails. If you wait until the API is stable and obvious, hundreds of competitors launch on the same morning.

Match Fresh Capabilities to Problems People Pay For

A technical phase shift on its own is just a party trick. A clever demo earns social media retweets, but software businesses require customers who will pull out a credit card.

Woodward stresses that founders must anchor these emerging technical shifts to painful human bottlenecks. “And then of course tech alone isn't enough, you've got to kind of match that to an interesting user problem,” Woodward notes. “And ideally, if you can put those together in a way that's so good, people will pay for it.”

Do not look at retention curves or funnel conversions during the first test. Watch the user's face. When an AI tool genuinely solves a bottleneck, you see their eyes widen in real time. If their eyes stay flat while they politely nod at your demo, no amount of conversion optimization will save the product.

What to Do With This

Open a clean document tomorrow morning and list five technical capabilities that are currently unreliable or too slow in production. Under each entry, write the exact problem users will pay you to solve the moment that capability crosses into viability. Check that list against every new model release.