From a young age, I have had to find ways to process my frustration when information is presented in a fragmented or confusing manner. In order to avoid overwhelm or even a mental shutdown, I started building tools and processes that help me hold onto coherence, meaning, and safety.

The outline below shows my sensemaking process — how I’ve learned to understand what’s happening externally that enables me to experiment with narratives that better meet my needs, especially after they’ve so often been misunderstood by others. I’m still finding structures for this, but sharing it feels like one way to open the door to conversation.

Datagotchi Sensemaking Methodology

This framework outlines the four-step process of turning personal anxiety and fragmented information into a clarified, actionable understanding of the world.

1. The Triggering Event: The initial moment of dissonance or chaos because your reality and external reality do not align.
2. Externalization: The act of turning internal, chaotic thoughts and feelings into a concrete, external document or system so as to not forget and reference again in the future.
3. Causal Analysis: The process of connecting the dots and revealing the underlying system at play. It’s where you find the causes of the original triggering event.
4. Collective Action: The application of your newfound understanding through sensemaking for a greater purpose. Your personal insight becomes a building block for the collective.

Does this process resonate with how you make sense of things? What does your own version of sense-making look like?

This framework was born from a personal struggle to make sense of a fragmented world. You can read the full story of my journey and the philosophy behind my social impact research lab (Datagotchi Labs) here: https://datagotchi.net/2025/08/28/from-personal-struggle-to-collective-rebellion-the-why-behind-datagotchi-labs/.

Problem Space

To hire, test out product features, and grow, startups need money before they start making profits—they need investment. Investors want to have confidence that a startup they invest in will be able to grow enough so that they get a return on their investment. As a result, a concept was established called product-market fit, which is when a startup’s product is useful to one or more customer market segments and competes effectively with other products in that space.

However, most startups are not able to achieve product-market fit. There are several reasons for this, but a key aspect of it is that their product does not does not serve the needs of any potential customers. In other words, their product does not solve an actual problem. A term to describe this problem is not having problem-solution fit. This is a bit misleading for products that offer novel interactions rather than solving a problem, but it could be said that not being able to interact with people as much, or as effectively, is the problem such products are solving.

Therefore, startups must reach problem-solution fit. Then, after identifying some potential users that the product solves a problem of theirs, a startup should find a subset of them or their managers that are willing to pay for it (customers). This is the first step toward achieving product-market fit. In other words, to achieve product-market fit, a startup must first identify customers that are willing to pay for their product.

Finally, after achieving product-market fit, a startup must grow so that they can acquire enough dominance in the market space to attract acquiring companies or file an initial offering to become a publicly-traded company (i.e., an initial public offering, or “to IPO”).

Technical Requirements

To reach problem-solution fit, or to make sure you build something that people actually want or need, many startups think of something that they would want or need, or use their gut instinct. However, such approaches, while a good start, are prone to error. At the very least, startups should test their solution’s core value proposition–the benefit that it provides to users and customers. This can be done with signup forms on landing pages or created content. Then, possibly using the potential users and customers from these tests, some iterative user or customer research is necessary to continuously confirm that they have a problem that your product solves, and that a large enough number of them have this problem for similar reasons.

To reach product-market fit, or to make sure your product is useful to one or more customer market segments and competes effectively with other products in that space, a startup must start by determining who are users and who are customers. They may be the same people, the customers may be managers of users of your product, or the customers may be organizations running ads to the users. Then a startup needs to understand users’ and customers’ needs to understand what product space they’re in and how to compete in it. Again, while subjective

views and gut instincts are a start, something more formal is needed to identify go-to-market opportunities and verify they would serve a large number of people or organizations. The tests ran to reach problem-solution fit are also helpful because they may contain information about users’ and customers’ needs, or because they may provide a list of people for user or customer research.

Finally, to grow, or to acquire enough dominance in the market space, a startup must optimize their successes delivering their product to users and customers and their success using it. Therefore, it is necessary for a startup to identify one or more channels to reach users or customers and deliver their product to them. Once the channels are identified, marketing funnels should be created for each of them, with potential users or customers and leads at the beginning, and prospects in the middle, and successful users or customers at the end. To increase the success between these funnel stages, a startup must iterate on their product and user or customer research to confirm their needs and success using it.

