Understanding product market fit and building a protoype.
How do you understand if your idea is a good one? How can you validate your idea?
If you are a founder with an idea, and you are wondering whether your idea is good one, how do you go about testing the market to see whether it is a good one?
At this point you may want to invest some capital in the idea. But, sensibly you will be cautious. So how do you get to a point of getting feedback from the market?
Investment in technology and ideas used to be time intensive and expensive. Building an app or platform would be mean high levels of investment, just to get to first base. Often ideas would change along the way, and you’d end up incurring most costs and exceeding your original budget.
There is no point building for true scale, if you don’t have an audience. What you really need to do, is put the idea in front of people and see if it matches their needs.
How can we do it effectively?
Rather than building a full on solution, you can build an prototype of minimum viable product (MVP).
This approach creates the space for testing things out, talking to the market, seeing what features are going to work and how they are going to be received by customers. It can also help provide some early indicators on pricing and what features are going to matter.
The key here, is you are not overcommitting.
Because of the current financial climate, investors are looking more favourably at start ups that are already profitable businesses. This is as opposed to betting in ideas and platforms that might some day promise mass market appeal (unicorns).
Capital is being deployed more cautiously and the numbers (profit) need to add up.
And to be honest as a founder you need to think about how you are going to pay yourself before you even get to a potential funding stage. Unicorns are rare. Even being successful is a challenge & very hard work, and not every company is fundable in that huge (Venture Capital) way.
A Venture Capitalist I spoke to during my own attempt at a raise, asked me whether I realised what impact venture capital will have on my company. Yes it will be like rocket fuel, but it will also mean hitting targets to justify the investment.
Everything with VC funding, is about rapid growth.
And you need to think about that. Sometime bootstrapping is a better approach. And to do that, the same rules apply. You need to justify demand.
Learn how Orzo Blue can help you achieve your goals. We build No Code apps. We work with non-technical founders to take their Saas ideas to market.
Is No Code an Option?
Having previously been heavily invested in structured development environments, such as Java, Linux, Nginx & MySql, it has been refreshing to come across some really viable No Code options.
It means getting to market, doesn’t need to month of developer and investment. It means fairly quickly you can get an idea and take it from concept to market in a very short period of time.
This approach will help you:
Learn about your audience. What do they really want, and how they might use your product.
Understand the most valuable features, and how that might translate to pricing.
Will give you time to experiment and try out ideas.
Enable you to experiment, review and adapt.
Give you time to focus on the viability of the business, understand the business model and route to profitability.
Learn who the clients really are, and how to find them, and sell to them.
Talk to real customers and fully understand the problems they are trying to solve.
Going with a no code solution give you breathing space. It means it could be side hustle to start with. You can invest a low amount of capital to test out your idea. It will help you to market quickly and crucially will enable us to start collecting feedback.
Pros & Cons of No Code vs Code
So, is this approach a good one?
Let’s first looks at structured formal application development:
Reliable - we can tailor the hosting, the app optimisation and performance in house. We know where all the (technical) issues are and can act (reasonably) quickly if we need to with some refactoring and code optimisation.
Scalable - if we are running the hosting, we can monitor performance and load, identify bottlenecks and take action.
Ownership - if we create everything ourselves in-house, then we own everything. We can set our own direction. If we outsource we are looking at revision cycles.
We can do it in-house and have full control over the dev and production environment and set up the team accordingly.
Tooling - we define how we go about our work, the software we use and we can build on this as we go through the business cycle.
But, what are the things that are going to drag this approach back in the early days?
Time consuming - coding from the ground up is fun and stimulating, but it takes a loooong time to achieve anything meaningful.
Expensive - good programmers, developers and product managers are expensive. Saving money on hires will impact on productivity (unless you get very lucky). You might save on monthly outgoings, but everything takes longer. And you don’t necessarily end up with a stable platform.
Technical Debt it is surprising how quickly you can build up technical debt, from decisions made in the early days. Assumptions you make back early on, can mean constant refactoring or workarounds to make new ideas work. This also presents hidden (stability) risk and a greater requirement for (regression) testing.
Less flexibility - once decisions are made they tend to be there for the long term. And this can mean pivots weighing heavily around the operational side. You’ve also got to take into account the motivation of the team. If you keep changing direction, the team will feel pretty demotivated. People take pride in their code making it to production.
A lot of management - you’ve suddenly got layers in the team. Yes you need to delegate and trust people to do things well, but also focus can be lost.
Over the long terms this is probably where you want to get to. And these things will cost and it puts pressure on your budget and the sales and marketing function.
But,wWhat if you decide validation is the most important part of what you are doing? Then a No Code approach seems to me like a good option.
It gives you the opportunity to run up some demos for potential customers and also build a version 1.0 you can take to market and see how it goes.
You are also giving yourself the best chance of understand your route to revenue earlier in the cycle. And if things go well then you can afford to throw away the No Code solution and write it properly in a structured environment using the original as the blueprint. That would be a good problem to have.
You can also test and adapt very quickly. You could keep things lean and make some progress at the same time.
You can also focus on value and pricing. You can respond to feedback very quickly.
The No Code Landscape
There is plenty out there, and with it a lot support through good docs and community support. No code tools have hit a good level of maturity over the last 4-5 years. Platforms like Bubble have real traction and a good core product, and has been used by a lot of start ups.
You can even use things like Wappler and Noodl which are NoCode development environments, that enable you deploy your app to your own hosting. Which does give you a route to scaling and app, if you generate demand.
If you are looking for quick wins. it means building upon the shoulders of others. Bubble has a good marketplace and there are plenty of plugins to get you started very quickly. And where solutions don’t exist, we can fall back to something like Zapier, or Make.
And how about mobile? Bubble can work for mobile and be a proxy for an app. However it acts as webpage with in an app enclosure. The main drawback in this approach is the need for a constant network connection. Whereas something like Thunkable, which is naturally native, might be a good workaround instead, and connects to APIs very nicely.
The core challenge is working out whether the new idea is going to be viable and understanding where it sits in the marketplace.