Research Plan and Question Bank

Turns a fuzzy business question into a research plan: the decision it actually serves, the sub-questions that would settle it, the right method for each, where the answer lives, and what you would have to see to change your mind.

A Markdown research plan containing: (1) the decision the research serves, with any assumption flagged; (2) the question restated in answerable form; (3) five to eight sub-questions, each with a method, a specific source, a rough duration and a good-enough answer; (4) the recommended order with reasoning that front-loads invalidating questions; (5) a falsification criterion; (6) a 'What not to research' section of two or three items.

# Research plan — should we expand into Germany?

## The decision this serves
The notes do not state the decision explicitly, so I am assuming it is: **do we commit engineering and go-to-market resource to Germany in the next planning cycle, or not?** Flagging that, because 'should we expand into Germany' with no decision attached generates a report and no action. If the real decision is smaller — whether to translate the site, whether to hire one salesperson — the plan below is more than you need.

## The question, restated so it can be answered
> Is there evidence that German buyers in our segment have the same problem, can buy our product as it exists today, and can be reached by us — sufficient to justify one quarter of focused effort over the next-best use of that quarter?

The comparison is the important part. 'Is Germany a good market' is unanswerable. 'Is Germany better than the alternative use of this quarter' is a decision.

## Sub-questions

**1. Why did the inbound German customer buy, and would others like them?**
Method: one interview, 30 minutes. Source: that customer. Time: this week. Good enough: you can state their trigger, what they compared you against, and whether anything about them is Germany-specific rather than just a company that happened to be German.

**2. Can a German customer legally and practically use the product today?**
Method: internal review with whoever owns compliance. Source: your own product, contracts and data-processing setup. Time: two days. Good enough: a yes, or a specific list of gaps — data residency, GDPR processing terms in German, invoicing requirements, VAT handling.

**3. What does it cost to make the product sellable there?**
Method: engineering estimate against the gap list from question 2. Source: your one free engineer. Time: half a day, after question 2. Good enough: a range in engineer-weeks, not a plan.

**4. Is the buying process meaningfully different?**
Method: three to five conversations. Source: founders who have sold into the DACH region from the UK — findable through your investors. Time: two weeks, mostly waiting for calendars. Good enough: you can name the two or three ways it differs from the UK, particularly around procurement, contract language and the expectation of local presence.

**5. Can you reach the buyer without local headcount?**
Method: a small live test, not desk research. Source: 50 outbound emails in German to a matched segment, or a small paid test. Time: three weeks including replies. Good enough: a reply rate you can compare against your UK baseline. This is the cheapest real signal available to you.

**6. What does the alternative quarter look like?**
Method: internal. Source: your own roadmap and pipeline. Time: one afternoon. Good enough: a written statement of what Germany displaces. Without this, question 1 through 5 cannot produce a decision.

**7. Is there a cheaper version of the same bet?**
Method: internal. Time: one afternoon. Good enough: a described minimum version — for example, German-language landing page and contract terms only, no localisation, no hire — with its cost.

## Do them in this order
1. **Question 2 (can they legally use it) first.** It is two days and it can kill the whole thing. Anything that can invalidate the rest goes first, always.
2. **Question 1 (the existing customer)**, because it is one call and it either strengthens or weakens every subsequent question.
3. **Question 6 (the alternative)**, before you have sunk enough effort to be committed. Doing this late is how research becomes a justification exercise.
4. **Question 5 (the outbound test)** next, because it takes three weeks of elapsed time and should be running in the background while you do the rest.
5. Questions 3, 4 and 7 in whatever order fits.

This fits your six weeks with room to spare, which it should — if a market-entry study consumes the whole window before the planning cycle, the study has become the project.

## What would tell you the answer is no
State this before you start, in writing: **if the outbound test in question 5 returns a reply rate materially below your UK baseline, and the compliance gap in question 2 is more than two engineer-weeks, the answer is no for this cycle.** Committing to that in advance is what stops a board's enthusiasm from becoming the finding.

## What not to research
- **German market size.** You will find a number, it will be large, and it will not change your decision. Every market is big enough for a seed-stage company's next quarter.
- **A competitive landscape scan of German vendors.** Interesting, slow, and it does not bear on whether you can sell there this quarter. Do it after you decide to go, not to decide.
- **Whether to translate the product UI.** Premature. Question 5 will tell you whether anyone replies, and until then UI translation is a solution to a problem you have not confirmed you have.

_I cannot answer any of these questions for you: no web access, no data, no sources. This is the plan, not the research._