My Solution

The concepts of user experience (UX), human-computer interaction (HCI), and usability testing all have foundations from when a group of researchers in 1982 came up with the concept of cognitive systems engineering (CSE) in response to the Three Mile Island nuclear disaster of 1979. It was then formalized by a couple of those researchers in 1983 with the lens of people and machines working together as a joint cognitive system (JCS). With this lens, CSE became an approach to systems engineering to continuously verify one’s understanding of users and machines, their joint success or failures in operation, and how those failures can be addressed. A similar cyclical approach called human-systems integration (HSI) was also invented in the military to model each systems engineering iteration’s decisions as risk management. I have worked with both the researchers that invented these approaches, and their followers, in my past government R&D research scientist jobs.

While usability, HCI, UX, design thinking, and so on, are used in the world of tech startups, other concepts of CSE like JCS and the HSI iterative cycle of systems engineering have not made their way there yet. Therefore, I will use my knowledge of these methodologies and related processes and tools to help startups with user and customer research, and improving their products with that knowledge–iteratively throughout their product lifecycles.

Problem-Solution Fit

To help startups perform user research to achieve problem-solution fit, I will study users’ and customers’ problems and their environments that are relevant to the envisioned product. Including their environments is necessary because their problems do not exist in a vacuum: they exist because of other factors or constraints in their job or life, and cannot be addressed without addressing those factors, too. Since people’s activities in their lives may or may not fit a consistent schema, I will start by creating empathy maps on potential users and customers. These will involve what they say, think, do, and feel, and possibly what they see and hear.

Then, as I learn more about them, I will add structure to the empathy maps. While a common formalization of empathy maps is personas, which are fictional people that have the attributes documented in empathy maps, I will take inspiration from cognitive work analysis (CWA) when it is possible. CWA maps a worker’s tasks and activities to the goals that they help achieve and the worker’s overall objectives that they are trying to fulfill. CWAs are a powerful CSE tool because they capture a worker’s job in its current state, which help identify inefficiencies that can be addressed with a product, and they can be extended with features of a product to test its success. They can also be combined with personal details to create personas.

Also, although CWA is taken from work-centered CSE research, it can be applied to consumers–i.e., people using a startup’s product outside the context of work. In these cases, overall goals may be social connections, self-worth, or similar ideas, and goals and activities may involve going out with friends or posting on social media, for example.

To enumerate empathy map metrics, potential users can be interviewed and they can be observed doing their job using their existing tools. Together, these methods will identify their job’s overall objectives, the goals to achieve these objectives, and the activities used to achieve these goals. Job observation will then identify the specific tasks taken during these activities and the tools and constraints that affects their execution of tasks. Finally, surveys or focus groups can then be used to discover if these metrics are common among a larger set of potential users.

Once these metrics are discovered, they can be measured, and then bottlenecks or other problems can be identified. These are the opportunities for a new product. To evaluate the empathy map metrics, specific measures must be identified and job observation is needed to record the values of the measures. Similar to empathy map metric enumeration, surveys or focus groups can then be used to discover if these bottlenecks or other problems are common among a larger set of potential users or customers.

Finally, solution improvements can be made to improve these metrics, and the cycle repeats.

Product-Market Fit

To help startups perform user and customer research to achieve product-market fit, I will study previously-identified user’s workflows and customers’ needs. Empathy maps and CWAs may identify some tasks that are part of a user’s activities, but it is not focused on the structure of these activities and tasks. Therefore, I will start by creating user journeys, which are diagrams of the tasks or steps a user goes through while using the product.

Then, as I learn more about them, I will add more details to the user journeys by taking inspiration from cognitive task analysis (CTA). CTAs map tasks and activities to their cognitive states (e.g., goals that the user is trying to achieve with them). Although CTAs are taken from work-centered, CSE research, they can be applied to consumers–i.e., people using a startup’s product outside the context of work–in that, like CWAs above, the goals that the activities and tasks help achieve may be social or personal goals.

