Directional Inputs for Your Product
04 Mar 2025The way you guide the direction of your product changes after you reach product-market fit. Before, you were wandering through the backcountry searching for something. You weren’t quite sure what you were searching for, but you’d know it when you found it.
One day, you find it. And now you have a whole new challenge ahead.
You aren’t wandering anymore. You know where you are on the map, and you know where your destination is. But there are innumerable routes between here and there. Which route do you choose? How do you check your bearings along the way?
You take in directional inputs from every possible channel, and then you use your intuition to chart the right course. And then you move ahead to the next visible landmark on the route, check your inputs again, and adjust if you’ve gotten off course.
To learn to navigate in this way, we need to know the inputs we have access to. Before product-market fit, our inputs are more limited. After product-market fit, as we begin to scale, we suddenly have many more inputs and we need to use them all to stay on track.
So, what inputs do we have access to? How should we use these inputs to guide our product decisions? Let’s take a look.
External conversations
First up are external conversations. This input channel is conversations with prospects and current customers. You didn’t get to product-market fit without talking to people, and you won’t get to scale without talking to many more people. The challenge is learning to balance these one-to-one conversations with the many new inputs that you have as your product begins to scale.
In the early days, 10 people might have represented a significant portion of your user base. You could reasonably get a feel for the right direction through thoughtful one-to-one conversations.
As you begin to scale, 10 people will be a tiny fraction of your user base. Heavily weighting one-to-one conversations, especially from early customers that you feel some loyalty to, can drag your product in the wrong direction. An early adopter may feel very differently about a decision than folks farther behind on the adoption curve. Power users want different things than typical users.
Listen to users, have deep, in-depth conversations with them about their problems, but as you scale, recognize that these conversations shouldn’t always lead directly to a new feature on the roadmap.
Don’t invest months adding dark mode to your product because you talked to a customer at a conference who said they needed dark mode. Use conversations like that to guide your research and to add support to the investments you commit to on your roadmap. Shift from “we need this feature because I talked to X about it” to “X talked about this problem they have. What other versions of this problem can I find in our other channels?”
Internal conversations
Internal conversations means listening to your teams, not asking them to fill out spreadsheets or file ideas on an internal ideas board or putting a ticket in a backlog. Sit down with members of your sales team, your support team, your engineering team, your success team, and any other team that thinks about your product and how people use it.
Don’t come with an agenda of ideas that you want them to validate. Instead, open the floor to them: What is resonating in sales demos? What would your support team wave a magic wand and fix today? What do your CSMs have to workaround when they’re onboarding new customers? What parts of the product are they embarrassed by?
These conversations can be hard. If you haven’t had them before you might find that your teams, especially your support team, have a wall of negative feedback that can feel overwhelming. Don’t hide from this channel, embrace it. Your support team knows the warts of the product better than everyone. Listening to them and acting on their feedback will make your product better and will build trust with the team, helping everyone learn and improve faster as time goes on.
Two words of caution on this channel
- Once you commit to hearing feedback from your internal teams, you have to be ready to act on what you hear. Don’t overpromise, and don’t just do everything they ask for. But, prepare to grab a few items of low hanging fruit and knock them out quickly so the team knows that you’re listening to them and that they aren’t wasting their time by bringing you issues.
- Be mindful of who is delivering the message. Sales teams tend to tell you that every feature is critical to closing a deal — that’s probably not true. Support teams tend to over index on the issues that the loudest customers raise, but those aren’t always the most important issues to address. Listen, learn, and act quickly when you can, but remember this is just one input channel. Look for confirmation through other channels before considering large changes.
Finally, this channel requires you to be confident and clear in your answers to direct requests.
Don’t say not right now when you mean no. Don’t say yes when you mean maybe. Always set clear expectations about the outcome the team should expect. Make sure they understand that the answer to direct feature requests will often be “no” without qualifiers. Most ideas are good — but only great ones make it to the roadmap.
Market research
This is a channel that is changing rapidly with the introduction of agentic AI.
Competitor research used to be a fairly manual process — combing through release notes and website changes, finding demos on YouTube and signing up for free trials. Now, a lot of this work can be automated by AI agents and well-crafted Perplexity prompts. It is easier than ever to keep up with what your competitors are doing.
With that ease, it is even more important to understand what to do with competitor research. What you shouldn’t do is see that your competitors released a new feature and change your roadmap to add it to your product too. You also shouldn’t decide to add a new feature to your product and then copy a competitor’s implementation.
Copying your competitors means:
- You will always be behind them
- You will always have a product that feels like it is less than the sum of its parts.
- You won’t have a coherent strategy guiding product decisions, just a variety of attempts to copy/paste success.
Instead, invest in a design and development culture that pursues your own unique vision for what your product should be, who it serves, and why it exists. Then, use your competitor research to help shape roadmap planning by understanding where the market is moving, what alternatives exist, and how your product can fill gaps that others may not have addressed.
Sometimes you need to add a table stakes feature and you need some inspiration, or you need to understand more directly the limitations of a competitor that prospects are also considering. In those cases, sure, dive into their product deeply. Otherwise, competitor research is for information, not roadmapping.
Another approach to competitor research
One way to stay ahead of the game is to identify adjacent industries that you can take inspiration from.
When I worked in recruiting tech, we were building a CRM for hiring teams. Instead of seeing what our direct competitors were doing, we spent our time understanding what the cutting edge was in CRM functionality for sales teams.
We knew innovation in sales tech would eventually reach recruiting tech — sales teams have larger budgets and more of an appetite for change to gain a competitive advantage. Looking closely at what was gaining traction in the sales space helped us find ways to apply those ideas to recruiting years before our larger competitors would build them.
We spent our energy looking years into the future of our space by thinking creatively about market research instead of obsessing over each new feature release from our close competitors.
Feedback data
Feedback data is aggregated data about what your customers are saying about your product, from sources like:
- NPS and CSAT surveys
- Support cases in your ticketing system
- Search trends on your help portal
- Ideas, upvotes, and comments on a public ideas portal or community
- Comments on social media and review sites
The key to this channel is that we are shifting from individual conversations into aggregated data to help identify trends. Aggregating the data from these channels is important to avoid over indexing based on very loud, grumpy customers.
Instead of treating every complaint as an emergency, look for the most time consuming or impactful issues by aggregating support case data and tying reports back to activity in the product. Are there certain issues that are more likely to lead to churn? Do trialing customers that get stuck at a certain point in onboarding and email support? Look for trends, don’t start unnecessary fires.
This channel is also helpful for finding and fixing low hanging fruit. Sometimes your support team will decide on their own that an annoying bug is too hard for your engineers to fix, so instead of telling people about it, they’ll just share a workaround 10 times a day.
Often, you’ll find those issues are quickly resolved once they’re known. Make it your business to find those issues and build internal communication channels to get them fixed before they become a drag on your product.
Engagement data
Engagement data moves away from softer, qualitative feedback into quantitative data. Forget what people are saying about your product. How are they actually using it?
Engagement data plays two important roles in helping you shape your product’s direction.
First, engagement data allows you to validate what you are hearing through conversations and feedback inputs with how people are actually using your product. Is everyone telling you that they love a new feature? That’s great! How many of them have used it more than once? Is everyone actually just a very vocal 2% of your user base?
Engagement data is best consumed through charts and graphs — most people struggle to see anything useful in spreadsheet rows — and early on you should invest in tooling to extract usage data out into a purpose-built solution that allows you to record ephemeral events (like clicking a button or applying a filter) along with longer term changes (like creating or deleting a record).
Build some dashboards, spend time regularly thinking about the data you have and how you can learn from it. Then, build the habit with your team that everything they ship needs to be measurable so that they know if their work is having the impact they expected.
Whenever possible, look for engagement data that helps validate what you are hearing through conversations, rather than trusting that what people are telling you matches up with reality.
A word of caution on this channel
It is easy to weaponize engagement data to prove anything you are determined to prove.
Weaponization goes something like this: I don’t like a new feature that shipped and want to show the team it needs to change.
First, I create a chart that shows trial starts are down since the feature shipped. I conveniently leave out the fact that trial starts began trending down 2 weeks before that feature shipped. Now I can prove that the feature is bad and needs to be scrapped. But I’m not moving the product forward, I’m just winning an argument.
Often the weaponization is more subtle, and less intentional, but it can be just as harmful. That scenario goes like this:
I ship improvements to a feature that I am really excited about. I know these changes are going to make this feature the best on the market. I check usage data and see that usage has doubled since we released the changes — success! Because usage has doubled, it is time to invest even more resources into this feature to keep up the momentum.
What I don’t share is that doubling usage means going from 0.5% of active users to 1% of active users. We’ve moved the needle, but we aren’t likely to get the results we need by continuing to improve a feature that no one uses. Should we invest more in this feature based on the evidence we have in front of us?
The stories we tell ourselves about engagement data can be dangerous, and immature founders and product people regularly use engagement data to shape a narrative instead of improving the product.
Approach this channel with humility and with your learning hat on. What does the data say, objectively, about the questions we have? Using data to prove yourself right, or to prove someone else wrong is easy. Getting real insights is hard. Do the hard work.
Tying it all together
Learning to balance all of these inputs takes time, experience, and plenty of false starts. I have seen plenty of founders struggle with the shift from exploring the wilderness to navigating to a destination. You won’t get every decision right, and you’ll get overexcited by a piece of feedback or a new channel. It happens.
The most successful folks I have seen make this transition have approached each new channel as an opportunity to learn something new. Instead of being the smartest person in the room, they aim for learning faster than everyone else.
Doing this work positions you and your team to transition the day-to-day work of product from you as a founder to employees that you trust. You still own the vision for the product, but if your team is tuned into these channels, they can begin to think like you, and to advocate for the same direction that you would. This frees you up to step up a level, and build repeatable processes for your company, instead of spending your time trying to pull the product in the right direction.
Next time you make a product decision, pause and ask yourself: which input channels are guiding this choice? And are you listening to all of them?