User research is just talking to customers

The short answerYou do not need a research team. You need five customer conversations per week with three questions: what are you trying to accomplish, what is getting in the way, what would you do without us? Ask what they are trying to do, what blocks it, and what they would do without you.

User research at early stage is five conversations a week, not a department. You do not need a research team. You need five customer conversations per week with three questions: what are you trying to accomplish, what is getting in the way, what would you do without us? Ask what they are trying to do, what blocks it, and what they would do without you.

Scope your MVP to one workflow, not one market

The biggest MVP mistake is trying to serve an entire market instead of a single workflow. A workflow is a specific sequence of tasks that a specific person does to accomplish a specific goal. Serve one workflow for one persona exceptionally well and you have a product. Serve five workflows adequately and you have a demo.

The test for your MVP scope: can you describe the before and after in one sentence? Before: the customer manually exports data from three tools into a spreadsheet. After: the customer clicks one button and the report is ready. If your before-and-after takes a paragraph, your scope is too broad. Narrow it until the sentence is crisp.

Technical debt is a business decision, not an engineering one

Technical debt gets framed as an engineering problem. It is not. It is a business decision about trade-offs between speed and quality. Sometimes shipping fast with debt is the right call. Sometimes it is not. The decision should be made consciously, with the business context, not by default.

The framework: track technical debt like financial debt. Know how much you have, what the interest payments are (slower development, more bugs, harder hiring), and when you plan to pay it down. Allocate twenty percent of engineering time to debt reduction. Not zero, because it compounds. Not fifty, because you still need to ship. Twenty percent is the sustainable rate.

Build versus buy depends on your differentiation

The build-versus-buy decision should be based on one question: is this capability a differentiator for your business? If it is, build it. If it is not, buy it. Your CRM, your payroll system, your analytics platform are not differentiators. Your core product is.

The mistake is building everything because you can. Engineering time is your scarcest resource. Every hour spent building something you could buy is an hour not spent on your differentiator. The counter-argument is that off-the-shelf tools do not fit your workflow. Sometimes that is true. Usually it is an excuse. Adapt your workflow to the tool unless the workflow is genuinely unique.

Prioritize features by impact, not by request volume

The features your customers ask for most loudly are not always the features that will have the most impact. Loud customers are often edge cases. The features that matter are the ones that open up new use cases, reduce churn, or expand your addressable market.

The prioritization framework: score each feature on three dimensions. Reach: how many customers does this affect? Impact: how much does it improve their workflow? Effort: how long does it take to build? Divide reach times impact by effort. Build the highest scores first. Re-score quarterly as your customer base and market change.

User research at early stage is just talking to customers

You do not need a research team or a formal process. You need to talk to five customers per week and ask them three questions: what are you trying to accomplish, what is getting in the way, and what would you do if our product did not exist? The answers tell you what to build next.

The format that works: thirty-minute video calls with a loose script. Record them with permission. Review the recordings monthly to identify patterns. After twenty conversations, you will have a clear picture of what your customers need. After fifty, you will know more about your market than any analyst report could tell you.


Frequently asked questions

How do I do user research without a research team?

Five customer conversations a week with three questions: what are you trying to accomplish, what is getting in the way, what would you do without us? That is the whole apparatus at early stage.

What makes a good user research question?

Open, specific, and about behavior, not opinion. What did you do last time outperforms would you use this by an order of magnitude. People are unreliable narrators of their future and excellent witnesses to their past.

How do I find customers to talk to?

Your own users first: recent signups, active users, and the ones who churned. The churned ones teach the most per minute. Ten conversations across those three groups will rewrite your assumptions.

What do I do with research findings?

Write each conversation into three bullet points the same day, and read the pile monthly. Patterns across fifteen conversations are your roadmap inputs. Notes not revisited are conversations wasted.

What is the biggest user research mistake?

Asking for validation of your idea. Do you like it produces politeness, not data. Ask about their work and their problems, and let your idea be tested by whether their answers keep matching it.

Working through this right now?

This is the work we do with founders one-on-one. One email is enough. A partner reads every message.

Start a conversation