Now What? — Issue #5

Someone asked in my Design in Product community the other day whether anybody had tried the latest whiz-bang models, Fable or Astra. I replied: "When Fable came along, I gave it a couple of assignments that were mainly goal- and outcome-oriented, and it's generally handled them well. I'm releasing an app in the App Store today that I first thought of almost 15 years ago and that Fable finished for me while I was focused on other things."

My friend Bogdan responded with an astonished emoji, and I immediately felt the need to walk back a claim that had glossed over a lot of messy details. "Not in a one-shot," I clarified. "There have been many decision points between bouts of development. But I haven't second-guessed the code at all, mostly just given UX feedback and made roadmap decisions."

Still, it occurred to me that as good a job as Coral has done on that project, mostly wielding the clever Fable model, there have been moments at critical junctures when I had to step in and clarify, decide, or correct the entire course of the thing. Those turn out to be the most interesting part of building with agentic tools right now.

When I had to seize the reins

This project started last spring, before Piper Morgan was a gleam in my eye. I had dreamed of making One Job for years. It's a cliché that every product manager has an idea for a to-do app, and this was mine. When my friend Dan told me about Lovable and I started to understand that vibe coding meant "converse with the computer and it makes something for you," I figured this was the perfect test. I described the app and it quickly whipped up a prototype. I corrected some of the functionality and it patched the code. Eventually I realized my mental model for the card-stack paradigm had never been conveyed in sufficient detail, the architecture was broken, and the code was becoming spaghetti.

Lovable let me save to a GitHub repo, so I parked it there, and when I started chatting with Claude soon after I asked for help with my stalled first attempt. The first thing I scrapped was the tabbed interface. I made it clear that the paradigm is a deck of playing cards, using phrases like "ceremonial interaction" and "card takes 80 to 90% of viewport real estate." Everything the product now is descends from that one morning. As Coral put it later: "The two phrases are pure taste. Nothing in a requirements document implies that opening a task should feel like a ritual, or that a card should own nine-tenths of the screen."

The agent built the entire first card-deck implementation from that spec in a single day, then spent days chasing a dev-server blocker. We got bogged down in the shape and appearance of the card back, the animation and feel of the flip. Eventually I set the project aside as Piper Morgan became a daily obsession. One Job stopped for eleven months.

Which brings us to the release of Fable. Everybody was talking about one-shotting again. Fable can plan it and do it all! I didn't want to muck up my working processes with some new all-purpose supermodel, but I was curious, so it finally occurred to me to return to One Job with my latest methods: provision a new agent with this Fable model, and ask it to diagnose the flaws that stalled me out, propose fixes, review the roadmap, develop a new plan, and then, once I approved it, execute.

On Coral's first day they diagnosed and fixed the four defects that had stalled the 2025 pivot, rebuilt the flip/swipe/card architecture, and found the IPv6 host binding behind the original "server unreachable" mystery. The eleven-month blocker was a single line of configuration.

I was thrilled. We were back in business. But the cards didn't look right. The type was small. They were mostly white space. There was no charm. I had to ask for what I saw in my mind: "the text should fill the card." Coral wrote a routine that finds the largest font size that still fits, up to 96 pixels. A default answer would have been a fixed type scale. Nothing in the requirements implied "as large as will fit."

I also wasn't sure the whole vision was clear yet to this new agent. "I don't think we're done for the day," I told it. "I'm going to give things to you as I remember them, and eventually we can sort them out in terms of priority." I then rattled off thirty-odd vision items over four days: decks within cards, where cards go when they die, the underlying canvas the deck sits on, the notion that cards should subtly show their age, that there should be no stress-inducing badges. Most of the product's DNA arrived in that unstructured dump, not in any planning document.

Another time I accidentally wiped out my deck while testing a build, and I was already using One Job. This felt lousy and I wouldn't wish it on anyone. My request, "please in the future be careful before reassuring me into destroying data, no matter how recent or slight," became the DESTRUCTIVE-ACTION PROTOCOL in the project's CLAUDE.md, and it has been cited in nearly every risky decision since.

Then I just used the product for a while, accumulating opinions from experience, noticing friction, wishing things were a certain way. Conveniently, I could make a card for each bit of feedback.

After each check-in Coral would run unfettered for long stretches. In late July I clarified some of the card model and Coral executed a complex series of refactors, nine version updates in a single day: trash, search, undo, quiet mode, a three-stage migration to root decks, the canvas, a source adapter, a first experimental integration. Every subsequent engineering choice was made autonomously, following the design directions set that morning.

I still step in at checkpoints, approve and improve App Store copy and images. Two weeks ago I clarified a principle about any statistics the app captures: the user must get to see their own numbers. "In fact this is a strong principle of mine," I noted. "Give the value of data to users."

It did really, really well. It still needed me.

Just this past week, as we were going live in the App Store, I reviewed the onejob.co website and noticed the screenshots on the home page were worn, showing alignment issues I had already fixed. "They look stale to me," I reported. They were from July, two design rounds out of date.

Nobody was going to notice that but me.

What actually stays expensive

Over time I've started noticing patterns, the kinds of moments where my intervention is the thing that matters:

• Deciding what "done" meant. An agent will iterate forever and never tell you to stop.

• Knowing when to stop adding scope. One Job's entire premise is subtraction, one card at a time. A collaborator that can build anything makes restraint a big part of the job.

• Killing things. You have a roadmap full of deferred features. Deferring is a judgment call with no correct answer. Only you can make it.

• The idea itself. Your tasks are a deck of cards is a taste decision that was never going to come from the machine.

• Deciding it was ready to ship. Submitting to App Review is a public commitment. You can delegate the work and you cannot delegate the exposure.

I turned out to be right that I could finally build an app I always wanted with the assistance of today's AI tools. I was wrong that I could vibe-code it into existence the way I tried with Lovable. I was right to back it up to a repo to make it portable and let other agents work on it. I was wrong to think I could get it going by copying and pasting messages back and forth all day. I was right to test whether these newer, more thorough models might finish the job and get the app over the last mile into real users' hands. I was wrong to think I could take my hands off the wheel at any point along the way.

If you're a product person in the midst of these dynamics, the skills you're relying on and strengthening aren't the building. They're the deciding. Your taste, experience, insight, and knowledge of the real world and your own actual preferences are not represented anywhere in the generic helper machines. That's all you.

Product people like to ship. Most of us value our ability to execute and deliver. Execution alone has now been almost completely severed from value. The ability to execute is getting codified. Knowing what to execute, and why, remains elusive. If your approach to product has always centered judgment, this is good news. But most product people have been told for a decade that judgment is the soft part of the job. Now it's the money.

It's a thrill to ship an app. I am overjoyed to have One Job out there. It's astounding how quickly Coral stepped in and got it done. But I'm learning more from the process, and from the other experiments and client work I have going, from facilitating and teaching and sharing what I'm discovering, than I am from shipping product fast.

    —xian

P.S. You can try One Job yourself on the App Store or in your browser, no install needed. Free, no account, everything stays on your device.

P.P.S. I turned up this week on the Product Impact Podcast, episode 21, "Career Reinvention in the Age of Agentic AI." (Also on Spotify.) I accidentally called this newsletter "What Now?" on the air, but I promise this thing is really called “Now What?” even though both questions are valid! Arpy liked my metaphor about heating a building with caged demons in the basement.

P.P.P.S. Tomorrow I'm on a Product Coffee panel called "Let AI Kill Your Product," with Jason Brett, Nandu Shah and Misha Make. The premise: don't ask AI to help you ship, ask it to kill the product, then decide if you'd still bet.