This document is pulling from a lot of existing stuff I’ve already written about Doss and our roadmap and passing it through the lens of what we need to do in 2024.

What is the story we are telling our customers?

‍

This is the sequence of what we want to deliver in the next year:

1. Inventory from PO to POS
2. Provide all of the tools to meet the unique needs of your business
3. Layer on best-in-class Finance and Accounting workflows
4. Get your most important workflows up and running in minutes

‍

How do we make this possible?

We find this to be particularly interesting because we’re trying to:

• Reconstruct and merge the functionality of dozens of applications-specific products. The result of this is what I call Platform Parity.
• Achieve Platform Parity in 1/100th the development time
• Allow for our customers to adapt the capabilities of our platform to meet their needs
• Onboard our customers 1000x faster than our Platform Parity competitors (as a ballpark, SAP is using 42,000 work hours in their example). Let’s say our target is somewhere between 4 hours and 40 hours depending on complexity.
• The end-to-end System-of-Systems is legible, visible, and easy to understand and interact with regardless of prior context

‍

Let’s consolidate that into one sentence to really get a grasp on how ambitious this idea is.

We want to put together almost all of the functionality, in 1/100th the time, make it dynamically configurable, and speed up customer implementation by 1000x.

Not only is this actually possible, I believe it’s only way to bring about substantial changes every industry touched by ERPs and large-scale software implementations. It’s a puzzle that can only be unlocked it if you realize the key is to address all of these “seemingly conflicting” goals at the same time.

‍

The impediment to action advances action. What stands in the way becomes the way.
— Marc Aurelius, Meditations

‍

Often this has become paraphrased as “The obstacle is the way” — if we think of our desired results from above as the obstacles, then we need to reframe the points contextually to show us the answer.

I picture this problem solving exercise as trying to build a figurative key that opens a lock. This analogy is powerful because keys are NOT sequential. Each attribute of the idea is a tooth on the key. Every piece must all work together to unlock the result. They’re all unique and any of them being missing or incorrectly shaped makes the key entirely useless.

Our ideas don’t make sense in a sequential and serialized manner. They all need to be considered and applied at the same time.

‍

‍

‍

[1] Elemental Building Blocks

‍We can rebuild almost entirety of Quickbooks, Anvyl, CIN7, Bill.com, and more if we distill these products down into their most elemental components.

I call these “primitives”, “prime factors”, “atoms”, “basic building blocks”, etc. But you get the idea — it’s an indivisible thing and it can be stacked up with other primitive ideas (”update a piece of data”) to make bigger ideas (”create a procurement workflow”).

In our case, we’re operating just one or two layers above the abstractions provided by programming languages, SQL databases, and cloud infrastructure.

‍

[2] Pragmatic Product Algebra

The way we achieve Platform Parity fast is by identifying and building the most useful base representation. Some examples of what this looks like:

• We made Tables a group of Records, which is a group of Fields, which is a set type of data. This is basically a super-typed abstraction on our database! We offer things like lookups, formulas, dates, money, etc.
• We made Tables actually have the idea of “Subtables”. This is super useful since often you’ll want to have granular control over: a table of POs, an individual PO, the line items within that PO, and the details of a specific line item. Our elemental model of this is: Table → Record → Subtable → Subtable Record.

We designed it this way because it’s actually a super common representation of information! Look at POs, Invoices, Product Catalogs, and Payments and you’ll see that they all basically follow the exact structure I just described.

Once you have a bunch of elemental representations that are (a) useful (b) composable, then you can build features to Platform Parity using your own system instead of a lower-level base syntax (programming language / infra). This means that for every net new idea that someone needs, you don’t have to “build it” explicitly. You get it “for free” implicitly, it just needs to be configured.

‍

[3] Process-Model Solidarity

‍There is where we start to see the interconnections begin to link with one another. The idea of process-model solidarity requires a bit of philosophical examination. The main point is that very often we represent the information about something separately from process itself. This attribute of our key is to unify the model of the process and the process itself into one thing that presents the process and also does the work.

Sometimes this gets reductively called “WYSIWIG” but I think it’s actually a much more elegant idea than just an editable content pane.

Let’s imagine you visit a carpenters workshop and an automotive assembly line. You’re tasked with describing the process for making one of each item: a wooden chair and a Ford F150. In the case of the wooden chair you’d probably start by asking them for a step-procedure and you’d write out a representation as they go through each step. In the case of the truck, you actually don’t need to ask anyone to get started. The assembly line itself ends up being a tangible guide — you can walk around the facility and see the materials getting transformed step-by-step and how this flows into one another.

There are many companies that have taken this idea to its logical extremes. BASF, a massive German chemical company, implements this idea as their concept “Verbund”, where their Headquarters is basically an entire chemical production city with thousands of miles of pipes, roads, and rail.

The implicit consequence of this is that you get a process that represents itself accurately and legibly, which is not true otherwise. I’m sure many of you have looked at assembly diagrams, process flowcharts, etc, that are “the latest version” but clearly not actually what is being done because people stopped updating them.

To put it another way: I had a great conversation with someone recently who works at Anduril and they said that was so frustrated by a recent experience he had. They were constructing a simple workflow for moving around data between other systems of record (their HRM, CRM, MES, ERP). In practice, he said it was impossible for them to build given the way that the data elements of the different systems could be accessed. Despite how trivial it was on the whiteboard, it was beyond their capabilities to put into practice.

