Why you should build features users don't ask for

“If I had asked people what they wanted, they would have said faster horses.” Now, it’s highly likely that Henry Ford never spoke those exact words, but the point still rings true. Often, people aren’t aware of what they need, or even what they want. It’s basic psychology that applies in all aspects of our life. People think they’ll be happy if they win the lottery (even though studies prove that isn’t true).

So, if just asking users doesn’t work, how do we actually uncover our users’ unmet needs? It’s not just about “eating your own dog food” or “drinking your own champagne.” It’s also about building empathy and weaving user research into the fabric of your company culture. At Pitch, we're always challenging ourselves to address the root cause of the problem, not just manage the symptoms.

You’ll never know what users want just by asking

If you ask most people what they want, you’ll get front-of-mind problems — whatever is most obvious in that moment to them. But often, it’s really the workarounds that have become ingrained in people’s habits that illuminate opportunities for innovation, and they’re the ones that people can’t even remember. As an example, while observing how people created presentations, we saw that they needed a way to communicate to their other teammates whether the slide was incomplete or ready.

One user was manually marking slides with their status. It was something so straightforward, but when we looked further, we saw many people taking a similar approach. This even ended up inspiring one of our users' favorite features today: slide statuses. This just goes to show that the things people spend the most time battling with are not features we ever get requests for. It turns out many things we take for granted — like the ability to align objects easily — are surprisingly complicated in traditional presentation software, even though they're a staple in other tools we use today.

Silent shadowing

Observing how people actually navigate and use their software will teach you much more about their needs than just asking them how they work. We got some volunteers to record themselves making presentations, and watching hours and hours of people struggling with PowerPoint really hammers home the point.

We try to understand existing user behaviors and expectations early on in feature development to make sure it's represented in the final result. By the time we get to prototypes, whether or not we want to admit it, our ego has come into play. It’s actually a good thing — it shows we’re proud of what we made. But it’s a bit like the IKEA effect, you’ll like something more if you made it with your own hands. And unfortunately, that effect can be blinding. In fact, it’s one of the most dangerous things when it comes to building a product. No one likes to kill their darlings.

Prioritizing early user research has not only helped us build features like slide statuses, it’s also shown us entirely new ways Pitch can bring value to our users, like our quick menu. Most people were not asking or expecting to be able to have a command palette in their presentation tool, but we saw an opportunity to bring that into Pitch based on the other types of software people rely on.

Friday presentations: How we use Pitch at Pitch

At Pitch, we often have discussions about how we think users will behave or expect a feature to work. However, we’re not always creating presentations in our day-to-day job. There are a few ways we test new features internally to put us in the user's mindset. One of my favorites is our Friday presentations.

This exercise in "eating our own dog food” has a simple premise: Choose any topic, make a presentation about it using Pitch, and note any feedback, suggestions, or bugs at the end. Doing this helps get you out of what you think people need, and see what you actually need when you’re really making a presentation.

They’re totally voluntary, but typically, new employees do one shortly after joining. This is not only a valuable way to get product feedback from people who bring fresh eyes and a newcomer’s point of view but it’s also helpful in onboarding new employees. The informal structure of the presentation helps us get to know them better and breaks the ice with the team.

We like Friday presentations because they're fun, light, and interesting. We've gotten to learn about everything from pineapples and Kimchi to volcanoes in Europe and how people perceive graphs. But beyond just learning new things, Friday presentations are a way for us to gather ideas for features our users may need. Some teammates have even hacked together new features as part of their presentations. For a presentation about Japanese noise music, our UX prototyper Jelle created an early version of what would later become Pitch's video embeds.

We may be getting feedback on the process of creating a presentation, but we could be missing out on other valuable user experiences, like what it’s like to get started with Pitch. To combat this, we use Pitch not only as our internal presentation tool, but also as a way to store and share knowledge like our employee handbook, org chart, and our weekly updates. Diversifying the ways we use Pitch helps us avoid blind spots we would otherwise miss.

Of course, there are always exceptions and gaps. One of the biggest is the ways different people in the company use Pitch. For example, as a designer, I don't use charts or tables very often in my everyday work. Because I'm not exposed to this feature on a regular basis, I may not be as familiar with a user's pain points.

Plus, most of the time, we only create presentations when we have a specific goal in mind. Maybe it’s a pitch deck to raise a Series A, or maybe it’s an end-of-quarter presentation for the department. Regardless, few of us create presentations just for the fun of it. By making Friday presentations light, we give people the opportunity to explore the product and to play with features they may not use otherwise.

We tend to vastly underestimate the differences between us and other people, which is why it’s just as important to try to know your user as it is to know how you're not like your user. This is why it's so important to use a combination of methods to really get the most comprehensive view of users' needs.

Even someone with the same background as you might have a completely different usage pattern. For example, a designer in a small startup has extremely different needs than a designer in an insurance company. Beyond the role or type of company, the surrounding context and user’s mindset in that moment have quite a big impact on their needs. Are they making a conference talk or a weekly SEO report? Do they just want to complete the presentation efficiently and move on to their next task, or to really invest in the design for an important conference talk by the CEO?

Conclusion

We all know understanding the people you are building your product for is extremely important. Especially when your product is in an early stage, slight changes in direction can add up to monumental costs if features are developed that users don’t need or want.

Identifying users’ unmet needs is more than just necessary, it’s a growing opportunity for us as professionals. Often it helps us re-remember things we've heard before, inspires new ideas or ways of thinking about things, and shines a light on the blind spots that may be getting in our way. Not only that, but it improves our intuition and helps us think differently, ensuring that we can build a product experience that builds on existing behaviors where relevant and creating new ones where we can innovate.