How Do I Gather Requirements When Customer Doesn't Know What They Need?
A Quick Way to Go From Discovery to MVP
Hello 👋, It’s Vibhor. Welcome to the 🔥 paid member only🔥 edition of Winning Strategy: A newsletter focused on enhancing product, process, team, and career performance. Many subscribers expense this newsletter to their Learning & Development budget. Here’s an expense template to send to your manager.
Q: We are developing a SaaS B2B application. We started to develop it from scratch. Our customers who will use the application have difficulty in describing their needs. They say it should be a better application than the application they used before. Of course, this information is not enough for us. In order to understand customer needs correctly and offer them the right solutions, what kind of a process should I manage with the customer step by step, from the idea stage to the MVP determination? I know a little bit about topics such as Design Thinking or Google Design Sprint, but I need a more practical process that can be used in a corporate company and that I can use immediately,
This question resonates with me at multiple levels.
I mean, if there’s one question that is more important than:
How much is it going to cost? Or
When are we going to get it?
then it is this question that you have asked.
How do I gather requirements when customers don’t know what they need?
Most teams, in most cases, don’t know what they are building. And if they don’t know what they’re building, how can they possibly know how much it will cost or when it will be ready?
I've been there. We all have. You sit across from a customer who says something like:
"We need something innovative."
"We want to be different from our competitors."
"We need to modernize our processes."
And you're thinking, "Okay... but what does that actually mean?"
I've also learned (often the hard way) that when a customer says this, they're really saying, "I know there's a problem, but I'm not sure how to describe it."
That's actually good news! It means they've already done the hard part, identifying a problem worth solving.
Now, it's our job to help them discover the solution.
In this post, I'll share a practical, step-by-step approach that has helped me guide countless teams from that uncertain "I don't know" stage of a customer to a clear, actionable MVP.
I'll cover a technique that works in the real world, not just in theory.
More importantly!
This approach doesn't require months of gathering requirements or endless meetings. I have designed it to transform uncertainty into clarity in days, not months.
Let's get started.
Step #1 — Persona Identification
Under normal circumstances, the first thing we do when building a Product is discover requirements.
Teresa Torres wrote a book which provides some techniques for discovering requirements. It’s called Continuous Discovery Habits. Read it if you want to go in-depth into those techniques.
Most of the techniques that Teresa talks about start with some sort of an interaction with the customer. These initial interactions include:
customer interviews
surveys
feedback forms
etc.
In our case, where we know that the customer doesn’t know what they want, we will use a modified version of “customer interviews.”
The goal of this interview is simple: help the customer articulate who they’re building the product for and what those users are trying to achieve. To do this, we ask them to answer two key questions:
Q1: Who are the key Personas?
Personas are fictional representations of your target users. They answer the “who” question — who will use this product?
They represent the key groups of people who will or are already interacting with the product. Each of these Personas comes with unique needs, goals, and pain points.
Persona = [Role] + [Key Behavior] + [Pain Point] Here’s a simple template to help you guide the conversation in those interviews:
Q2: What is each Persona's Workflow (the journey steps)?
Next, we need to understand their workflow, the series of steps they take to achieve their goals with the product's help.
This is the “what” and “how” of their interaction with your product.
The answer to this question will help clarify what is “needed.” It will also ensure that you are not building a product in a vacuum but designing something that meets your users' real-world needs.