For highly structured jobs, and easily-observable tool usage, job observation can be used by itself. For more unstructured jobs, or for tasks that are more difficult to observe, methods like card sorting can be used, where a potential user sorts labeled cards about information, tools, or tasks they can perform to determine the order they prefer to achieve a goal identified in the CWA.

Then, go-to-market strategies and metrics to evaluate them should be identified. In the case of users being the customers, or users being the product to the customers (e.g., attention and data for advertisers), marketing funnels for the identified delivery channels can be extended, or supplemented, with product usage funnels from journeys that are modified with features of a startup’s product. Then, these funnels can be evaluated with analytics events embedded in the product, and user journeys can be evaluated with those analytics.

The customers’ needs also need to be understood, regardless of whether or not they are the same as the user. As a start, customers can be interviewed and documented with empathy maps. Then, workers’ objectives that were identified in the empathy maps can be mapped to their managers’ goals. Also, similar to user journeys, customer journeys can also be evaluated with job observation, interviews, card sorting, or analytics, along four stages (AIDA):

• Their Attention to or Awareness of a product category or the product itself is increased: Advertisements, created content, etc., can be tracked in terms of the number of views they get and the percentage of interactions they get (e.g., click-through, CTR, of ads).
• Their Interest in the product is increased: Starting with the percentage of interactions, other activities related to ads or content can be measured and combined to score how much a lead is interested in the product.
• Their Desire of the product is expressed: Similar to interest, desire can be measured by more direct activity like downloading a product (if applicable), signing up to get notified when it launches, and so on.
• They take one or more Actions: For example, shopping around the product category, trying out the product, or buying the product. Having a certain number of large/popular companies as customers is often used to measure pm-fit, but startups can go further. Measuring product-market fit, both to optimize internally at the startup or for future investors can be done by doing cohort analysis on the metrics mentioned above — i.e., what percentage of people from a previous stage go to the next stage, all the way to buying the product. On the way to reaching product-market fit, a startup should make product improvements to improve these customer and user metrics.

Growth

To help startups grow, I will assist with the use of analytics to help iterate on product features to optimize key metrics–a process often called growth hacking. Analytics will be used for two purposes: to identify differences in users’ or customers’ patterns with a product versus the modified, envisioned journeys mentioned above, and bottlenecks in funnels with the end stages resulting in money for the startup. A common approach to grouping these metrics is “the pirate metrics”: acquisition, activation, retention, referral, and revenue (AARRR, like pirates say).

Existing analytics solutions can be used (e.g., Mixpanel, Heap, Segment), or a custom analytics solution can be created. Then, funnel events need to be inserted into the product to fire off when users take certain actions. Finally, the funnels should be visualized with aggregated data across users.

If the users’ or customers’ patterns do not match the envisioned journeys, then interviews can be done to identify reasons for the differences. Similarly, interviews can be done to identify reasons for bottlenecks in funnels that *do* match the journeys, but do not complete them. Then surveys and focus groups can be used to determine if these reasons are common.

Finally, changes to the product can be made to improve the analytics, and the cycle repeats.

Technology Innovation

Many frame the primary problem with artificial intelligence (AI) systems as users not trusting them, or as the AI systems not being trustworthy. However, automated technologies have always been a problem because they are not resilient in the face of unforeseen circumstances. In other words, AI systems are not trustworthy because they are unhelpful for data they are not trained on.

One solution to make these AI systems more resilient is to show where their outputs came from, and, if it is unable to provide a high-quality answer, why it was not trained on relevant data. However, many modern AI systems are based on deep neural networks. Therefore, they cannot practically show the path through their network that resulted in an output because they are billions or trillions of parameters large.

(1) To be resilient in the face of unforeseen circumstances, AI systems must show rationale that users can understand and react to when the systems fail, rather than just forcing users to recall them or assume that the system is always right. Therefore, our high-risk technology innovation will be a Collaborative Copilot that uses interpretable models. This is high risk because interpretable models often do not scale well with data, are not easy to develop like deep neural networks these days due to the tools from tech giants, and are expensive to train.

