Three Ways to Build Better Solutions Without Asking Users What They Want

Creating the right things starts with finding & solving the right customer's problem

Sharing rough sketches with end users to learn. Image via Midjourney

“People don’t know what they want until we show it to them.”
– Steve Jobs

Through my work coaching product people and teams, and being part of online writing communities, I’ve started to see how similar they are in one key area.

Building fans

At their core, both collaborative software development and online content creation are about understanding user needs.

This allows us to create or write something so compelling that it will create and keep loyal users and readers coming back for more.

But unfortunately, too many creators do this the wrong way.

They either never talk to their readers and go off and build or write things no one’s interested in.

Or they go to the other extreme and make the biggest mistake I see both product people and new online authors make.

They flat out ask their readers what they want, some variation of:

Please tell me what you’d like me to build for you next

Please tell me what you’d like me to write about for you

While it might seem to make sense to ask users what they want, there’s a few key reasons why you’re wasting both your time and theirs.

I’ll give you three actionable tips to understand what users really want from you, and how to create without guessing.

The goal

Before we get into the action steps, we need to step back and be clear what we’re trying to achieve by creating in the first place:

In online digital writing, the gold standard for viral content is to:

• Write something that makes people look smart for liking, commenting on it, and resharing it with their network

When we’re building software, successful products happen when we create something:

• People love

• Use it to solve their unmet needs, hopes, and desires

• Return to it regularly

• Pay for it gladly

• Happily tell their family and friends about our product

There are only a handful of products we use every day that pass this high bar.

The way we create products customers love is through understanding their needs and building trust, rapport, and relationships with them over time.

Why this is so rare

But Product Managers new to Continuous Discovery either send out surveys or fall into the bad habit of asking users what feature they should build next.

I’ve seen many new writers across several of my writing communities make the mistake of begging readers to tell them what they should write for them.

There are five problems with this:

1. When we look to others to tell us what to do, we appear weak and unsure.

2. Worse, we’re giving them homework to do for us. It’s our job to figure out what to create, not theirs.

3. They don’t even really know what they want or what it will be like when they have it.

4. They have no idea what’s possible, so the solutions they ask for will be limited by what they already know. At best, their suggestions will be low-level and incomplete.

5. People are unreliable by nature. As the work of the late Daniel Kahneman uncovered, people don’t act or speak in rational ways. We’re not trying to intentionally mislead. It’s important to accept that at a fundamental level, we’re just not wired for truth and transparency.

With all these factors going against us, it’s clear why it’s a bad idea to ask users what they want.

Fortunately, there are ways we can understand user needs and come up with better solutions.

Stepping up

The key comes from getting clear on:

• Who we’re solving problems for

• What problems we’re going to help them solve

It comes down to one simple question. In whatever we’re building, creating, or writing, ask:

“For whom am I creating this, so they can then do what”?

This forces us to focus on creating value through our unique experiences and knowledge.

Managing software products

Product Management leads by bringing higher-level organizational strategy to life through product-level choices made in collaboration with the Product Trio.

Their unique value comes in understanding what technology solutions are just now becoming possible to address user needs in unique, innovative ways.

Users can, and will ask for things, but it’s up to us and our team to uncover what problem they’re really trying to solve, and how to best solve that problem.

Three better ways to create

1. Talk to people

Regularly speaking to our product’s users, or our readers, may be the single best use of our time.

Sometimes we build things because we fall in love with a piece of tech, or write something because we’re curious about ideas we want to explore more deeply. Our users or readers can seem like a distraction from what we’re trying to do.

In these cases, it’s helpful to turn things around and look at them this way:

• In product, we build products so we can share our excitement about them and talk to people about them.

• For creators, we write and post online to gain trust and permission to connect with people who like and engage with our work.

• In both cases, this helps us understand their experience, why they like us, and what may be holding them back from loving us so we can learn how to better solve their needs through our work.

Interviewing for understanding

The breakthrough of continuous interviewing is to shift from talking about our work to focus instead on our users’ experience.

In this approach, we ask our users to tell us a story of the last time they tried to solve a specific problem.

For example, we’ve identified a possible problem for our users in recruiting clients for one-on-one coaching opportunities.

Our goal here is to shut up and listen, and capture notes as the user tells their story. Don’t blabber on and interrupt them.

When they run out of steam, we can ask follow-up questions like:

“How satisfied are you with your ability to recruit clients?”

“What else have you tried/purchased/read to help with this?”

From solution to the underlying problem

Our goal is to listen for and uncover problems to solve and unmet needs to fulfill through understanding what success looks like for them.

If they jump in and start giving you solutions (“Maybe we could have a Virtual Assistant (“VA”) cold call people for us.”), we can redirect them to the next set of questions:

“What would having someone cold-call on your behalf free you up to do?”

“And why would that be important to you?”

“How important would this be for you in this situation?"

