The cheapest market research a founder of a services business can run is a list of about ten pains, each written as a sentence a buyer would say about themselves, taken into ten conversations with people who already have the problem, and scored twice: once for how often each pain happens and once for what it costs when it does. It takes a fortnight and costs nothing but the conversations. It will not tell you the size of a market; a consultancy, agency or managed service provider needs one buyer before it needs a market. What it tells you is which sentence makes somebody wince, and that is the only research a two-person firm can act on. Everything else on this page is how to write the list, run the conversations, score the answers and prioritise (prioritize) the result.
Why a questionnaire, not a market report
Market sizing is for product companies raising money. A report describes an industry; your buyer describes a Tuesday that went wrong. If you are about to sell skilled people’s time, the question is whether a specific kind of person has a specific problem often enough, and expensively enough, to pay someone to make it stop.
In February 2013, weeks before we incorporated the business that became DevOpsGroup, a services company helping other businesses build and run software, my co-founder Steve sent me a questionnaire. Its first question asked what the main operational challenges were in managing a website, and underneath sat eleven possible answers, from availability and performance, through deployments that broke production, to disaster recovery and compliance. Eleven guesses about what hurt, and then Other. Writing them down changed the task: we could stop explaining what we thought companies ought to buy and ask what they were actually dealing with. Every line had passed a test we did not know we were setting. Each was a complaint one of us had heard somebody make out loud.
Writing the ten questions
Keep the pain list to about ten items. Five is too few to find the one that makes somebody wince; thirty turns a conversation into an examination. Each line should be a sentence the buyer would say about themselves, never a feature you would like to sell them. “Our releases break production” is a pain. “You need continuous delivery” is a pitch wearing a pain’s clothes.
Always leave an Other. The small opening lets people recognise their own experience rather than squeeze it into your vocabulary, and the answers that land there are the ones you did not know to ask about.
Wrap the pain list in a few context questions: ours asked who built the website, who ran it, how large the business was and how much revenue depended on being online. The same difficulty is a nuisance in one company and a serious problem in another, and you need to know which you are talking to.
Then prepare the follow-ups for whichever pain lands. These are the five I would carry into every conversation.
| What to ask | What it establishes |
|---|---|
| Tell me about the last time this happened. | A concrete event rather than general agreement that the problem exists. |
| How often does it happen, and what changes when it does? | Frequency, disruption and consequences. |
| What have you tried so far? | Existing workarounds, effort and spending. |
| Who is responsible for improving it? | The people involved in deciding on and carrying out a change. |
| What would convince you that it had improved? | A result the customer could recognise and evaluate. |
How to run ten conversations
Choose people who already have the problem and have spent something trying to make it stop. They are not the people you would send a positioning argument to, who are chosen for their disagreement; these are chosen because they live with the pain. Former colleagues, the customers of a vendor you know well, the people asking the same question in every user group: ten is enough.
Ask about what happened, not what they think of your idea. For a release that went wrong: what were they trying to change, who became involved, how long did recovery take, what work stopped meanwhile. A real example shows whether your service fits, or that the difficulty sits somewhere else, which is cheaper to learn now than after you have named the company for it.
After each conversation, write a short account: the problem in the person’s words, the recent example, the consequence, what they had already tried and the result they wanted. Across ten conversations, that gives you something more useful than a count of encouraging replies.
Then, after every third conversation, rewrite the first line of your proposition and keep the old version. The drift between the versions is the clearest record you will have of what you learned.
Scoring every pain twice
Score each pain in each conversation twice, once for how often it happens and once for what it costs when it does, on a scale of one to five. Frequency on its own is noise. Cost on its own is an anecdote. Together they let you put one line above another. Here is an invented example of the totals after ten conversations; the numbers are made up to show the method.
| Pain (invented) | Frequency total | Cost total | Combined |
|---|---|---|---|
| Releases break production | 38 | 41 | 79 |
| We cannot scale for peak demand | 19 | 44 | 63 |
| Monitoring gives us poor metrics | 42 | 17 | 59 |
| Out-of-hours cover is too expensive | 27 | 22 | 49 |
Read the shape, not just the total. High frequency with low cost is an irritation people have learned to live with; you will struggle to be paid to remove it. Low frequency with high cost may still justify serious investment. Previous spending cuts both ways: it may show the problem matters, or that the buyer is tired of paying for disappointing answers, and the conversation needs enough detail to tell those apart. Underneath the arithmetic, you are watching for the line that made somebody wince.
What to do with the ranking
The top pain becomes the first line of your proposition, in the buyer’s words rather than yours. The second and third become the services you propose once the first has earned trust. The bottom of the list you stop talking about, however much you enjoy the work.
Then the harder question, the one that turns research into a service someone can buy: how would the customer know you had made it better? In the spring of 2013 a business development lead at a managed hosting provider asked us exactly that: what would we measure, and what assurance would the client receive? We set out the operational measures the industry used at the time, availability, time between failures, time to recover and performance, proposed a fifth we cared about more, the time an idea took to travel from development into a live service, and said plainly that the fifth was hard to measure. Research is finished when you can say what better looks like in a measure the buyer would recognise, and can say honestly which parts are hard.
I cannot draw a verified line from that questionnaire to a signed customer. Its value was the change in the discussion, from recognising problems towards explaining a service someone could judge.
One more use for the ranked list. Two days after we incorporated, I sent Steve a proposal to build a software platform of our own; his questions about dependencies and competitors were sensible, and the idea stayed an idea while customer work acquired momentum. Ideas close to the work keep arriving. The ranked list is what you test them against: who would use the first version, what job would it do, and what would you stop doing to make the time.
The customer discovery questions playbook, in development, carries the full questionnaire, the scoring rules and the rewrite cadence. The questionnaire scorer, also in development, runs the ten-item list across your own conversations and produces the ranked table.