What problem(s) does AgileData solve?

This should be an easy one for me to answer right?

Understand the customers problem first

We get told in startup land that you need to understand the customers problem in-depth, before you start building your product.

So what problem does AgileData.io solve?

It’s a question I get asked almost daily and one I am still struggling to answer with clarity and finesse. Not because I don’t know of a problem that we can solve using AgileData.io, but because I know of too many.

AgileData.io is a SaaS data platform combined with a proven agile way of working. If a customer has a business question that they can’t get an answer to in a safe and repeatable way, and they know they have the data that should allow them to do so, we will collect, combine and present that data to them to help them answer that question.

Some business questions we have seen customers need answers to:

• How many customers have we got?
• Who are our most valuable customers?
• How much product did we sell last week, last month and last year?
• How many Official Information Requests did we answer on-time in 2019?

So when somebody asks me what AgileData.io does, I will often ask them if they have a question that they know they have data to answer, but the answer and data always seems to be out of reach. And then I tell them we can fix that problem, in a simply magical way.

Often the “trust us we can fix that” statement doesn’t gel with them. They tend to want a proven example of where we have solved a specific problem before so they can categorise what we do (put us into a known bucket), or sometimes they know they have a problem, but they cant articulate it clearly and so struggle to see how we can solve it.

There are a number of “patterns” which we could apply to identify and articulate the problem(s) we solve.

Focus, Focus, Focus

I constantly get told that we should focus on a specific use case, or on a specific source of data, or a specific industry and I know that focussing is important.

We could focus on the use case of automatically collecting data and populate predefined metric dashboards and reports, I know I can find multiple alternatives out there that we could compete with in this space.

We could focus on automatically collecting data from specific sources of data, for example Shopify, and making it usable. Again I can find multiple examples of alternatives who say they do that, just have a look at the reporting category in the Shopify Marketplace.

Our first customer was a charitable organisation, so perhaps we could focus on helping charitable organisations wrangle their data to reduce the time and effort it takes them to do it.

Or perhaps we could combine a few of these things to become laser focused.

We could solving a specific problem for Charities who use Shopify and need Reporting or Dashboards at a click of the button, without spending hours every week compiling the data, and without spending all of their limited cash on “technology”.

Can we meet our hairy ambitious goals of scaling to become a global and sustainable company solving that one laser focussed problem? I am guessing the answer to that question is no.

And we would only focus on solving this specific problem, because this is the problem our first customer presented us with, and now we know that we can solve it in a simply magical way.

But it isn’t a problem that we picked as “strategic problem” to be solved.

Race to the bottom

We could focus on doing things cheaper and faster than alternative options.

We could aim to deliver at 10th the cost of alternatives, providing value at a cost that other solutions can’t.

One of our core principles is to provide simplicity to our users by automating every task we can. In doing so we know we can reduce the effort and time required to collect, combine and present data to answer business questions. This results directly in a x10 saving in people effort.

We know peoples time and effort costs money. If we compare our cost of delivery to the true cost of delivery of other solution (software, hardware and people effort) we know we can deliver to the promise of being one 10th the cost of alternatives.

But I have always been taught to compete on value not on price.

You have spent $200k already, you still have $20k left for us to deliver

We could focus on the FUD (“fear, uncertainty and doubt”) factor.

As I mentioned in an earlier article, we often see the 3–2–1 problem, 3 Million dollars, 2 years and 1 report. Now that is an expensive report.

If your a small to medium sized organisation and your outgrowing your ability to use data with your current ad-hoc processes and systems, then you will probably be looking at investing in a solution to automate this.

You no doubt will harness the wisdom of the crowd and ask people you trust what they did. You might be hit with the horror stories of the 3–2–0 failures. Or you might be told that you will need to spend $200k to have that problem solved, and a recommendation of a consulting company that can help.

We know we can deliver with less risk, than the other high FRICTION solutions.

But we are not sure being the ambulance at the bottom of the cliff is the main problem we want to solve. We would rather help organisations deliver early for the $20k and leave them the other $180k to grow their business.

With variability comes complexity, simplifying complexity solves a problem

We could focus on automatically collecting data from multiple sources systems, for example Shopify, Salesforce, Xero and Google Analytics, and then automatically combining it to understand core business events such as:

• customer signs up for account
• customers orders product
• supplier ships product
• customer pays for order

