Mastering the Unknown: Building Great Products in New Spaces
How to validate your product before you over-invest in development.
Building a product in a new or unfamiliar space is one of the toughest challenges in product management. Even with great research and a solid strategy, you're often trying to solve a problem with little to no precedent, and hoping the market will respond positively.
You may ask yourself:
Is the solution intuitive enough?
Does it really solve the problem—or just shift it?
Is this pain point worth solving in the first place?
Are my limitations going to sink the user experience?
Is the market willing to pay for a solution here?
The best way to approach a situation like this is to make small, quick experiments to test whether your solution will work before committing significant resources to it. It’s important to understand that a working solution isn’t just one that can solve the problem, it’s one that is actively being used to solve it.
Here’s a simple approach for doing just that.
Clearly Define the Problem Space
This is the most important and, often, most rushed step.
A common mistake in product teams is jumping into solutioning before fully understanding the problem. But when you truly understand the root cause, constraints, context, and user behavior, you can design something that fits into your users’ world more easily and with more confidence.
“If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions.” — Albert Einstein
You should not gloss over this step. Often what you think is the problem is actually just a symptom and you need to go deeper to understand the root cause. In order to do that, you’ll need to analyze user behaviour by looking at available data (e.g. performance metrics if you’re trying to improve a space or market trends if you’re going somewhere new) and user interviews.
At Vasco, for example, our onboarding experience is slower than we’d like it to be with our channel mapping step contributing significantly to that delay. In this step, we ask our users to define all the channels that they use at their organization and then map those channels to properties in the CRM. In Vasco, channels can be part of one of 3 categories: Inbound, Outbound, Partnerships.
However, it is only upon analysis that we discovered that:
No companies used more than 2 channels per channel category.
Even though it was an open text box, the channels created by our users were invariably the same.
The hurdle wasn’t in the mapping, but in the fact that the properties in the CRM didn’t exist.
This insight helped us zero in on the root cause of the problem: organizations that were slow to map their channels hadn’t previously recorded the acquisition channels used to attract prospects in their CRM. As a result, when it came time to map those channels in Vasco, they first had to do that foundational work. However, when they did complete the task, they rarely went beyond identifying the channel category, making support for a more granular level largely unnecessary. Identifying the root cause and understanding user behavior helped establish clear boundaries around the problem space.
Pro Tip: While researching your users, try to identify a few who are willing to be early testers. Their feedback will be gold later on.
Define What Success Looks Like
Before you begin designing a solution, define success based on the problem. Instead of designing a concept and then estimating its potential, focus on defining a success metric that indicates that the pain point you identified earlier has been addressed. Your concept should be designed specifically to meet this goal so it needs to reflect what you hope to accomplish. In other words, hitting this target means that you have successfully solved the pain point.
Success might mean:
Reducing time spent on a task (e.g. onboarding flow completion time)
Increasing usage or engagement (e.g. DAUs/WAUs)
Improving outcomes (e.g. data accuracy or conversion rates)
Cutting costs (e.g. infrastructure, support tickets)
The goal here isn’t to prove your product works perfectly—it’s to find out whether it’s worth investing in. So set a success metric and a clear threshold that indicates: pursue, pivot, or pause.
For Vasco’s channel mapping feature, we defined success as enabling a customer to set up their channels with 95% data integrity in under 10 minutes. If we made meaningful progress toward that goal (even if we didn’t fully hit the mark) it signaled that the concept was promising but needed further refinement. On the other hand, if we fell significantly short, it was a strong indication that the idea might not be viable and should potentially be abandoned.
Pro Tip: For early-stage products, usage that matches the frequency of the pain point is a fantastic integral indicator for both value and usability.
Design a Laser-Focused Product
This is where discipline matters most.
It’s tempting to build out a full feature set, but your first iteration should be purposefully scoped. As a rule of thumb, only include elements that directly solve the core problem. Exclude everything else.
This first iteration can have many names (e.g. MVP, alpha, beta, proof of concept), but for the purposes of this article, I wanted to avoid labels that can carry unintended assumptions and just focus on the intent. What matters most right now isn’t building a complete product that can solve every edge case; it is to assess whether your concept has the merit to serve as the foundation for a complete product.
One of the reasons to reduce the number of features is that it offers you time to invest more in polishing the experience. Even though you’re not looking to win everyone over at this stage, you want to minimize the number of variables that will impact your ability to assess the merit of the concept. In short, if you don’t see the success that you were hoping for, you want to make sure that it is because of the merit of the idea and not because of its appearance, usability, discoverability, etc.
While designing the channel mapping feature, we included features like automation because we couldn’t get the experience to below the target time with only manual tactics. At the same time, we intentionally left out support for custom channels. While that’s likely a bridge we will need to cross in the future, our current focus is on evaluating whether this new experience can serve as a solid foundation for a more complete solution down the line.
Pro Tip: Don’t aim for perfection. Aim for clarity of purpose.
Step 4: Build, Release, and Measure
The final step is to build and release your solution. Ideally, you can leverage the test users you identified earlier, but if you can’t, then limiting the release to a random sample is fine. The goal is to put your product in the hands of people experiencing the pain point that you identified so that you can gather actionable feedback.
This is where your success metric becomes essential. You need to measure how your solution performs against your target outcome—and then decide whether to pursue, pivot, or pause.
For example, if you're addressing a high-frequency, high-pain problem, you should expect coincident usage. If usage is low or the metric falls short, ask yourself: does the solution need refinement, or is the concept itself fundamentally flawed?
At the time of this writing, Vasco’s channel mapping automation hasn’t yet launched. When it does, it will become the default experience during a required onboarding step, ensuring strong visibility. The existing, more flexible setup will be moved to an “Advanced” option. This configuration allows us to not only measure our time to get to 95% data integrity, we can also measure how often the new flow didn’t meet the needs and had to be circumvented. For us, success isn’t just that the design could enable users to complete setup in under 10 minutes—it’s that they actually do.
Pro Tip: If you’re close with your test users, they may hesitate to give candid feedback. Usage data tells a clearer, more honest story.
Conclusion: Validate Fast, Learn Faster
Building in a new space is difficult because without precedent, you don’t know what will be successful. Your primary goal in the early stages is to uncover a concept with the strongest potential for success.
Start by gaining a clear understanding of the problem. Go beyond surface-level symptoms to uncover the root cause of the issue and the behaviours and context around it. This clarity will guide every decision that follows.
Once the problem is well defined, identify what success looks like. Set specific, measurable targets that will help you assess whether your solution is delivering meaningful impact.
From there, design a focused solution. Scope in only the features that directly address the core problem, and leave out anything that doesn’t. This discipline allows you to build more quickly and test more effectively.
When your solution is in the hands of users, measure how it performs against your success criteria. Use those results to decide whether to pursue, pivot, or pause.
At the onset, you're not trying to build a perfect product. You're trying to find a foundation that is worth perfecting.