What to build next is a perpetual challenge for early stage products. There's a universe of possible features to build, bugs to fix, tests to run - how do you know what to prioritize?
In my experience, there's 2 factors that go into prioritization decisions early on:
What are customers asking for? Hopefully you're talking with your customers on a regular basis - what are they wishing existed? There's a couple things to keep in mind here:
Balancing and prioritizing the various feedback you get from customers is tricky.
If your feedback has some common theme across most of your users, that's a great sign - it means you've found a cohesive market segment, with similar pains that your product could solve. Double down on those pain points (assuming the align with your strategic direction).
But what about when the feedback you get varies wildly? It seems like every user you talk to wants something different, and there's very little overlap. This is usually a sign that your product is too "horizontal" - that is, it serves many different possible use cases. For early stage products this is usually a bad idea. Horizontal products are difficult to make into truly amazing product experiences, because you can't serve all use cases equally well.
When you find yourself in this "horizontal product" trap, it's often best to niche down further. Pick one promising subset of your audience and build for them. Keep narrowing down until you start to see consistency in the feedback - that's when you know you've found a cohesive segment you can build for.
That doesn't mean you have to restrict yourself long term to that niche either - this approach makes for a great "land and expand" strategy, where you focus and dominate one niche first, then expand to adjacent niches gradually.
There's a valuable lesson to be learned from the House M.D. show:
PatientsUsers lie
Joe User says he loves your product, and can't wait to use it as soon as you add feature X. You dive in, spend days or weeks on engineering time building it, excitedly email him that his wish has been fulfilled, and ... crickets.
Or worse: he replies with "Looks great - now I just need feature Y to get rolling!".
What happened?
Users lie.
It's often not intentional. Sometimes people lie to be polite, or to avoid embarrassment, or simply when they don't have a good answer to your question. No one enjoys being the fool.
But those lies distract you.
Then send you down rabbit holes, chasing phantom features that won't actually make a difference.
Pressure indicating UI is a tactic to help cut through that noise, and get to what users really want. It's based on the concept of stated versus revealed preferences.
We often do things that contradict our stated preferences. We say we want to lose weight, but we don't exercise or eat better. Our revealed preference is to keep the weight, eat what we want, and not exercise.
Pressure indicating UI is designed to avoid the trap of chasing stated preferences, and instead get at the true, revealed preferences of your users.
There's two kinds of pressure indicating UI to know about: pressure gauges and escape valves.
A pressure gauge UI is a piece of user interface that tells you, the product owner, what people are interested in. It's the weaker form of pressure indicating UI, in that it doesn't help the user achieve what they want right now. But it's easier for you to ship quickly.
Let's take an example: you are thinking about adding an "invite a co-worker" feature to your app that would send the co-worker an invite with a link that sets them up in the app.
You're not sure if this will be valuable - you've had some requests for something like this from existing users, but you aren't confident people would actually use it. Maybe it's really useful, or maybe when it comes to it, users don't actually mind copying invite links manually.
A pressure gauge for this might be a simple "Invite a Coworker" button you add to the UI that records who clicks on it. When it's clicked, you pop up a message saying the feature is coming soon, and offer the user the option of getting notified when it ships.
This lets you get a real, unvarnished sense of who wants to use this feature. And it even builds a list of eager early adopters - great candidates for beta testing or evangelizing the feature when it ships.
The danger, of course, is abusing this pattern to mislead users. Be careful that your pressure gauges don't deceive users into assuming certain critical functionality exists, just to have them realize it doesn't right when they need it. In other words, don't test your "restore from backup" feature this way.
Escape valves are features that give those users desperate for some functionality a "way out". It lets them get what they need out of the product, at the cost of a bit more legwork on their part and with very little investment from you.
My favorite example of this is the humble "notes" field. Just a simple, plain text input that lets users add their own notes to records in your app.
It's great.
And it's great precisely because it's not good UI.
A notes field is a fallback. A catch-all.
It's an admission that your app doesn't let the user track everything they need to, so it's giving them an escape valve to add a little bit of their own functionality to things.
This gives you two main benefits: first, it lets you support users who love your product except for that one missing feature - that one missing field or value they want to track. They can track that on their own now!
But more importantly: it lets you see the pain. How people use the notes field will show you what's missing. And as you start to see patterns ("Ah, looks like lots of people are adding the last phone call time to the contact note's field"), it gives you a roadmap of what to bake into the product as a first-class feature.
Building great products is a balancing act. There's a equal measure of meeting people where they are today, juxtaposed with building for the better future your users aren't even imagining yet. As the apocraphyl Henry Ford quote goes:
If I had asked people what they wanted, they would have said a faster horse - (not) Henry Ford
This first factor of prioritization is customer demand: what your customers want today. The second factor is strategic direction: the better future you are building towards.