Research What Is It

How the Research What Is It Process Actually Works

Most people treat research as something that happens at the end of a project, when they already know what answer they are looking for. That is backwards. The Research What Is It approach flips the timeline. You start by mapping the question space before you touch any data, sources, or tools. I learned this the hard way on a procurement project last year. Our team was tasked with evaluating five different database management platforms for a client. We spent three weeks comparing features side by side, reading documentation, running demo instances. At the end of it, we could not answer the actual question: what problem were they solving? The client had never clearly stated their constraints around data volume, latency requirements, or existing integration points. We had built an elaborate comparison matrix for something we did not fully understand. That wasted about forty person-hours and nearly derailed the engagement.

What Research What Is It Really Means

At its core, this method is about distinguishing between the surface question and the underlying problem before committing resources to finding an answer. It sounds simple, but in practice most teams skip directly to information gathering because there is pressure to show progress. Reading papers, running experiments, and collecting survey responses feel like work. Defining the question feels like waiting. The first step is always to write down your working hypothesis in one sentence. Not a paragraph. One sentence. If you cannot do that, you are not ready to start researching yet. My rule has always been: if the sentence requires a semicolon, rewrite it until it does not. This forces you to identify the actual scope. After the hypothesis, you map the unknowns. I use a three-column table for this. Column one lists everything I think I know about the domain. Column two lists the gaps. Column three lists the assumptions I am willing to make provisionally. This takes about ten minutes and usually reveals that half my confidence was built on unexamined assumptions. In the database platform example, I had assumed the client needed sub-second query response times when they had never actually said that. They needed audit trail compliance instead. Completely different technical direction.

The Execution Phase

Once the question space is mapped, you move into targeted gathering. This is where most guides tell you to read broadly and take notes. That advice is wrong for this method. You read narrowly. You pick the highest-confidence sources available for each gap in column two and you extract only what answers that specific gap. Broad reading introduces noise and bias because you absorb context you did not ask for. I keep a decision log alongside my research notes. Every time I find information that changes my working hypothesis, I record it with a timestamp and the source. This creates a trail you can revisit later. When I was building that same procurement evaluation, I kept going back to my decision log and realized our original constraint assumption had been contradicted by three separate pieces of vendor documentation we had skimmed over. The log caught it before we presented anything.

Pitfalls and Where This Fails

This method does not work when the problem itself is genuinely ambiguous with no actionable constraints possible. In exploratory scientific research where you are opening a new field, you sometimes need broad scanning to discover what questions are worth asking. Research What Is It will slow you down in those cases because the rigid hypothesis-first structure conflicts with genuine discovery mode. It also fails when you are working under extreme time pressure. If someone tells you they need an answer by end of day and you spend two hours mapping unknowns first, you will not earn trust. In those situations, I fall back to a lighter version: state the hypothesis aloud to someone else and get immediate pushback. That takes five minutes and catches the obvious wrong turns without the full framework. The biggest practical downside is that it feels unproductive during the mapping phase. Stakeholders watching will see you sitting there writing tables instead of actively researching. You need to communicate what you are doing upfront or people will assume you are stuck. I literally send a short message saying I am scoping before I start and what I will deliver in return. It prevents the "why hasn't he started yet" messages from coming in.

A Technical Edge Case

There is one scenario I run into occasionally that breaks the standard approach. You are researching a topic where the authoritative sources are themselves uncertain or contradictory because the domain is newly emerged. I hit this with a federated identity integration project where every vendor documentation page made different claims about SAML versus OIDC support depending on the release version. The gap analysis table filled with contradictions instead of clarity. The workaround was to add a fourth column to the uncertainty table: source reliability tier. I rated each piece of information as primary (direct from the specification or vendor engineering), secondary (implementation guide or tutorial), or tertiary (forum post or blog). When contradictions appeared, I only resolved them using primary sources. If no primary source existed, I flagged the gap explicitly rather than picking a side. This prevented me from presenting false precision on a decision that should have stayed open.

Summary of the Practical Workflow

The process takes roughly three stages. First, write the one-sentence hypothesis and build the three-column unknowns table. Second, gather narrowly against each gap using only the highest-confidence sources you can find. Third, maintain the decision log and flag unresolved contradictions rather than forcing a conclusion. If you are working under time pressure, compress stage one into a verbal hypothesis check with a colleague. If the domain is new and sources are unreliable, add the reliability tier and leave gaps unmarked instead of guessing. Most of the value comes from stage one. Getting that right means stages two and three are about fifteen to twenty minutes of work per gap instead of sprawling into days of unfocused reading. The total time savings on a typical business research task is somewhere between two and six hours depending on complexity. Not dramatic on a single small task, but it compounds across a quarter of engagements.