For interpretable models, linear rules would only be accurate for a very niche domain of data. Their extension into decision trees would not be easy to use because they cannot be automatically pruned. Bayesian networks would have similar problems, so we will use Causal Influence Models (CIMs). CIMs are Bayesian network UIs with connections going in the direction of influence and have colors and weighted lines to show the influence sign and strength.

Although relatively easy to understand, forcing users to read through full CIMs would still result in significant cognitive overload.

(2) To minimize cognitive overload, information system UIs must fit users’ mental states when they are doing work. To explicitly consider users’ mental states, they should be objectively modeled, rather than just guessed by the developers or inferred from biased surveys of users. Therefore, we will supplement the Collaborative Copilot development by designing and empirically evaluating Mixed-Initiative Workflows using a family of research methods called Cognitive Task Analysis (CTA). However, CTA models of users may not match users in the real world, nor do they capture the higher-level objectives and constraints of their work. Therefore, we will also measure the professional contexts of users using a family of research methods called Cognitive Work Analysis (CWA), which outline the objectives and goals of the users and map them to their activities and tasks.

Technical Objectives and Challenges

1. Prototype and Evaluate the Collaborative Copilot

We will build interpretable models with Python tools like Pandas, NumPy, SciKit-learn, and Matplotlib, and will compare our models to deep neural networks created with tools like TensorFlow and PyTorch. We will evaluate these models and compare them with deep neural networks on four metrics:

1. High output quality: We will start with accuracy and machine learning variations on it like the receiver operating characteristic (ROC) and area under the ROC curve. Deep neural networks are famous for being very high quality, so this will be our primary metric.
2. Understandability of outputs: We will verify that users can understand the machine’s output and determine if they are mistaken. We will do this by comparing users’ mental states with the Copilot’s models.
3. Ease of development: Because interpretable models do not train and scale with backpropagation like neural networks, more technical expertise is likely required. We will specifically consider the technical expertise needed to run expectation maximization (EM) training on the networks.
4. Training costs: Large corporations have the resources to build deep neural networks with large amounts of data, while smaller businesses and academia often do not. Therefore, we will explicitly measure the costs for the EM training. For expensive cases, we will consider incremental learning, where they can start out as linear rules, then become networks of rules, and finally become Bayesian networks.

2. Design and Evaluate Mixed-Initiative Interaction Workflows

We will design these workflows with mixed-initiative interaction: utilizing software to process data, generate models, and make suggestions to the user, and enabling users to not only request suggestions when they need them, but to also critique them when they are confusing or mistaken.

The workflows will be evaluated in two ways: (1) by matching the states of the users during tasks to the system’s output: to ensure that users understand the machine’s outputs, and (2) the performance of users and the software accomplishing the tasks together: to ensure that users can correct or take over for the system when necessary to increase resilience.

3. Validate Commercial Viability and Impact

In the Phase II, we will apply the innovations to a use case we have researched over the past few years: reducing information asymmetries between job candidates and recruiters to improve the efficiency of hiring. Therefore, in Phase I, we will work with user representatives from our previous research and development to confirm their commercial viability and impact.

Market Opportunity

• Models: To ensure general use of the models we develop by individuals, they need to always be free. Furthermore, to enable academic research of them and both individual and commercial modification of them for different uses, they should be open source. However, we could offer support services for them to businesses.
• Mixed-Initiative Workflows: The mixed-initiative workflows would likely be exposed via research papers, and thus would be de facto free and open source. However, for commercial usage, they could also be patented and licensed.
• Candidate and Recruiter Tools: The candidate tools were always envisioned to be free to ensure high adoption. Furthermore, since the initial target users were senior software engineers, they could also be open source to enable customizations and improvements. The recruiter tools, on the other hand, are the primary market opportunity for Phase II’s use case. Whether the users are external or internal recruiters, they likely have a budget they can use to pay us.

Company and Team

