IT could be Excel
Why I think some MVP's can be just analog + excel and how to avoid doubling the cost of development.
In sales-led organisations, especially startups, it's pretty common to develop some sort of system whenever leaders identify a sales opportunity on the horizon. Such an "opportunity," driven by sales or marketing and tested on a single customer with a low-code/no-code MVP, might not be enough to define product-market fit. I've seen it, but this experience was a great lesson on how to avoid it. To illustrate, let's consider an example:
Imagine we built a "sales platform" to sell solar panels to B2B customers, but with some additional "ifs," like limits or special promo tiers for each customer. Leadership decided to launch this project with the help of a third-party agency to avoid disturbing the internal product team, and now, we have a single company using it.
"Great! We have a customer, so we have PMF (Product-Market Fit), right? Now it's time for our product team to take over and scale. We are here!" - said sales team.
But it's not so easy... There are several issue that might pop up.
Handovers Are Costly
You have Zapier, maybe Wordpress with tones of plugin, some email automation tool or Glide, connected to some standalone database outside your infrastructure. If the operational employee, responsible for this unit, leave the company, with no written process in place, it becomes extremely difficult to understand how such a tool works. The product team needs to return to the drawing board, gather requirements from the sales team, and, based on the current no-code solution, define the process again. Remember, product team was not engaged on MVP stage.
Very often there is also quality issue in fast prototyped MVPs done by external agency. Scaling, these solutions become expensive and harder to adjust based on requirements needed to onboard new customer. - To be clear, I appreciate the no-code/low-code options available on the market, but they must be chosen wisely.
At the same time, there is a strong push to scale this solution to other customers, leading to chaos and disorganisation, consuming both time and money—again, because a similar effort was made at the initial project kickoff.
Moreover, without a clear unit P&L, it's hard to monitor costs and assess if the business unit fundamentals make sense. Remember, we're still discussing an MVP without confirmed product-market fit, yet there was a strong push to adjust/scale app to sale it to new customer. Time is money and we burn even more.
Then what?
How much simpler it would be to dedicate one person to manager orders, create a catalog, and make a simple listing page or send a full offer via email to companies we'd like to work with. With a great process and discipline, this can be a scalable process that is easy to monitor on google sheet. If we acquire the first, second, third customer, and together with the product team, we determine that we can achieve healthy unit economics, then it's time to invest in software. By then, we have all the requirements and needed data to assess what we need to build.
I've found that nowadays, everything must be a system. I miss the times when tasks could be managed in Google Docs, and people were more process-oriented than app-oriented. I know that tool might be not as interesting but now in non ZIRP world efficiency is the key. My strong advice is to leaders and managers is to:
- Have a dedicated P&L very early - even with analog process
- Engage the product team very early
- Do not rely on an outsourcing agency without an internal tech umbrella.
- introduce bulletproof "analog" process first.
- and then build application.
In essence, it's more important to have a working model for a few customers in an old-fashioned, analog way than to create a low-code app that will need to be replaced eventually. From my experience, if something can be sold over the phone or landing page, managed with Excel, and customers are asking for a solution to streamline and excel the process, this is a strong indicator that you have PMF.
Disclaimer
I know this is an extreme example and something must have gone wrong in Product & Tech to allow the sales team to go this far, but when the P&T team is based in a different region and is more of an outsourcing agency than a partner, these conditions can arise.
Cheers,
M