Skip to Content

2023.04.20

Operationalizing Product Research

Slowly building a corpus of market research data to find things people want to buy.

https://nikolas.ws/research-ops

This is a FutureIdea™ born from a need that the nascent Stucco Software has. I’ve been following the ideas of Coudal Partners so far - things that I want and need that maybe other people will also want and need. Today that want and need is a way to understand what people want to buy (Hoy’s theory of product development, perhaps opposite of Coudals).

This is a tool for conducting collection and analysis of digital ethnography in the domain of market research. While exploring digital sources, I want to quickly be able to:

  1. Capture texts and contexts from an audience, alongside it’s canonical URL using something like Scoop.
  2. Create summaries of the pain and value described therein. Attach those to canonical resources that collect many texts.
  3. Attach the resource to any concepts that might be relevant.
  4. Identify where a pain or a success might suggest an opportunity.
  5. Identify the pain and values in terms of their flavor; waste, lack, negative feeling, saving, earning, positive feeling etc etc.
  6. Associate potential methods and formats with the identified opportunity,
  7. Assign a need and impact score to the opportunity

Once that data set is assembled, we can use it to identify promising directions of product development.

A UI For Data Collection

Aggregation happens across devices – from work computer to personal computer to phone. Any time I come across something that that makes a little “ping” noise in my brain I want to grab it. This means a web tool with light as possible validation and authentication layers. Set it and forget style of auth/acc.

From the phone, it should be possible hook into the native iOS share cards to send a slack or discord snippet directly to a webhook endpoint – that would be minimally disruptive. Ideally there’s not a lot of copy/paste moments of grabbing the url than grabbing the text.

From the desktop, it can be a little more robust. Maybe just a little web app form that can collect and structure the data, or a little desktoppy app that just runs locally.

Both will talk to a web server and app for broader classification and structuring and analysis.

An Ontology for Digital Ethnography

This is basically a modified version of an IBIS.

A Resource is a single datum in our corpus. It has a source, a body. It originatesFrom an Audience, and describes any number of Pains and Successes. Its ID is its canonical URL. It can have the subject of, or simply mentions, a Concept.

An Audience has a name and description, and can hasCommunity, identified as a URL. It generates any number of Resources. It can be partOf another Audiences, as well as relatedTo a Concept.

A Pain and a Success are both a type of Issue. An Issue has a name, summary, and description. It demonstrates a more fundamental Quality. It can have the subject of a Concept. It suggests an Opportunity.

A Quality is a narrower classOf an Issue. It can be foundIn an Issue.

An Opportunity has a name, a summary, and a description. It is suggestedBy a Pain or a Success. It is relevantFor one for more Audiences. It can have the subject of a Concept. It is addressedBy a Method. It is embodiedBy a Format. It has a necessityScore and an impactScore, both of which are floats between 0 and 1.

A Method has a simple statement. It addresses an Opportunity.

A Format has a name and a summary. It embodies an Opportunity. It may have other properties to assist in determining its relevance or appropriateness.

Elsewhere

© 2026