• Founder: I have a diverse background in technology and data science. I have a BS in Computer Science, and an MS in Information Science. I researched AI throughout undergrad and grad school. After grad school, I was hired in the government R&D field as a decision-support analytics research scientist and software engineer. I wrote SBIR and STTR proposals on human-machine collaboration and mixed-initiative interfaces, won many of them, and led the resulting projects. In other words, I have focused my entire career on these types of problems. I have also collaborated with many of the relevant researchers who have championed resilience engineering, cognitive task analysis, and cognitive agent rationale, and who would likely be happy to consult for this project. I then moved to California and have worked with several technology startups as a full-stack engineer, UX expert, and product manager.
• Company Background and Status: Datagotchi Labs is an R&D lab I’m incubating to use the skills I’ve gained in my career. I have explored several ways to make money, starting with a Patreon page, spinning off this project to raise investments, and running Kickstarters for the consumer-side of the projects. Since none of these have been successful, in addition to pitching to the NSF Seedfund, I am currently working on a marketing campaign to better establish myself on social media to attract some consulting leads and offer freelancing services.

Our economy is based largely on exploiting both natural resources and people for profit without regard to how it affects either the earth or those people. To protect themselves, those in power hide as much information they can about what they are doing. For example, corporate reporting structures are designed to keep lower-level employees ignorant of what executives are doing with their company. Similarly, news website paywalls keep people from knowing important information, even if it affects our democracy! When information is available to people, it is often distorted with complete or partial lies. Failing that, useless information is often used to distract people from important truths.

Many people in the world are working on solutions to these problems. For example, there are people working on data visualizations, which are better than raw, tabular data, but often do not have the necessary context to make them useful. There are many working on investigative journalism to get important information out to people, but these efforts do not decrease the amount of information that is overloading people. As a result, some people have resorted to protests to get out the word on information they think is important. However, this is still dangerous in our democracy because those in power will find ways to disenfranchise them by firing them from their jobs or even arresting them. Most importantly, none of these efforts are focused on enabling people to use the information once they get it.

Instead, people need to be empowered with information. That means giving it to them in the contexts where they can use it. For example, company information would be helpful when deciding whether or not to join or stay at a company; news about global warming would be more useful with tips on what to do about it; and information on a product’s supply chain is useful when deciding whether or not to buy it.

However, while such contextualized information can empower some people, it may not empower people who are not in those contexts. For example, an employee who can’t leave their job because they are in debt would not find the extra company information useful; most people are disenfranchised when it comes to making global warming mitigation policies; and many consumers need lower-priced products so they don’t break their budgets, rather than more moral products.

In other words, people need to be empowered with information in way way that guarantees that it is useful in some way. Even if they can’t directly use it, like information in a representative democracy, they deserve to know it because it affects their lives. Therefore, for the examples above, company information, global warming news and suggestions, and product supply chain information should be easily available — not just upon demand, but to others who may not think to make the demand.

Therefore, I am officially launching my initiative, Datagotchi Labs, to truly democratize information. This means that my products will be focused on this goal, and will always be free for people to use. Requiring them to pay for these capabilities goes against my motivation for creating the products in the first place. It also means that the products’ creation and improvement will be collaborative with any and all people who are interested in participating. While I have a couple of products already in their early stages, I plan to include interested people more in the creation of future products. In the meantime, I plan to involve everyone in the testing and improvement of the Inspect and Counteroffer products once I launch them.

Since I am now devoting myself to incubating Datagotchi Labs full-time, collaboration will start in the form of a Patreon page, where members can pledge a monthly donation to me (starting at $5/month) in exchange for updates, involvement, and early access to my work.

Even if you can’t afford $5/month, though, I would still like to invite everyone to the Discord channel to chat about products Datagotchi is currently working on, and can work on in the future! Find it here.

For further reading

• The Amazon Labor Union (ALU). https://www.amazonlaborunion.org/
• Dewey, J. (2008). Democracy and Education. https://www.gutenberg.org/files/852/852-h/852-h.htm
• ProPublica. About Us. https://www.propublica.org/about
• Tufekci, Z. (2017). Twitter and Teargas: The Power and Fragility of Networked Protest. https://www.twitterandteargas.org/