Or, the No-Product Framework
In recent years, there has been a marked shift among founders reverting to the old practice of launching full-fledged, bloated ‘MVPs‘. A trend among startup founders I work with is to once again launch products after months of extensive research and product development, sinking resources without much by way of actual product demand validation.
The Lean Startup methodology advocates developing a no-frills minimum viable product (MVP) and launching it as quickly and efficiently as possible. However, ‘minimally-viable product’ has lost its meaning.
I’d like to propose a somewhat radical idea in line with the philosophy of testing out a startup hypothesis with minimal wastage of resources. Yes, you read that title correctly. Just launch. Without a product.
In this article, I would like to propose a structure for framing problems in such a way that product hypotheses can be tested without a conventional product. I can assure you that it works – I’ve done it myself.
What launching without a product actually means
The concept is fairly simple - it means testing a business hypothesis and giving users its core value proposition without the aid of an app.
Fundamentally, it focuses on identifying the single main value proposition and replicating manually the process that the product would follow to deliver this value. As customers grow, the emphasis is on using no-code tools and integrations to automate the process as quickly as possible.
This No-Product Framework allows you to test what you are building and evaluate your product more easily, without sinking time and money into building even a barebones MVP.
The problem with Minimum Viable Products and Minimum Viable Services is that people tend to think of the 'Product' or 'Service' as the end goal, not the first basic beta prototype.
Another technique, the Riskiest Assumption Test, aims to reduce this psychological feature bloat by emphasizing testing out just the single most critical assumption first. The issue is that often this leads founders once again to building a product, albeit with a limited feature set.
Why you should be launching without a product
As I briefly touched upon earlier, this is the most agile & flexible hypothesis testing method, period. It is the simplest and most flexible and efficient path to get a startup up and running building the right product.
The No-Product framework allows gaining maximum customer and market insight with a minimum spend. It allows founders to incur the least possible amount of technical debt, with much more informed and focused development effort when product development actually starts.
Any results and insights gained from a No-Product launch will be much cleaner and more de-noised than usually obtained via a typical MVP, which inevitably boxes customer feedback into focusing on the product itself as opposed to the value proposition at the core of your business hypothesis.
In addition, the No-Product approach guarantees a very rapid, lean and incremental product development process. I will take the liberty to call it the most rapid, fastest, leanest product process out there.
How do you launch without an MVP?
The first step is to identify the 1-2 main hypotheses, the ones that test your main business (or growth) model.
Next, identify what goals the product would accomplish and exactly what value propositions it would provide. Develop an understanding of what processes and workflows the product must implement to accomplish these goals and provide this value proposition. Write these processes and workflows down.
At this stage, the aim is to manually implement these processes and gain a small pool of initial users to gain valuable feedback on the validity of the business hypotheses and product value.
Refine & reiterate the process simultaneously while quickly automating as much of it as possible, using no-code and other extremely quick time-to-market techniques. An excellent go-to set of process automation tools worth looking at are Airtable, Zapier, Hubspot, Mailchimp, Google Forms and Google Sheets. These should serve to automate a lot of manual work within a day or two of configuration.
Repeat in weekly/biweekly cycles, rapidly iterating on the product.
How should one consider whether to launch without an MVP or not?
This approach is helpful for process-centric services and products that do not need highly-complicated consumer-facing functionality (although complicated functionality is generally a bad idea in itself).
What is the product? If the core business hypothesis is to solve a problem through a certain process, even if it means a process facilitated by fancy algorithms and apps, then the answer is most definitely yes.
Examples of successful products that could very easily use this approach include Uber (manually call up drivers distributed across a neighborhood and connect them to riders), DoorDash (manually call up a rider and restaurant to process an order), and most other big names whose core value proposition was not software.
How much technology is required to solve (not scale) the problem? If an app or minimum viable product is critical to proving your hypothesis, then a No-Product approach is not very helpful. Microsoft would be an obviously bad fit for an approach like this.
However, for most other businesses launching a product (should) make sense. Note the emphasis on solving the problem, not scaling. We tend to conflate solving a problem with creating a scalable solution to solve that problem. An app that connects pet owners to dog walkers in their area is not the solution to the problem of dog-walking, a dog walker is.
If the core value proposition is not software itself, then you should seriously consider launching without a product. This question is one of introspection, and will usually point you to a No-Product approach.
When does it make sense to launch without a product?
The right time for actual launch depends on a few factors. A very clear idea of the problem that will be solved is critical. A good understanding of exactly how the solution will solve the problem is also important.
A defined set of processes that will be used to solve the problem will help frame the solution hypothesis. Prior to launch the solution hypothesis should be framed as an experiment, with a concretely defined purpose.
In particular, the following questions should be asked:
In particular, the following questions should be asked:
- What are the learning goals of this experiment?
- What is the hypothesis of this experiment?
- What are the tests to validate this hypothesis?
- What are the targets of this experiment?
- What are the results?
- How are the results being tracked?
- What does success look like?
- What does failure look like?
Once you have satisfactory answers to the above considerations, it is generally the right time to launch operations and quickly test out your core hypothesis. It's also helpful to have an understanding of how you would ramp up product development quickly once the initial experiment is live.
When does this approach not make sense?
As highlighted earlier, situations where the product or app are critical to solving the problem are generally not good candidates for this approach.
Another consideration is if the founder knows exactly what to build based on extensive prior market feedback and user research. If funding is not a challenge and a formal launch with guns blazing is required instead of a staged and piloted launch, then it also makes sense to build out a more complete MVP that covers not just the core value proposition but also embellishes it with finishing touches.
The drawbacks of this approach
If a founder incorrectly underestimates the importance of an actual product for their startup, they may find their results from this experiment skewed towards the lack of the product instead of towards validating their idea. The inherent benefit of a No-Product approach is a very short iteration cycle so hopefully, such a mismatch might be found early on, but this lack of fit might go unnoticed.
Another drawback is the high operational overhead that may arise from manually operating everything. This may detract from product development efforts and the team may find themselves bogged down in day-to-day operations instead of being able to focus on the bigger picture. The way to mitigate this is to ensure that the automation of manual processes starts early and is done as quickly as possible.
The final challenge with a No-Product approach is the danger of over-optimizing based on the small sample size of initial users, especially in the early days when it is difficult to find a representative and unbiased user pool. To overcome this challenge it you should continuously research your users to validate the target customer personas, keep reassessing product direction and whether progress is in line with the vision.
If you liked this, you should definitely subscribe for more cool stuff!