We keep asking questions, in a gentle but focused way, like the “5 Whys” technique, to uncover deeper underlying truths.

2. Rapidly test assumptions

Now that we have an idea of what deeper underlying problem they need help with, we can come up with a range of ideas to test that could solve that problem.

At this stage, we don’t want to jump in and take months to build out the first idea that comes up. Our goal here will be to take a page from lean startup and rapidly test our assumptions by creating the smallest thing we can to learn and build on that.

Using the example of online writing, we can start by writing:

1. A short LinkedIn post or Tweet – Just a short, powerful fragment of an idea. For example, here’s a relevant one from Justin Welsh: “Don't chase money. Chase problems. Solve them and the money will likely appear.”

2. Listicle – We turn that into a short series of bullets, something like “3 Ways to Reverse-Engineer Customer Problems to Create a Profitable Business.”

3. Tweet Thread – We take that listicle, and blow each of those bullets out to an individual Tweet, with an intro and takeaways Tweet.

4. A longer LinkedIn post or carousel – We can then create the next level of content by rearranging, expanding, moving around, synthesizing and editing our ideas

5. Medium long-form post – Finally, we’re ready to create a longer-form (5-10 minute read) article

At each step, we’re testing our ideas and how we build our logic, and loop that back in as we gain traction and generate conversation with our readers.

The old waterfall

Traditional software development relied on following a specific set of “phases” each handled by an “expert,” before handing off to the next “expert.”

We first “gathered requirements,” spent months “synthesizing,” then “designed” a solution, each “expert” handing off their findings to the next, mostly based on intuition and guesswork.

Trust me, I managed this process for years, and the documents we built got ugly and unreadable fast. My biggest-ever “Product Requirements Document” (“PRD”) weighed in at over 520 pages! The development team was expected to take this, read the entire thing, and then build out an entire solution which would then get tested and pushed out to customers. That process could take anywhere from 6 months to two years to go from idea to working software.

After two years, you can only imagine how out of date our assumptions could be.

Discovering continuously

In the new approach to product development, our goal is to prove ourselves wrong. Continuously.

We think we have an idea of what might work, but we rapdily test our assumptions at every stage with end users. At every step, we’re creating something our users can get value from. The key here is to build the minimum amount possible until we’ve proven our idea has value and is ready to take to the next level.

And our work is never done. Keeping this process going continuously means we keep pace with our users, the marketplace, and our competition:

1. We start with some rough mockup sketches on paper we can share internally and with users

2. Once some general directions become clear, we design and put together “Clickable Prototypes” so our users can have a better sense of the how different experiences might work.

3. Google Ads & Landing Page – If we’re unsure whether users will find value in our solution, we run some limited Google Ads sharing the idea, leading people to a simple email capture signup page. If a certain mumber of people sign up, we know it’s safe to move forward.

3. Get feedback and keep improving

As long as we’re regularly talking with and engaging with your users/readers, we’ll be getting a regular stream of feedback.

Some good. Some bad.

Remember that feedback is a gift if we take it the right way.

The key for us is taking the relevant feedback and bringing it into our work.

Survival of the fittest

One important point to realize is that most ideas we think are amazing around a conference room table simply won’t appeal to our end users.

Instead of resisting or forging ahead in some “sunk cost fallacy,” it’s important to accept this. Our goal will be to understand how we need to adapt our solution and shift it, or abandon it completely.

The best ideas will ultimately win out, but we can’t always rely on our users to let us know.

People are unreliable

When we’re speaking with them, our users may be filled with ideas and opinions.

As Daniel Kahneman's work explains above, people aren’t intentionally lying to us, but we need to look more at what they do than what they say they do. Behaviors are the most reliable signals to pay attention to.

We can understand better their underlying thoughts and motivations through looking at two kinds of data:

1. Qualitative – live user conversations, feedback & engagement

2. Quantitative – survey results, site analytics, views, likes

Many tend to focus on one or the other, but both are essential to get a clearer picture.

By keeping an eye on these, we can feed our latest learnings back into the writing or product.

Our goal will be to follow this continuous process over the life of our product and our writing.

As Marty Cagan mentions, even many of our best ideas will need multiple versions and a significant amount of the right users’ feedback before they’re even close to achieving their desired outcomes for our users and our business.

TL;dr & Takeaways

“This job would be great if it wasn’t for the %$&#’ing customers.”
― Clerks, 1994

First and foremost, don’t look at your end users and readers as distractions but as people you get to engage with as a result of the creation you do.

But don’t ask them what feature they want or your readers what to write for them.

• Connect and engage directly with the right users/readers

• Get them to tell stories about their needs

• Work backwards from those unmet needs

• Test your ideas creating the smallest chunk of value possible

• Get feedback and iterate

Consistently putting these underlying principles into action can make the difference in creating products and content that resonate.