For many, many things in life, success rarely follows a single path. Different but equally viable methods are applicable to reach the same goal. Like in sports. Tons of tactical angles you can bring to the pitch. Once looked closely, though, it seems that these differing methods actually converge on a fundamental level. What’s explicit in one could be a subtle complement in another, but, on an idea level, they display the same raw, purpose-driven take on the matter. Acting super fast or patiently waiting for the right time to strike. Different in a mechanical sense, yet borne out of the identical driven-ness to do something big.

In developing software products, one may take a well-defined approach or invent something of its own to ship something. Either way, the purpose stays untouched as it has always: turning an idea into a product or a feature. Some prefer being cautious, seeking confidence at any step of the process before taking a step further. Some take a leap of faith and skip some steps, while others seem indispensable. Nevertheless, both, with enough level of drive, could actually work to turn ideas into reality.

Product development is a continuous idea-realisation activity at its core, and making bets on ideas or opportunities that would prove useful commercially. And in choosing ideas, without a doubt, everyone wishes to pursue an idea that promises returns. Regardless of the tools, tactics, or processes, almost everyone strives to work on a winning idea. However, when it comes to how to make bets on ideas, preferences vary greatly.

Idea and problem validation methods have come a long way, from simply not existing to being strongly advocated at every level of product development. From the outset, the logic seems absolute; validating your assumptions or gut feelings at the earliest point is a sensible thing to do since no one wants to squander valuable design and development resources on hunches that have no market. On the flip side, nevertheless, the realities of everyday business might contradict what’s deemed as absolute logic and question the worthiness of these validation techniques. Sometimes, spending resources on half-baked ideas could turn out to be a winning formula or shipping something not good could leave a lemony taste in users’ mouths, so their confidence towards some particular technology or idea turns sour at the expense of slowing down your competitors. There might be many reasons for anyone to skip the validation practices and jump straight to building stuff without sensing the air. Yet, even though you might have your reasons, is it reasonable to do so? Do you not need to confer with your would-be users or gather inputs to make educated guesses?

How far ahead do you like to see to be convinced? This is the question in question that should steer your perspective on validation. In a way, it’s already been decided how meticulous your product team will be when conducting validation research because the question above is more about how you and your organisation think risk-wise. It’s been already decided, therefore, for one simple reason: Your risk appetite and validation love is not about product development at all. It’s about how the founding team make bets in their life. It’s about how optimistic they generally are in their endeavours.

Following a text-book validation process sits on the one end of the spectrum. You can go after trying to validate the problems that gave birth to your idea. You can conduct surveys, focus groups, or nethnography studies to investigate whether or not the problems you’re dealing with exist or are promising enough. You can choose to dive into exploring your idea only after you’re convinced of a validated problem. You then again can go methodical, applying idea validation methods like fake doors, concierge MVPs, or guerilla user interviews to get a sense of the market in general. Maybe you do not just rely on users’ accounts or the feedback you collect, you assign certain KPIs or indicators to your field studies to move forward unless a certain threshold is met. This makes you extremely methodic, planned, detail-oriented, risk-aversive, and all. Sitting on the edge of the spectrum. However, does it make you bulletproof? Or would you be doomed when you completely ignore validating your assumptions? Of course not. Tons of products are out there just because their creators were madly believing them. So, how do you find your balance?

Imagine we reach a point where every known chair maker is so good at what they’re doing that they all can build the best products when asked. No sensible difference in their craft or for your buttocks, no matter who you go, you get the best chair. Or even a better analogy: burgers. Just think that each burger joint is cooking the best burger in town. All the time. What would you seek after you’ve had enough of these yummy burgers? What would burger joints do to stand out in the competition? You and they would probably invent. Invent new tastes, new expectations, new angles. And to do so, you would rely on your intuition. What would make a burger good? Looking similar but different in some aspects and more appealing than its counterparts. You’d try to come up with something new. A key component in your idea generation process, and therefore in product development, would be intuition you’d apply to all aspects of your business: your burger, your users, your joint, and your market.

You can very well skip ahead and pay no attention to any validation practices. You can be loose, you can let your teams to be loose about building ideas. But, even if this methodlessnes gets you to luckily reap some remarkable results, it probably will not take a long time before you realize you just were lucky, and the whole thing was a flip toss. What would happen more realistically is that you fail when you went binary, idea to launch. One way or another, somewhere along the way, you find out that the ideas you deemed breakthroughs are just epiphanies you had. But this would not necessarily be a bad revelation. To make your approach work, to justify being loose and binary, you could embrace failures as they are the most impactful way to gestate intuition. Only by failing do you start to see the nuances that separate bad from good. So, instead of following boring text-book validation practices with half-baked ideas and working on just enough prototypes, you could indeed go all the way down and win the market if you possess both the resilience to weather repeated failures and the analytical mindset to extract meaningful patterns from each setback. This approach demands not just stomach but self-awareness and emotional regulation.

Choosing a spot between being loose and going methodical could define your trajectory, and how you build your products. Depending on your vertical, stage, and market, you may feel the obligation to do certain things in a certain way. You maybe cannot afford to be loose if you’ve got investors and more stakeholders than you can count. Or, similarly, you maybe can not spend time following a checklist if you’re working on a B2C product as a startup. All these parameters would have contributing weights on your decisions. Therefore, what you should do is to decide on how to develop intuition. By trial and error or by going big and failing enough. And this decision will actually have already been made quite early on in your story. You just need to articulate who you are as an individual and as an organisation as a first task. When you clearly see how you like to think and how others think, you’ll see which approach would suit you and your organisation better. If you’re free to be yourself in your case, with no pressure from external factors, you can then go and craft a specific approach that suits you entirely. But, almost always, starting from your teammates to board members, there will be people sceptical about the things you do or not. So, choose wisely and think about how your way of thinking would resonate with those around you.

This theoretical discussion becomes practical when facing actual product decisions. Consider how different teams might approach the same problem: Team A conducts extensive user interviews, creates prototypes for testing, and graduates features through staged rollouts. Team B develops a bold vision, ships quickly to a subset of users, and iterates aggressively based on real-world feedback. Both can succeed or fail spectacularly; the determining factor isn’t which approach they chose but whether that approach harmonized with their organizational DNA.

Lastly, and this time not subtly, I would suggest that you do not let methods rule your development practices. Do not simply follow something invented some time ago. It was always the case, but the game is changing more swiftly now than ever. New tools, new engagement channels; the shield around everything that’s validated before is down, you can go twisting methods or berzerk and invent something completely new. No matter where your finger lingers on the spectrum, the only thing that can be argued for certainty is to think how it would suit you. Do not YOLO it; do not be random, and let your randomness tell who you are. First, make a deliberate choice and make it known. Then, go by the books or binary. This way, you won’t be arbitrary. This way, you’ll build ideas as yourself, no matter whether you win or lose.