How to Fix Your Roadmap and Stop Wasting Time on the Wrong Features

If you're building products for a while, you already know that often the hardest part isn't shipping features. It's knowing what's actually worth building. Most early-stage roadmaps are packed with assumptions. Some ideas feel exciting, but unfortunately, they won't grow the business. Others have potential, but only if you shape them the right way. And here's the truth: sorting this out is where most early-stage teams get stuck. After 15 years of helping early and growth-stage startups fix UX bottlenecks, I've seen the same pattern again and again. The moment you bring real user feedback into the process, endless internal debates stop. People move faster, decisions become clearer, and the roadmap finally starts to make sense. That's where interviews and quick usability tests come in. They help you cut the noise, kill bad ideas early, and shape the ones that are actually worth investing in. Let me show you how we do this with our customers step by step. First things first, You start with what you want to learn. Before talking to anyone, get clear on why you're talking to them. Are you trying to test a new flow? See what people actually do in your product? Discover real use cases or pain points? Or understand why customers pick you over competitors? All these are different questions, different interview styles, and sometimes even different people that you will talk to. If you tend to skip this step, usually that's when the interview starts to feel messy. Useless and like just wasting time. Once you've figured out what you want to learn, the next step is to prep a short list of topics. Keep it simple, you only need 3 to 5 talking points, and try to avoid writing a full word-to-word script. It just kills the conversation. What usually happens if you have a script is that you will be focused on the next question instead of being there, listening, and asking follow-up questions. Instead of preparing a full script, just be there, be present, and make sure you ask those follow-up questions like, tell me more about this, why you've done that. Walk me through that moment when you've done whatever. Usually that's how you will get the most out of the interview. And to give you some examples, these are some structures that we used with our own customers. The first one is really simple. It's from the Mom Test. And as you can see, it's like 5 questions. That you can use to start even just practicing running interviews. The first one, it's anchoring the discussion in the past. And that's really important because if you start asking people about future behaviors, they tend to make those up. This is why we start with, tell me a story about last time you've done XYZ. What was the hardest part? Why was it hard? How do you solve this problem now? How did you try to solve it? Why isn't this the best solution? This is just one frame. Then There are a couple of other ones, like when you talk to a customer that picked a different solution, or when you talk to a customer that picked your solution. In these cases, you want to understand how they ended up picking the solution. So you ask questions like, when they started to look for a, a tool like this, was there a specific trigger, time, why they started to look for it, what problem they wanted to solve, where they found the solution. When they found it, what solutions they ended up buying, how they picked that specific solution, and eventually what other solutions they were considering. All these questions help you understand how customers make buying decisions. Obviously, it's a good idea to interview past clients, clients that picked your solution but then moved on. In this case, you want to understand how and why that happened. And obviously there are more open discussions like discovery interviews where you want to understand if people have specific problems, if they are aware of those problems, and how important is that problem to be solved for them. You can find all these structures in the description. Once you have the structure for the interview, the next step is start to look out for people that you want to talk to and to invite them to the interview. You don't need to do anything fancy here. If you have customers already, the easiest step is to email them, send out a couple of emails and invite people to an interview. The other option is to add an in-product popup. We use Get Site Control for this and invite them to an interview that way. Either way, make sure that you include a scheduling link and you make scheduling effortless. You can use Calendly. There are other options as well. And to make things smooth, don't forget about reminders. Send an automated reminder 1 day before the interview and maybe 1 or 2 hours before as well. Now, if you don't have customers yet, there are a couple of other things that you could think of. Start with your own network and ask about people that fit the criteria that you have, that experience the problem that you want to understand. Just be aware that usually people that are close to you might not give you a full picture because they don't want to upset you. Either way, you can start with them and ask for referrals. The next step is you can search on LinkedIn or other social platforms, or you can join groups, forums, niched communities, wherever these people gather so you can talk to them. You can also try running some small ads and obviously asking for intros from people that you already know or talk to. You only need a handful of people to get some signals and make some decisions. Once the interviews are scheduled, the next step is to run the interviews. Before you start, make sure you have everything ready. That means if you are running usability tests, you have a prototype, the prototype is working well, everything is set up, and so on. For any kind of interview, make sure you have something around so you can take some notes. And if it's possible, bring a teammate along. Because this way one of you can focus on the interview, the other one can ask follow-up questions, take notes, and so on. Don't forget to be open-minded and curious. You are there to learn, not to convince somebody of your solution at this stage. Try not to mix discovery sessions or discovery interviews with sales calls. I saw this happen a couple of times with founders. Sometimes it's okay. But there is a very small line when things start to go south really, really fast. Because in a discovery session, you are there to learn. You want to understand how people make decisions, what problems they have, how you can help them, and so on. And nobody wants to open these up to learn that they will be just sold something. So try to not mix these two. If it's possible, always record the session. You'll notice things later that you completely missed in the interview or in the live sessions. This way you can revisit them, you can take more notes, you can extract even quotes, add more nuance and depth to the interviews as well. After the interviews are done, what you have to do is sit down and analyze and organize everything. Now, some founders tend to skip this step and just jot down whatever they still have in their mind. That might work up to a point, but it definitely comes with less depth, less nuance, and less insights in general. So make sure you have time to review your notes, review recordings, and look for patterns across calls. For all this, we use Dovetail for tagging and highlights, and also we use Airtable to log every piece of feedback and link it to specific parts of the product. This is in the end what shapes the roadmap, not just opinions and some of the parts of the feedback that you can remember. Now, I'm not a big fan of async testing, but when you're in a rush and you still need some kind of feedback, in some cases might work. What we tried so far is using Lisna to test prototypes, especially simple prototypes where the starting point and the endpoint can be easily defined. We uploaded the prototype in Lisna, we sent over the link to our customers, and we wanted to see if they get from point A to point B, how would they rate the experience and why. And another example was when we sent over a screenshot of the app and asked people where they would start certain specific tasks, and we collected the heatmap to actually shape the starting point for that flow. But if you can do live interviews, always choose that. first. They give you way more nuance, emotion, hesitation, frustration, the stuff that tools can't capture yet. So as you see, user interviews and usability tests, they don't have to be a very big research project that will take quite a lot of time and resources and money and so on. They are about making better decisions faster before you waste time building things nobody needs.