What is the kind of data that is actually valuable for business? Think about it – what kind of data does a business want to see from the government or from some other peer? Think about it. Let’s talk about it on a meta level.
Businesses are essentially problem-solving systems. Anything that helps you make a better decision when it comes to solving that problem is sought after. If you are living in an area where environmental laws are strongly enforced, then a fishing vessel might want to check out How many fish people are permitted to catch this week and How many are already caught.
What kinds of decisions do businesses have to make?
Decisions regarding how to make more money or how to reduce costs and risks.
Then what kind of data would be needed to take these decisions?
We can think of it as operational and non-operational data. Operational data helps them with the sourcing, manufacturing, storing marketing, selling, distributing, and maybe after-sale services. Non-operational things might be helping them with compliances, or one off the risks that might hamper the money. Operational data needs to be regular and granular so that you can take real-time decisions, while non-operational things can be done at leisure, in a business sense of the word.
We can also think of it as data that aids the daily workflow, that helps the business stay afloat. Or data which comes as a need once in a while. There can be some type of data that is baked into regular workflows of users, such as financial metrics for valuation analysts at consultancy as opposed to financial metrics for in-house accountant who also does valuations on need basis.
So the data types become:
- Continious
- Ad-hoc
Absence of continuous data can impede the process and clog the whole workflow. Let’s say it is a 10-step workflow, and step 5 is missing the data it usually needs. Whatever is stuck in step 5 will now be there for a long time, and even if steps 1, 2, 3, and 4 are complete, they cannot proceed ahead. So, it affects the whole workflow. While ad hoc data is necessary at times, but I don’t know how to deal with it yet. Since continuous data is a necessity for day-to-day operations, it can be something that can be monetized using subscriptions. While ad-hoc is something that is sold for one time. Ad hoc can be in the form of tests or courses before you get certified to do that certain thing as a service of your business.
For continuous data you create value by speeding up operations or avoiding breakdowns, and if cost for it is less than loss from breakdowns or gain from sped up workflows then it is easier to sell.
For small teams the opportunity lies in providing easy access to continuous data that is external. For internal things the sales cycle and integration time and effort will be both longer. And that makes smaller player be at disadvantage. Internal data requires customization for each client, Access to company databases, Trust around security and privacy, Change management (people need to adopt new workflows)
To be even more specific and simpler, Provide better access to external continuous data that is used in internal workflows, where external continuous data means, Data that is essential in regular workflows and is obtained from external (non-self) sources.
This is great because the need is proven as it’s already in their workflow, so you’re not creating demand, you’re improving supply. The pain is tangible if they’re manually checking websites, waiting for emails, or dealing with unreliable sources. It also helps you create instant gratification by compressing time to value and effort to value. The value is immediate because faster/more reliable access = measurable time savings or risk reduction. And since it is external integration is lightweight.
In this article, I discuss the concept of process apps and data flow apps and to create process apps is not a venture that you should undertake as a solo developer. And the discussions above point me to the same conclusion as that article. Essentially, what you should be doing is
- Go at the sources of data that the business needs
- Process it into a packaging that is intuitive and useful for the end user
- Transfer it to them
This type of application will result in something that has minimal processing and satisfies the data needs of the customer. And it entirely fits the archetype of solo developers because you don’t need huge commitments or considerations to get going with a client. A-nd of course you should be enriching the external data such that it is way more useful for the client, so there is a value addition component to the whole process.
We should be averse to any idea that includes huge behavioural changes. We dont want to create anything that needs much workflow changes even if it makes something 10x better because its going to 100x harder to explain and sell and maybe 1000x harder for the client to implement. We pour gasoline on existing fire, not create new embers
My prediction:
- 10x better product requiring workflow change = maybe 0x adoption rate
- 0x better product that fits existing workflow = maybe 10x adoption rate