‍

[4] Semantic Autotranspiler

‍This is something that humans are actually very, very good at already. We’re intelligent creatures and we’ve been given the ability to take the semantic meaning of something and translate it into syntactical structures and reconstitute a new semantic meaning. You’re literally engaging in semantic transpiling at this exact moment as you read the literal words of this sentence and develop your understanding and meaning.

What is distinct about the final attribute of our key is the “auto”-ness of it. The idea of a machine, or a system of machines, that are capable of taking in semantic meaning and reconstituting them with a target syntax and grammar is fascinating but not super novel. We’ve had transpilers, compilers, grammars, etc for a long time. What is truly novel about this exact moment in time is the ability to create a transpiler than handles dimensionality so well — you don’t have to write a massive monolithic parser to “figure out what to do” for a given set of expressions. Large-language-models have opened up an entire realm of possibilities where I can say: “I want to do XYZ given ABC” and we don’t have to have predefined the circumstance of what do with X, Y, Z, A, B, and C.

‍

Now that we have rigorous explanations for each attribute of our solution, let’s examine our desired end-state and show how this will work:

• Platform Parity in 1/100th the time → achieved by assembling product elements algebraically to feature-completeness instead of building all of the features individually
• Customers can adapt the product to meet their needs 1000x faster → achieved by using the autotranspiler to give users deep capabilities without syntax mastery
• E2E the system is easy to understand regardless of prior context → achieved through process-model solidarity being component of algebraic expressions of well-defined elemental building blocks. Additionally, the transpiler works both directions — it is able to understand the context of something and synthesize a human-representation of it the same way it can do the reverse.

‍

What, exactly, is going to happen in 2024?

I’m sure you’re tired of all of the representation gymnastics and conceptual framing — let’s put this into literal terms and go through the nuts and bolts of what actual is happening this year and where we need to focus.

‍

[A] New and Improved Building Blocks

What does this contribute to: Get to Platform Parity

We’ve identified a bunch of atomic elements and implemented them. This year we need to improve on what we have and add some new ones where we’re falling short.

1. Data visualization: we need charts, metrics, and dashboards. Simple, but needs to be easy to use on top of our existing data model.
2. Finance and Accounting primitives: I’m not sure if it is necessary yet, but we might need to make some dedicated components for Journal Entries and a General Ledger instead of using our existing Tables, Records, and Subtables. We are already to do so much with what is in place today — we just need to focus on GL use cases and see there are emergent properties that we have not captured fully.
3. Upgrade existing Tables, Records, Forms, and the product information architecture to improve usability across the board.
4. Role & Resource Based Access Control (RRBAC). Simple idea that will require complex execution of state, permission control, and more. This will allow for permalink sharing, password link sharing, user permissions, external (guest) users, public form publishing, workspace-level controls, CRUD controls, and more.

There are so many workflows that users need to access that don’t rely only on first-party data. Sync with Shopify, Amazon, Stripe, Square, Faire, their email inbox, a CRM, Quickbooks, a QMS, and so on.

‍

[B] Integrations-as-Workflows and pre-built connections‍‍

What does this contribute to: Fast Time-To-Value

1. Best-in-class integrations with the heavy hitters: Shopify, Amazon, Quickbooks, Email. We create a pristine and super simple experience for our most common 3rd-party data sources.
2. Generic API Actions which trigger on webhooks and can GET / POST / etc. This unlocks the long-tail of integrations by treating “Integrations-as-Workflows”.
3. Data transformation: better querying on 3rd-party and 1st-party data, this is a barbell approach where mostly it will be very simple or very complex. We need to design around this bi-modality, by exposing our actual Doss Data Model Abstraction Layer (DDMAL).
4. This goes beyond the product. We need to think critically about how to connect the Product Vision articulated all throughout this document with a GTM Vision that thematically is aligned. Is there a way to make this product more self-service? How can we get someone engaged in a 15min phone call? How can we spread the word about this new way of doing things?

‍

[C] Improve UX for workflows and CRUD

What does this contribute to: E2E Legibility and Recognition

‍This also contributes to our initiative of fast adaptation, but largely will allow us to give our users more control over what is in their Doss instance.

1. Workflow Editor needs a more comprehensive read-only view so that we can begin to use it for it’s intended purpose of E2E legibility and recognition.
2. Basic use case should be that someone can go into a workflow and quickly read through / scroll / zoom in/out on the canvas and understand what the workflow is doing (or supposed to be doing).
3. Tables need CRUD and Smart Import from CSV
4. Forms need a basic editor for simple fixes and setup
5. Everything about Form CRUD except file field mapping should be in scope (even that might be OK)
6. Triumvirate of Workflows <> Tables <> Forms needs to have conditional validation guardrails not just on the backend but also exposed in the frontend.

‍

Slowly and then all at once

We are building a best-in-class ERP that can get your most important workflows running in minutes. Doss grows with you; it doesn't take 18 months to implement and cost a small fortune.

If you're wanting to learn more, please feel free to book a demo with our team and we can help evaluate if Doss ARP is right for your team.