Work
You can almost hear the collective flashback to the last time someone said that, and the six months that vanished into the void. Welcome to the eternal tension: when do you build, when do you mock, and how do you get feedback before you’ve sunk half a year (and a chunk of your soul) into the wrong thing?
The problem with building too soon.
Product teams are a hopeful bunch. We want to believe we’ve nailed the solution. But the truth is, most of our “brilliant” ideas are just guesses with a fancy Figma skin. If you build too soon, you risk investing time, money, and emotional energy into something nobody wants. (Ask me about when I built a “revolutionary” dashboard that users promptly ignored. Actually, don’t. I’m still in therapy.)
The heart of modern product discovery is rapid experimentation. You create quick, cheap tests to see if your hunch is even in the correct postcode. This isn’t just about risk reduction; it’s about innovation. Some of the best ideas look daft initially, but survive because they’re tested in the wild, not just in a boardroom.
The art of the mock:
Why faking it works.
Enter the prototype. Not the “let’s spend three weeks making it pixel-perfect” prototype. I mean the scrappy, “don’t look behind the curtain” version that’s just good enough to get feedback. Sometimes, you’re not even faking the feature-you’re faking the entire product. (If you’re not slightly embarrassed by your prototype, you probably spent too long on it.)
This approach is convenient when you’re not sure you’re solving the right problem or the solution is technically risky. Mocks and clickable prototypes let you test the user experience, the value proposition, and the basic workflow without writing a single line of production code.
The best part? You can show it to real users, stakeholders, and even your team and get honest reactions. If they don’t get it or don’t care, you’ve saved yourself months of work (and a few existential crises).
When to build, when to mock.
Mock it when:
- You’re still validating the problem or the solution.
- The technical path is unclear or risky.
- You need quick feedback from users or stakeholders.
- You’re not sure if anyone will care.
Build it when:
- You’ve validated the core value and user flow with prototypes.
- You need to test technical feasibility or performance at scale.
- You’re ready for real-world usage and data collection.
- You’ve already faked it, and people are still excited.
In other words: mock early, build late. And if you’re not sure? Mock it. The worst that can happen is a bruised ego when your “genius” idea flops in front of a user. That’s a lot cheaper than a failed launch.
Getting feedback without the pain.
Feedback is the lifeblood of product development. But getting it early is tricky. Users are polite. Stakeholders are opinionated. And everyone’s busy.
Here’s what’s worked (and what hasn’t) for our team:
- Show, don’t tell: Don’t describe the feature; let people click through it. You’ll spot confusion and delight in real time.
- Test with real users: Not just your colleagues, who are contractually obligated to say nice things. Find actual customers, or at least people who look like them.
- Embrace awkward silences: If someone frowns at your prototype and says nothing, that’s feedback. Don’t fill the silence, let them process.
- Iterate shamelessly: If your first mock doesn’t land, change it. Don’t get attached. (My record is five iterations in a single afternoon, powered by coffee and mild panic.)
- Mix qualitative and quantitative: Watch what people do, not just what they say. If possible, use simple analytics even on prototypes to measure engagement.
Real-world lessons
(& a few bruises).
Our team once spent weeks debating a new onboarding flow. Should it be a wizard? A checklist? A friendly chatbot? We mocked up all three. Turns out, users just wanted to skip it and get to the product. The winning design? A single “Skip” button. (We laughed, then cried, then shipped it.)
Another time, we tried to automate a recommendation engine. Before building anything, we faked it with a human behind the scenes, sending “automated” recommendations. Users loved it. Only then did we invest in the real tech. Sometimes, the best MVP is a person with a spreadsheet.
We’ve also learned the hard way that not every stakeholder wants to see every iteration. Some want the big picture; others want to nitpick the font. Knowing who to involve (and when) is half the battle.
What worked, what didn’t,
& what we learned.
What worked:
- Rapid prototyping with low-fidelity mocks.
- Testing with real users early and often.
- Iterating based on actual feedback, not just opinions.
- Keeping the team aligned on the problem, not just the solution.
What didn't:
- Building too much, too soon, and getting attached to the wrong ideas.
- Assuming we knew what users wanted without showing them anything.
- Waiting for “perfect” before testing-by then, it was too late.
What we learned:
- Faking it is not just allowed-it’s essential. Prototypes are disposable learning tools, not precious artifacts.
- Feedback is only useful if you’re willing to act on it, even if it stings.
- The sooner you can kill a bad idea, the more time you have for the good ones.
The impact on product and people.
Rapid prototyping hasn’t just made our products better-it’s made our team braver. We’re less afraid to try weird ideas, knowing we can test them fast and move on. There’s less finger-pointing and more curiosity. We laugh more (sometimes at our own expense) and ship faster. And when we get it wrong, at least we haven’t wasted half a year—just a few afternoons, a handful of sticky notes, and maybe some dignity.
Ultimately, faking it until you make it isn’t about cutting corners. It’s about learning quickly, staying humble, and building the right thing before you build the thing right. And if you can laugh about it along the way, even better.
If you’ll excuse me, I have a new prototype to test. It’s held together with duct tape and optimism. Just the way I like it.
Keep Reading
ALL POSTS
