Try more ideas. Keep the bar high.

I felt powerful. Then I felt shaken.

The start of 2026 felt like a sea change in what was possible with agentic development. During Airspace’s Innovation Week alone, I built two functional apps aimed at telling the Airspace story in a conference setting. One was Relax, It’s Airspace, a calm globe-and-sound piece that turned time-critical shipping inside out: once Airspace has your package, you can relax. The other was driven by hand tracking. I am a director of product, not an engineer, and in one week I had built two things I could not have dreamed of building myself a year earlier. It felt enormously powerful.

It also shook me. If I could push an idea straight into working code, so could anyone. When code gets cheap, a team can produce a great deal very quickly without producing anything better, and I could see exactly how bad that might get. Often features sound good on paper, but products rely on cohesion, and a soup of poorly planned features can feel overwhelming and sloppy. A slow, feature-packed mess of our platform flashed before my eyes. Gulp.

Feature lust, now at machine speed.

At a basic level, good product practice isn’t that complicated. Before you build the thing someone asked for, you find the problem underneath it and check that what they asked for will actually solve it. A lot of the job is that, and most product people do it by reflex.

Almost nobody else does, and there is no reason they should. Executives, engineers, operators, salespeople, account managers: they are all waiting on a feature that will fix a problem they can already feel. Asking them to stop and articulate that problem first is asking them to do a product manager’s job for free.

With AI in the mix, that urge stops being harmless. What could break Airspace was never the code getting cheap. It was what people would want to do with it.

Then, a spark. A future of piles upon piles of code was inevitable. The challenge was to embrace it. What if I could get people to naturally embrace good product practice? What if I could make it feel worthwhile, even… fun?

Make the case before you make the thing.

The shape came from Shape Up, Ryan Singer’s book out of Basecamp. We studied it at Airspace for a while and never found a way to fit it into how we actually worked. Its core is a betting table: people pitch ideas, every pitch carries an appetite for how much time it is worth, and the best ones get picked up.

With the influx of cheap code, Shape Up suddenly seemed relevant again. Now we could plausibly build inside the two, three, and six week windows the book describes.

Product Lab takes that abstract process and gives it somewhere concrete to live. At its core Product Lab is a marketplace for feature requests. You sign in with your Airspace Google account and submit an idea: who it is for, and why it is a business problem worth solving. Then you invite other people to sponsor it. Everyone gets an allowance of sponsor money each week, and once an idea attracts enough investment it moves up into the prototyping process.

Then I ran the process on itself.

So I built Product Lab to meet the need I have just described, and it turned out to be a very good vehicle for it. It was not an instant hit. My assumptions got challenged more than once along the way.

Today most submissions come from outside the product team, and most of the most popular ideas of all time came from somewhere other than product. The most popular idea of all time was submitted by an operations specialist.

It was not a universally popular idea. The worry I heard back, over and over, was that you cannot just let anybody make something. I sat with that for a while and landed somewhere uncomfortable: I agreed with the fear and disagreed with the conclusion. Nobody is going to stop this from happening. The only real choice is what we ask of people while they do it.

The part I did not plan was what building it taught me. To make Product Lab work I had to run the exact process it asks of everyone else, on myself, in public. I had a hypothesis. I was wrong about it twice. It only started working once I stopped explaining the value and handed it over instead. If you want people to embrace good practice, the practice has to survive contact with them first.

The work becomes more valuable when the learning travels.

The AI team used Product Kit to give its AI Operator thesis, AI that earns autonomy inside real operations work, a form people could click through and argue with, and to stage the path toward it. A product leader in another vertical paired the practice with an internal data workflow: find where everyday tasks stall, measure the volume, and let the evidence line up the next piece of work. In both cases, prototypes got easier to make, and the learning moved between teams instead of staying where it started.

Product Lab and Product Kit are now part of how the Airspace product team explores. The next question is always the same: does this make the idea clearer, more testable, and easier for the right people to improve?

From a weekend hack to a new, validated way of working.

Product Lab proved what was possible: that a clear problem, a second believer, and a working prototype could make ideas better and pull good thinking in from across the company. The next step was to make it standard, not a side project. I used the same ideas to design Airspace’s R&D process, an official cadence the roughly fifty people in R&D now use to evaluate ideas, decide which ones earn backing, and distribute resources against them.

It turns the experiment’s instincts into a repeatable rhythm: ideas get a clear form, evidence and sponsorship decide what graduates, and resourcing follows the strongest cases rather than the loudest voice. What began as a way to make a single prototype more honest became the way a fifty-person organization chooses what to build.