Week one at Sell2Rent. I’m sitting in a marketing meeting at 10am and a dev standup at 11am. The marketing team is talking about lead acquisition. The dev team is talking about form architecture. Nobody in either room knows what the other room just discussed.
There’s no product roadmap. No design system. No documentation that connects what marketing promises to what the product delivers. The VP of Marketing is about to leave. The CRM has been paid for four months and nobody’s used it.Most designers would see that and think: we need process. We need structure. We need a roadmap. I’ve learned, after 8 years in early-stage startups, that the opposite is true. Before product-market fit, the most important skill isn’t design. It’s knowing how little structure you actually need.
What Product-Market Fit Actually Looks Like (It’s Not a Launch)
Marc Andreessen describes PMF as systemic overwhelm. Customers buying faster than you can serve them. Usage threatening server stability. Support tickets piling up because people care enough to complain.
Until you reach that threshold, the only metric that matters is how fast you’re learning. Not how many features you shipped. Not how clean your Figma files are. Not how comprehensive your design system is. How fast you’re learning what users actually need and whether you’re building it.
At Sell2Rent, we lost our primary lead partner. Over 50% of our leads disappeared. The response wasn’t a three-month strategy document. It was hundreds of CRO tests, landing page variations, and conversion experiments. 76% more organic leads in four months. That speed of iteration only happened because we weren’t weighed down by process that didn’t serve the problem.
Why Traditional Process Kills You Pre-PMF
I’ve worked on projects with full roadmaps, detailed user stories, and centralized decision-making. Some of them still failed.
Keller Offers had 64 screens, a design system built on MUI, and prototype testing with real users. NPS came back at 90. The project was pulled by the client at final delivery. Not because the design was wrong. Because the structural process around it was broken in ways that no amount of documentation would have fixed.
The two process traps I see kill early-stage teams:
The roadmap trap. Any plan longer than two to four weeks pre-PMF is fiction. You’re guessing what users will need based on assumptions that haven’t been validated. The plan creates a false sense of progress while the real learning stalls.
Abstraction friction. This is the one nobody talks about. Detailed documentation, exhaustive user stories, annotated wireframes. Sometimes the spec takes longer to write than the feature takes to build. That’s not process. That’s intellectual debt disguised as rigor.
This doesn’t mean you work without any structure. It means the structure has to be minimal, rigid in cadence, and flexible in direction.
The Operating Rhythm That Actually Works
After working across Mentive, Customela, Keller Offers, and now Sell2Rent, here’s the rhythm I’ve settled on for pre-PMF teams:
Two-week cycles with a single goal. Not a list of features. One goal: improve retention, increase activation, reduce time-to-value. Everything the team ships in those 14 days serves that one goal. If an idea doesn’t connect to it, it waits.
Grade everything before you build it. Engineers tag ideas as easy, medium, or hard. Nothing that takes more than one cycle gets approved. If it’s too big, break it down or kill it. This prevents the scope creep that quietly eats startups alive.
Measurement before code. The analytics for a feature get defined before anyone writes a line of code. Not after. Not during. Before. This is the same principle behind talking to dev before opening Figma: align on what success looks like before you start building.
At Sell2Rent, this rhythm let me run CRO experiments, CRM migrations, and product design in parallel without drowning. The cadence was the constraint that made the chaos manageable.
The Founding Designer: Specialist Is a Luxury You Can’t Afford
In a mature company, you can be a “product designer” and that means one thing. In a pre-PMF startup, it means everything.
At Sell2Rent, my job title says Senior Product Designer. My actual job is product design, CRO, marketing automation, HubSpot architecture, SEO, brand strategy, and now AI tooling. That’s not scope creep. That’s what “product designer” means when you’re the only one in a 35-person company.
The founding designer role requires three capabilities that design school doesn’t teach:
Code enough to prototype in the real medium. I use v0 to take Figma designs and generate functional React components. The back-end stays with dev. But when I hand off a working prototype instead of a static mockup, the conversation with engineering changes entirely. The gap between design intent and built product, the gap that killed Keller Offers, gets compressed.
Skip wireframes when speed matters more than documentation. In early stage, going from paper sketch to high-fidelity prototype in a day beats spending three days on annotated wireframes nobody reads. The goal is validation, not documentation.Polish strategically. There’s real research showing that aesthetic quality builds early trust even when the feature set is incomplete. A clean, professional interface compensates for bugs and missing features in ways that a functional-but-ugly product can’t. This matters especially when every potential lead at Sell2Rent represents real revenue.
Do Things That Don’t Scale (This Is Not a Metaphor)
Paul Graham’s advice to “do things that don’t scale” is the most repeated and least followed principle in startups. Everyone quotes it. Almost nobody does it.
At Sell2Rent, before we automated the investor matching workflow in HubSpot, we did it manually. I built the CRM logic, the lifecycle stages, the email sequences, and the automation triggers. But before any of that existed, the team was matching investors to deals by hand. That manual process taught us more about what the automation needed to do than any amount of upfront planning would have.
The same principle applies to user research. The Mom Test framework says it plainly: don’t ask users “would you use this?” Ask “what did you do last time you had this problem?” Manual conversations, one by one, with real users.The temptation is always to scale before you understand. Send a survey to 500 people instead of talking to 15. Record a 45-minute Loom walkthrough instead of having a 10-minute conversation. The unscalable version is almost always the one that produces real learning.
Design Debt on Purpose
Speed pre-PMF requires shipping things you know aren’t perfect. The key distinction is between intentional and unintentional debt.
Intentional design debt means you ship a sub-optimal UI to validate whether the feature’s core value resonates. You know the visual design isn’t final. The interaction model is rough. But the core question, does this solve the problem, gets answered before you invest in polish.
Unintentional debt is what happens when communication breaks down. The dev team picks a component library without consulting design. Scope changes happen without documentation. The gap between what was designed and what was built grows until nobody can tell which decisions were intentional and which were accidents.
I’ve lived through both. Intentional debt at Sell2Rent, where we shipped CRO experiments knowing they’d be refined later, produced real learning. Unintentional debt at Keller Offers, where Devias Kit Pro got adopted without discussion, produced a permanent gap between Figma and product that contributed to the project’s failure.
The rule I follow: every piece of debt gets written down. What was shipped, what’s compromised, and what the fix looks like when the time comes. Debt without a ledger isn’t strategic. It’s negligence.
When You Know It’s Time for Real Structure
Pre-PMF structure is minimal by design. But there are signals that tell you the minimal phase is ending and real process needs to come in:
Retention curves flatten. You stop losing users after the first week. A core group sticks around and uses the product consistently. That means the value proposition is landing and now you need to optimize, not just discover.
Organic word of mouth appears. Users recommend the product without being asked or incentivized. At Sell2Rent, when investors started referring other investors to the platform without any referral program, that was the signal.
Users get angry about downtime. When people don’t care about your product, they don’t notice when it’s down. When they care, they notice immediately. Sensitivity to disruption is a proxy for product-market fit.
At that point, the design system matters. The documentation matters. The roadmap matters. But only because you’ve earned the right to plan by learning what’s actually worth building.
The Real Framework: Learn Fast, Document Light, Ship Constantly
After 8 years building products across six startups, from pure UI work at Mentive to running the full product stack at Sell2Rent, here’s what I know about pre-PMF:
The goal is not a beautiful product. The goal is learning what the product needs to be.
Short cycles, one goal at a time, measurement before code, manual processes before automation, and intentional debt with a ledger. That’s the minimal structure that maximizes learning.
Everything else, the roadmaps, the design systems, the comprehensive documentation, is a tool for the next phase. Adding it too early doesn’t make you rigorous. It makes you slow. And pre-PMF, slow is the most expensive thing you can be.
Want to see how I apply these principles in real projects? Check out my case studies or connect with me on LinkedIn.