How I Build Products in Spring 2026
The bottleneck I find isn't with building anymore, but rather knowing what to build.
With AI, I can go from "I think there's a problem here" to a working product in hours. But the speed only matters if you're pointed at the right problem. The tooling doesn't help you if you're building the wrong thing fast.
Here's how my pipeline actually works end-to-end.
Start with the problem, not the solution
I spend more time on research, but not on formal, multi-week studies. Instead, I'm reviewing customer comments, product notes, interview transcripts, and support logs. Running SQL against databases to see what users actually do versus what they say they do. Looking at session replays. Reading through analytics dashboards and Gong recordings at 1.5x speed.
The goal is to find the gap between what exists and what should exist. And it has to be specific. "Users are frustrated" isn't a problem statement. "Users drop off at step 3 of onboarding because the verification flow requires a document they don't have on their phone" is a problem statement.
PostHog published a whole thesis about how PMs are broken and engineers should own product decisions. I agree with parts of it. Measure outcomes, not output. Keep teams small. Get builders close to customers. Those are universally true. But the "engineers decide everything" model is built for product-led growth companies selling to developers. If you're building an enterprise platform where the buyer isn't the user and six product lines need to tell a coherent story, someone has to hold the strategic frame. That's not gatekeeping. That's the job.
One thing I've gotten sharper about: every research sprint needs to end with a decision, not a readout. "We learned X, so we're doing Y." If the research doesn't connect to an action, it was a waste of time.
Plan before I build
Planning is not execution, and so I keep those separate on purpose.
I use Obsidian to structure my thinking. Everything starts as rough notes, links between ideas, connections to past decisions. When something is ready to become a project, I write a PRD in Claude. Not a 30-page spec. A clear statement of the problem, the approach, what success looks like, and what I'm explicitly not doing.
The PRD matters because it forces me to articulate the bet I want to make before o write a line of code. I've also changed my approach to metrics: I now treat metrics instrumentation as a prerequisite, not a follow-up. If you can't define how you'll measure whether this bet paid off before you build it, you're not ready to build it. I've seen what happens when I skip this step. I ship features, and I think they're working, and six months later, you realize I have no data to prove it either way.
I use Claude in plan mode for this phase. Have strong opinions, even if they're wrong. LLMs are too agreeable by default. If I tell Claude my approach and it just says "great idea," that's not useful. I want it to push back. And I need to feel empowered to stop it when it's going in the wrong direction. The model is a thinking partner, not an authority.
Design with Claude
For UI/UX, I use Claude to iterate on designs fast. I describe what I want, it generates options, I react, and we go back and forth. It's not replacing a senior designer's judgment. But for the kind of products I'm building right now, like the Watch.Uristocrat.com or the Uristocrat Mixtape, it gets me to a good-enough interface in hours instead of days.
The key is being specific about what I want and what I don't want. Vague prompts get vague designs. "Make it clean" means nothing. "Single column layout, no sidebar, data table with sortable columns, dark background" gets you somewhere useful.
Build with Claude Code
This is where the speed gets real. I write the PRD, plan the approach, and then use Claude Code to implement it.
I've shipped a real-time NYC subway tracker, a sports market arbitrage tool, and an x402 payment tool this way. Projects that would have taken weeks with traditional development are done in days.
A few things I've learned:
- Start fresh conversations for different parts of the project. Long conversations cause what I call context rot. The model's quality degrades as the context window fills up. New chat, clean context, better output.
- Use plan mode in Claude Code before you start writing code. Same principle as the PRD. Think first, build second.
- Deploy to a live URL fast. I use Cloudflare Workers. Having something real to look at changes the conversation from hypothetical to concrete.
QA with Claude and Codex
For PR review and quality checks, I use a combination of Claude and Codex. They catch things I miss. Type errors, edge cases, security issues, inconsistencies with the rest of the codebase. It's not perfect, but it's a second pair of eyes that's always available and never tired.
The bigger value is speed. I can ship a feature, get it reviewed, fix issues, and merge in the same session. The feedback loop that used to take days now takes minutes.
Instrument from day one
This is the part most people skip and then regret. I built metrics tracking into the plan from the start. Not after launch. Not "when we have time."
Because if you're iterating fast, you need to know fast whether what you shipped is working. Vibes aren't data. I've worked on projects that were losing revenue and had no infrastructure to track detailed metrics. Everyone had opinions about what was working. Nobody had numbers.
Faster iteration only compounds if you have the feedback signal to learn from each cycle. Otherwise, you're just shipping faster in the wrong direction.
Retro on bets
The last piece, and honestly, the one that took me longest to get right. Run retrospectives on bets, not just sprints.
Most teams do sprint retros. What went well, what didn't, how do we improve the process? That's fine for execution. But it doesn't answer the harder question: did the bet itself pay off?
I do project reviews now. Here's what we bet on, here's the data, here's what actually happened. Did this move the metric we said it would? If not, what did we learn? These reviews need real data, not stories. And they need to be shared widely so everyone can see the results, not just the team that built it.
This is the accountability loop that makes the whole pipeline work. You can research, plan, design, build, and ship faster than ever. But if you're not closing the loop on whether your bets paid off, you're just doing more stuff. Outcomes over output only work if you actually measure the outcomes.
Where this breaks down
I want to be honest about the limits. This pipeline works well for products where I'm the PM, the designer, and the engineer. Solo or small team, clear problem, fast iteration.
It gets harder when you're coordinating across multiple product lines, managing enterprise sales narratives, and dealing with reactive pressure from customers at risk of churn. I've lived in that world too. The principles are the same, but the execution requires more people, more coordination, and more explicit decision-making frameworks. AI can help with that, too, but that's for another day.
Some of my recent projects
uristocrat
Member discussion