And then we could present the data to a predefined visualisation tool such as Thoughspot with a raft of predefined metrics that identify the financial health of on-line clothing retailers.

This would enable us to solve a complex problem with simplicity.

But again is it a problem that enough organisation’s need to solve, to bound AgileData.io to solving just that problem.

Bespoke craft

We could focus on solving unique problems with simplicity, which other solutions struggle to solve or introduce masses of complexity.

We could become a consultancy focused company that uses AgileData.io to craft a unique solution for an organisations unique data. But we would leverage all the automation and patterns that we have already built into AgileData.io ensuring we are not building masses of orphaned unmaintainable data pipelines or a one-off bespoke data platform.

But this would be hard to scale globally.

Who is your audience

Another piece of advice in startup land is focus on a “persona” and solve their specific problem.

I believe the primary problem we will eventually solve is the disempowerment of smart people in an organisation from being able to collect, combine and present data.

Everybody seems to make their data solutions complex and therefore creates an “Illuminati” of experts, who are the only people that can solve an organisation’s data problems.

We have seen data visualisation tools such as Tableau, PowerBI and QlikSense drive a wave of “data democratisation”, empowering data savvy people to bypass the “data warehouse” team to get access to data. But while this approach did empower this audience, it resulted in new data silos and these products have started expanding their features to includes collecting and combining data in a more repeatable and automated way.

We have also seen the advent of “Data Lakes” to empower the highly technical Data Scientist, but again this area is now morphing to “managed data lakes” where a team of expert data engineers created automated data pipelines to collect and combine data consistently.

Who can create and manage these these data ecosystems? Right now it is still only highly skilled technical people. Either a team of expensive data engineers or even more expensive consultants. And they have a high risk of hitting the 3,2,0 problem, as they are cobbling together a combination of technologies and approaches to deliver the data solution.

We know we have an interesting bunch of patterns that cover both and technologies and ways of working required to reduce this friction. And we know that Business Analysts (and their siblings Data Analysts, Systems Analysts etc) have the ability to adopt these patterns to collect, combine and present data without the need of a technical data or information technology team.

But we need to provide these patterns with simplicity which requires the development of the AgileData.io User Interface and as we are bootstrapping the company this will take us some time to deliver properly.

Managed Platform partners

We could focus on helping partner organisations leverage AgileData.io to solve their customers data problems.

Currently who can create and manage a data platforms for an organisation? Right now it is large and expensive consultancy companies that have the technical skills and can afford to spend the time to cobble together multiple disparate technologies and approaches, or an organisation that can afford to hire and retain a dedicated internal team of 5 to 10 technical data experts. Both expensive options.

We could enable small 2 to 5 person consulting organisations to work with specific use cases, specific data sources or specific industries and enable them to deliver like we can. We could help them to deliver at one 10th the cost of their competitors and at 5 times the margin.

But it will take us time to build this network of trusted partners and build out repeatable patterns required to help them become successful.

Where is my recipe Nigela?

We could package up “cookbooks” for specific use cases, data sources and industries.

These would allow our customers or our partners to deploy prebuilt and proven “combo’s” of data sources, and metrics that are tailored for a specific use case or industry.

For example customer and product profitability in an energy company, or customer acquisition and cross-selling for an online retail store.

But it will take us time to build out each of these cookbooks so that they are automated, repeatable and sustainable.

And so its a problem solving journey

I struggle to bet our success on solving just one problem, or allowing ourselves to be pegged as doing only one thing, as we can solve so many different problems (and solving problems is fun).

I fundamentally believe that similar to the way most organisation’s have data with a massive amount of variety, the problems we solve should also be as varied. But we should solve these problems using repeatable and automated patterns to reduce the complexity and friction.

So maybe that is the key, if a customer has a data problem, we will solve it in a simply magical way.

As we solve each new problem for a customer in a specific industry, or with a specific source system, or with a specific use case, we will make that solution available (as a “cookbook”) to anybody else that has that specific problem.

Over time we will end up with an unenviable portfolio of problems we have proven we can solve. And of course then we will hit a new problem, akin to a restaurant that has to many items on its menu and overwhelms the customer with the breadth of choice. But I have already thought of how we might handle the implications of that success hitting us.

Which means how we message the problem(s) we solve will need to change over time, as AgileData.io grows. But change is always a constant, especially in an agile data world.

Right now I’m excited about focussing on the the journey of discovering the world of customer problems that we had no idea existed, and solving them all one by one.