3 Problems That Stall Builds & How to Fix Them
Building for yourself is harder than building for others.
I've watched 20+ people prove it in the Build Like A Pro workshops over the last six weeks.
Gym employees, researchers, designers, coaches, career-changers, front-desk leads. Many weren't in product development at all. Most built easily. Some struggled. Here are the differences.
A gym owner built a dashboard tracking new members' first X visits in Y days. His ops lead converted the first chapter of an 118-page printed playbook into something staff could use during a shift. A sales lead built a retention radar that told her which prospects to contact and when. These aren't simple problems. They got built, they got shared, they moved forward.
Others tried to build something for themselves. A portfolio site. An expertise showcase. A personal landing page. Those often stalled.
I initially thought the split was AI-savvy researchers versus everyone else, or product people versus outsiders. It isn't. The split is about the target of the build. When the build isn't about you and has edges, you typically have a brief — and you build better and faster because there's a goal post. When the build is you, for you, or has no edges, three problems seem to compound, in the order they show up.
1. There's no brief.
When you build for someone else, the brief writes itself. New members are dropping off before X visits, so the tracker needs to show who's on track and who isn't. Leads are getting lost across paper lists and DMs, so the workbench needs one view of each prospect and the next action. The problem writes the brief. It has a goal post, edges, and a distinct purpose — exactly like a research recommendation.
When you build for yourself, you likely skip this part. No brief. No goal post. No edges. You start with the thing itself (the header, the hero image, the About section) because it feels like you already know what you want. You've been ruminating for eons.
Except you haven't been thinking about the object, the form factor, the interaction. You've been thinking about what the object should convey about you. Both feel like prep to inform a build. The build skill we're focusing on is the former, not the latter.
The brief doesn't have to be long. Three sentences. What is this, specifically? Who is it for, well-defined? What does success look and interact like, concretely? Without it, every question routes back to your gut, and your gut has a stake, and you rewrite the same paragraph six times. The paragraph isn't the problem. The missing goal post is.
2. You substitute the skill you know for the skill you came to learn.
On the expertise showcase project, people come to build something about themselves. Quickly, they aren't building anymore. They're rewriting the About paragraph, the tagline, the bio.
Writing feels like progress. It isn't the goal. The goal is to build the thing. Without a brief, there's nothing concrete to build toward. Without a definition of the interaction or a clear reference for the finished object, there is nothing to show the tool what "good" looks like. So the builder often retreats to the more familiar task: writing.
The brief keeps you focused on the build opposed to the endless rewrite.
3. You can't see the shape of a build the first time you make one.
This is the rung that explains the other two.
Anyone who has done specific work many times looks at a rough version and recognizes it as a work in progress. A researcher looks at a draft screener and sees a screener. A designer looks at a rough wireframe and sees a wireframe. They've created a hundred of them. They know what the finished version looks like — they're just not there yet. It's a familiar trajectory. They trust it because they know you have to crawl, walk, run.
A first-time builder doesn't have that trajectory. They're looking at their v1 with no mental image of v3 or v10, because they've never made one. And they may not have written the brief, so there's no goal post. "I'll know it when I see it" is not the answer. They have no way to answer, from the inside, whether what they're looking at is scaffolding or failure.
One student was building a spec sheet for his client — a real, external target, with a clear brief. He kept saying, "This isn't client-ready." He wanted the end result, faster. He couldn't see that the rough version was the foundation of the end goal. That was a first-time-builder problem, not a brief problem. He'd never been in the messy middle-build before.
That's why "just iterate" and "done is better than perfect: don't feel right on personal projects. When the work is about you, the mental model gap isn't the only problem — the very close and personal proximity is too.
Repetition is the fix. Build one, iterate at least five turns, then build another. The mindset is learned.
The order matters.
Without the brief, every rough version can feel like it's failing at some unnamed thing.
Without a target, you can't tell you've slipped from building into rewriting.
Without the map, you can't tell whether you're on rung two or off the ladder.
The brief is something you can write in ten minutes before you start. The wrong-mode substitution is something you can catch in yourself — the moment you find yourself rewriting the About paragraph again, that's the tell. But the map you can only get by building. The first thing you make for yourself is harder than anything you'll make for anyone else, because you're building the map and the thing at the same time. It's like driving the bus while changing the tires, blindfolded.
How to fix them.
Fix 1 is a brief you write before you touch the tool. For a personal project, three sentences aren't enough. You need answers to five specific questions: what is the object (concretely, not "a portfolio"), who is it for (specifically, not "hiring managers"), what decision does it help them make, what does success look like for them (yes, them — they are the end user), and one aesthetic reference that matches your audience — not just your taste. If you can't answer one, focus on that part first. Not in the tool.
Fixes 2 and 3 — the tell for catching yourself when writing has replaced building, and what repetition actually teaches you about your own map — I share those, along with many other tips, prompts, and examples I use when I build, with all workshop registrants and previous attendees. It's an extensive live, living Build Like A Pro Prompt Library.The personal projects template for the expertise showcase is brand spanking new, born out of watching the drift live.
That's what the Build workshop is for.
Three hours, live, capped at 8. We cover three mediums. You pick what fits your curiosity or your current work. You'll leave with something you can put in front of someone the same day — with the brief written first, so you're building the thing, not rewriting the About paragraph.
Starting with the next session, every learner will be asked to write their brief before we build. Especially for the expertise showcase project. The brief is the fix for problem one. The workshop is the fix for problems two and three.
Two seats left for Tuesday, July 21 · 3–6pm PT / 6-9pm ET. $197. Between roles and want to join?
Can't make July 21? Two new dates just added:
Wednesday, July 29 · 9am–12pm PT
Tuesday, August 4 · 3–6pm PT
One seat per course is reserved for those currently unemployed at a 50% discount. Hit reply for the discount code.
Who is this for? Anyone...
Who wants dedicated, structured time to explore and get live feedback
Stuck on a portfolio, showcase, or personal landing page
Building a dashboard, tracker, or workbench for their team
With a research recommendation or business need, they want to make tangible
With a fix in mind, who wants to show it, not describe it
P.S. If you're stuck mid-build right now, I have two questions:
Did you write a brief with a defined, specific end goal?
What changed between not-seeing-it and starting-to-see-it?
I've built so many things I can't remember those moments anymore — but you might, and I'd love to hear about them. Hit reply.
P.P.S. "A brief? That's it? I don't need a workshop for that." Writing a brief is simple. Writing one before you start when the object is you is not. That's what the workshop's structured block, live support, and three-hour cap are for. The brief is the input. The build is the skill.
Speak up, get involved, and share the love!
Connect with Michele on LinkedIn for more UXR tips and UX discussions.
Read about Curiosity Tank workshops.
Interested in team user research training? Let us know!
Participate as an On-Demand for less!
Dive into a different UX Research term every week! Sign up for UX Lex weekly emails here.
Forward this email to someone you think might enjoy it. Better yet, sign them up here. It will be the gift that keeps on giving.
