Let’s talk about how we build a product from scratch with low technology and no code. Not just a mock-up, but an actual product we launch, sell, and grow.
The key is to build a pilot MVP around our core idea. Everything around that core idea should be manual, flexible, and low tech, so that it can evolve quickly as we learn.
I’ll explain why this kind of pilot is critical, and I’ll run through each part of the product cycle and discuss what kinds of low tech can substitute for future high tech counterparts.
Why No Code? Because No Rules.
Here’s a sneaky truth about tech. No one NEEDS technology. In fact, the more technology we have in our lives, the more complicated our lives become. But we embrace technology when it simplifies our lives without reminding us that it’s there. We love technology when it solves our problems and makes our lives easier. We need technology to be able to do those things we can’t do manually.
The mistake entrepreneurs make is applying rules to our tech before we understand how our users will embrace the product, how it will simplify their lives, and why they need it.
The great thing about a low tech pilot MVP is that it forces us to reproduce the manual steps that will uncover those rules. When we do things manually, we get an education on what will go wrong, which of those problems are the most costly to us and to the customer, and exactly how our tech needs to address those problems. Once we have those rules, then we build the tech.
Thus, we don’t want to enforce a lot of rules during our pilot MVP. You may go into it saying something like, “Well, at the free-to-use level I don’t want them doing this yet.” You don’t know that yet. Coding that rule before you launch the MVP is risky and expensive.
Remember, at every turn, technology enables our product, it doesn’t comprise our product.
People: This is your code
Ultimately, technology enhanced products provide the most value by making decisions for us and for our customers. But technology on its own is not a decision maker, no matter how much machine learning you throw at it. Those decisions are always first and best made by people.
So at the MVP stage, our people are going to substitute for code, taking in all the inputs at each part of the process, figuring out the math to make the product work, and sending the outputs to the next step of the process. They should document everything they do, including all the outliers, mistakes, problems, and numbers.
This documentation will eventually tell you what you need to build first, how much it will cost, and how flexible each piece needs to be.
In other words, before you get to artificial intelligence and machine learning, start your MVP with human intelligence and actual learning.
Spreadsheets: This is your database
Throughout my career, I’ve dabbled in SQL, data science, and machine learning, and I’m still a huge fan of the lowly spreadsheet.
Spreadsheets will serve as your very basic, very non-relational, very feature-poor database. They might also provide the logic and the calculations you’ll need to perform some of the functions of your product — the math that will eventually will be handed over to your technical team.
While your people are collecting inputs, doing that math, and creating outputs, all the data they produce should be stored in one or more spreadsheets.
You’ll want a spreadsheet for you users, for your attribution, for your costs, for your revenue, for any result that has a number attached to it. You’ll even want spreadsheets for data that isn’t numbers but you believe you can quantify later.
Bonus: An online spreadsheet solution like Google Sheets or Excel for the Web allows multiple people to collaborate and tracks their input.
Sharable Docs: These are your functions
Don’t sleep on how shareable documents — Google Docs or Office 365 or whatever — have changed the game in terms of information management. When used properly, shareable docs are your functions, used to collect and manage information according to a standard set of rules.
Shareable docs can be limited to a single user or groups of users. They can be internal or external or both. They automatically collect all sorts of meta information including user IDs and timestamps. And they can be constructed to be able to collect unstructured information in a structured format.
These are a lot of the same things that code does, only code does it prettier.
Bonus: Google forms and surveys allow you to limit the input options, and automatically generate spreadsheets for your low tech database.
SMS/Email: These is your APIs
Application Programmer Interfaces (APIs) send information (data) from one part of one system to another part of another system. In low tech terms, a text message (SMS) is an API from one person to another person.
Yes, this can be clunky, but to be honest, SMS is probably the most frictionless user interface you can imagine. No app is needed, no format is needed, all the rules happen on the backend, so to speak.
So SMS and Email, basically any form of digital communication, will serve as your very manual, very slow, very user-unfriendly input and output.
Bonus: For an advanced run at low tech APIs, Slack and Zapier can act on information as it comes in or goes out, including information that comes in from Email or SMS.
Online Payment Processor: This is your eCommerce engine
The most important part of any product is how it collects payment. This needs to be frictionless.
Thankfully, there are a lot of providers out there now that handle everything for you. Rather than list them all and talk through their pros and cons, let’s instead talk about getting to revenue quickly.
And I can handle this with one sentence:
I don’t care if your MVP launches with customers having to mail you a certified check, it’s always more important to launch with a pricing and payment structure in place than to have tech hold you up too long from launching or collecting revenue.
Bulk Email Service: This is your CRM
A bulk email service like MailChimp or Constant Contact is a simple way to start building a Customer Relationship Management (CRM) system. It provides basic reporting on opens and clicks and conversions, and it’s completely self-service on the customer end.
That last part is important, because this is the first low code system that will act as a secondary system to your low tech MVP. You’ll have a spreadsheet for your users and a list of contacts in your MailChimp. Where those two data sets intersect is going to be your customer base, so that data has to be up to date.
Bonus: A lot of the bulk email service providers offer semi-automated ways to input to and output from your users spreadsheet, including Comma Separated Value (CSV) downloads and uploads.
Google Analytics and Social/Ads: This is your Marketing
Even if you only have a static website, it’s important to have incoming and outgoing marketing data from the beginning. This step can come last in the MVP process, but it’s mandatory, because it’s your future.
Your website and/or app is your inbound funnel, this is how you get people to the product. Your social and web-based advertising are your outbound messaging, this is how you let people know your product exists. All the parts to make these things happen and collect the data from them start with low tech.
Google Analytics is the beast, with a simple cut-and-paste process to get it working and a web-based reporting system to analyze the results. The social networks and ad platforms all have their own portals. If you want to aggregate your messaging, there are free low tech products like Hootsuite or Hubspot.
Bonus: Google Analytics reports inbound from social and advertising portals. It also has APIs that can connect directly to those portals to track clicks and even conversions.
When They Come, You Must Build It
Finally, remember that you do eventually have to build your low tech into something real and scalable. You can launch your MVP if you don’t know if your low tech will scale, but you can’t launch your MVP if you don’t know if the real tech will work.
So as you design and tweak the processes around these low code solutions, always be thinking about the viability and cost of the final coded solution.