Building a product isn’t just about shipping software or coding features. It's about uncovering your product’s core truth (its reason to exist) and proving that it can solve a real, enduring problem. As a founder (especially if you’re primarily an engineer), your instinct might be to stack your MVP with advanced functionality. But the most scalable products start with restraint: validate your hypothesis, understand the actual pain, and scale what’s true.
Product
•
4 minutes reading
Oct 27, 2025
Jason Weiss, Mount Everest Panorama — Everest Region, Nepal, photograph taken from the summit of Kala Patthar (18,519 ft), Nepal, stitched from six long-exposure images. Building is like climbing a mountain: you start with a single focus, and compete the journey with precise, baby steps.
Step 1: Validate the hypothesis (don’t build a design system yet)
If you’re still at the idea stage, you do not need a design system. You don’t need sublime code or perfectly crafted components. At this stage, your only job is to validate whether your hypothesis is even true.
Example hypotheses:
"It seems people have problems tracking their sales across a funnel.”
"It seems people struggle to report sales to their manager because they’re disorganised.”
If you want to solve this problem through a product or technology, just prototype. Put that prototype in front of the people who feel this pain. Don’t worry about polish (unless this is for customer-facing products, in which that case, polish is highly appreciated. People finding products aesthetically pleasing, perceive these as performing better than any other competitors, Aesthetic–usability effect). Focus on proving whether the problem is real, whether it’s big enough to matter, and whether your approach shows signs of solving it.
At AstroBee I remember, our team started with a technically advanced AI system, but no clear interface or user story. I helped reframe the product from the perspective of a user in search of meaning, not a dashboard junkie. We validated the hypothesis that analysts wanted immediate insight, not just tools. That insight drove our MVP direction.
Step 2: Build a scrappy product (not a pretty one)
Once your idea is validated (once people are actually trying to solve the problem the way your prototype suggests) now it’s time to build a real product, even if it’s ugly.
Your product doesn’t need a final vision yet. It just needs to work. Write fast, dirty code. Skip the extra features. Focus relentlessly on the core problem you’ve validated.
Ask yourself:
Is the problem disorganisation?
Is it lack of structure in decision-making?
Missing manpower?
Lack of analytical skills?
That’s the actual problem you're solving, not just “sales tracking” or “reporting”.
For example, when I was working at Clarium, we didn’t try to become a full-fledged hospital ops platform on day one. We focused solely on the critical pain of supply disruptions (hence an huge organisational and collaboration problem at the core). That focus helped us build something hospitals needed immediately.
Step 3: Once It works, now you can systemise (design system + iteration)
Once your scrappy product solves the problem and is actually being used, this is when design systems matter.
A strong design system enables speed, consistency, and clarity. Build components that are:
Familiar and easy to use
Quick to prototype with
Modular enough to adapt as you learn more
With a design system in place, you can start to rapidly test new ideas. Use the same people who helped you find the core problem. Iterate on their feedback. Designers should now sit at the frontline of product evolution: speaking to users, shaping features, and balancing design with product ownership often, a product designer should be preferred as individual contributor rather than having a product owner/manager as well as they often are a huge bottleneck; often times, you need creative thinking not pure rational thinking during early stages are you're solving a problem either differently than others or newly like nobody else before and a creative mindset wins against a rational one, which could help on a longer run with a product owner).
In early-stage teams, the designer often acts as a hybrid product owner. That’s a feature, not a bug. Fewer handoffs, less bureaucracy, more agility.
Step 4: Don’t overthink onboarding or final UX (yet)
If the product is usable, don’t stress about onboarding flows. You can onboard users manually. Talk to them. Walk them through the product.
You’re still in the stage of proving consistent value. You’ll scale onboarding when the product is ready to scale (when users use it without you around). Until then: test, refine, evolve.
When I was working for AstroBee, we followed this path. We just wrote a documentation without building a product tour. We recorded anonymously people sessions to see how they were using early product and refined from there, paired with user interviews which I was also running personally. We guided a small user base manually, watching where they struggled and adapting in real-time. That loop fed directly into our design iterations.
Conclusion: Build from the core outward
If you’re building an MVP, start with the truth of your user’s pain (you remember the organisational problem? What about the manpower problem? What about analytical thinking problem? These are real problems). Prove that your idea helps. Ship something that works, not something that’s polished. Once it does work, codify that truth into systems: design, product, and growth. That’s how you build something that scales.
The fastest way to scale is to find what’s real, ignore what’s optional, and repeat what works. The MVP isn’t the first version of your product: it’s the first version of your truth. Design, engineering, and product strategy all follow from that center.
So find your center. And scale what’s true (!).
