Are you planning to build an application? This method will help you achieve success.

Hi, This is Kamil Tarczynski. I'd like to welcome you to another episode of our JUST NO-CODE podcast. In today's episode, we're going to talk about how to vet ideas for implementing new solutions into an organization or releasing new products. It might seem that these two topics are not quite related, because it's a bit different to release a product to the market, of course, a new application or something to help users, and it's a bit different to deploy a solution to companies, where we already know the users, we can ask their opinions. And of course as these two processes differ a little bit, they are still fundamentally supposed to solve certain problems. They're supposed to help users solve certain problems, so that those problems get rid of, so that we can increase productivity or so that we can help in some other areas to make these projects successful. We have to verify our ideas. We have to somehow verify that whatever we're thinking about has any, has any raison d'être, and that it's going to be an answer at all, a real answer and a real help to solve that particular problem.

‍

Why is verification so important?

‍

Let's start with this. Verification is important for the reason that, of course, if the idea of implementing a new product or a new solution into an organization, however initially verified, it is obvious that we reduce the risk of failure to any degree. Reducing the risk of failure entails other consequences. It may not be the best word, but it drags with it other benefits. When implementing such solutions, of course, if we want to reduce the risk of failure or failure of a product, well, we should take some time to verify the idea. Later in the podcast, we will be talking precisely about how we can de facto verify this idea. Whereas now we are talking about the benefits of verification itself. So first, of course, is risk reduction. If we reduce the risk, well then, of course, we also reduce the risk of financial loss or financial loss. This is very important from the point of view of the current times, but not only, because of course we know that the current times are very uncertain when it comes to spending or budgeting the funds we have, or in the case of startups, raising funds can be difficult.

‍

Unless we actually prove that this idea of ours has any, any raison d'être.

‍

Of course, in the case of startups, it's a slightly different scenario, because if we want to raise funds, having a customer base already, having some working product that has already been somehow pre-verified, it will be much, much easier for us to raise these funds. In the case of companies, on the other hand, when we implement a product in our own organization, it is also easier for us to verify the idea, because we have users with whom we can talk directly. We also have some history of how our company functions, what our users need. So here it is the steering of these ideas or these projects that can go very differently, look very different. However, in the case of startups, the moment we want to verify an idea, a very interesting aspect is that the very verification itself can bring us a certain customer base. Well, because with whom else but potential customers? We will be verifying our idea, so de facto reducing the risk, verifying the sense of the idea, we build ourselves a user base by the way, in the case of startups of course.

‍

The next such aspect of why it's worth saying why it's worth doing these things in the first place is not that, of course, we're reducing costs and why we're reducing costs, and what's the difference between de facto reducing costs and minimizing the risk of incurring some costs.

‍

If we don't do anything, we won't spend anything. This is a self-evident fact. So the moment we verify that our idea doesn't make sense, well, we just reduce the risk of losing the money we want to invest in the idea. On the other hand, cutting costs is something else. Please note one thing, that very often, unfortunately, at the moment when we come up with an idea, we want to implement an idea, because it seems to us a great solution, it will simply change and turn the whole market upside down, we very often get caught in such a trap. Not even that it will turn the whole market upside down. But that it will change the mega face of our company, we very often catch ourselves in such a trap that we want to immediately build a great product, a great product that will already cover all functionalities, all needs whether it's our company or our customers. With the eyes of our imagination we see these big products that make millions of dollars or that mega increase productivity in the company.

‍

On the other hand, you have to remember that this is a very long way to go. If we come out with just this assumption that we are building a great product right away, doing everything right away, we will very often fail that way and very often spend a lot of money down the drain.

‍

Because even if we don't fail, but build a product that has caught on in the market, but has 10 different functions, and users only use three, four, even six, it turns out that we spent those 40, 50, 60, 70% down the drain. So here the verification of ideas can help us a lot, because we will start by building something small. We'll start with the first functionalities that will cover the users' needs in a minimal way, but further on we won't build functions that we don't know if we need. We don't know if they make any sense, but we will build what our users will realistically need. How will we know this? Obviously they have told us themselves that they need this, that or are simply missing something in our application so they can complete the whole process. So this is the third point, which one? Why is it worth building at all? Why is it worth vetting these ideas at all? Well, precisely for the reason that we can simply spend less money than we originally anticipated.

‍

And the last point, which of course is related to all of this, which you've probably already guessed, is the reduction of time.

‍

If we don't just build this big solution, right away just release the first iteration, the second, the third, we reduce the time to market, that is, we reduce that time it takes to go to market and de facto get the first investors, which will be our customers. There is no better investor than our customers who pay us for our product. In the case of companies, there is no better investment than one that lasted a short time and cost little. Of course, there is rarely such an ideal scenario, well, but we should always try to simply strive for it. So why is it worth it? To summarize, first of all, risk reduction. By reducing risk, we reduce the possibility of failure and increase our chances of success. We also reduce our costs that are associated with building an application. We also reduce the time that is involved in building an app. And in the case of startups, we build a potential customer base. I think these four arguments are good enough to convince anyone that it's a good idea to simply vet a product before taking on building it.

‍

And now let's talk about why de facto this whole process applies to everyone.

‍

They don't just apply to startups, they apply to startups. It affects small companies, medium-sized companies, mature companies, giant companies. Why is this the case? Well, because I think that the problems or benefits that we just discussed earlier apply de facto to any company, whether it is an internal product or an external product that we want to go out to customers with. It's undoubtedly the building of these benefits, the reduction of this risk and so on that is a very important part of approaching the building of an application or the building of anything that we want to implement. Okay, so now that we've talked a little bit about why it's important to vet ideas in general, let's now talk about how to approach it in general. Of course, there are many methodologies on how to verify ideas, how to approach it, for example, the Lean Startup Business method, Model Canvas or several others, which we will talk to each other about in future episodes of podcasts, which we will verify and go through.

‍

On the other hand, today I would like to talk about such a simplified method based on Kanban based on lean startup, a little bit of just such a life-like method, which many people now just use, which is also relatively simple to verify.

‍

It probably applies mainly to startups, while here the cases of larger companies or companies in general that want to implement something internally, we will also be able to apply this method in part, simply excluding certain points. Let's say we came up with a great idea. An idea that is simply going to revolutionize the whole world, is going to conquer the market. We are expected to make hundreds of thousands on it. Or millions of dollars. How to do it? Of course, the idea itself is still nothing. Each of us has a multitude of ideas. Each of us has the same ideas or similar ideas. It's always the implementation that matters most. Execution is something that raises our chances when it comes to verifying this idea, our chances of success with this idea, which we will de facto want to implement. If we listen to ourselves many business practitioners, etc. Each of them will tell you that, above all, it is the implementation that counts. Dan is better than perfect. Our solutions will never be perfect, will never cover 100% of the users' capabilities or needs.

‍

What is important is that we simply all the time and steer. And of course, we'll get to that aspect in a moment.

‍

Today we'll go step by step through what the whole process should de facto look like and where we can start. Let's say we are ourselves an entrepreneur, we may have a company, we may not have one, but we want to enter the market with a new product. We may also, of course, be a solo person who just wants to launch his first business. How should we approach this? To begin with, in general, it's worth seeing if there is any market for our solution, if indeed the problem we are thinking about and besides talking to our friends, if there is and they have confirmed our idea yet, is there a bigger market for what we want to do, for this solution of ours? How do we do that? How do we verify that market? Well, and of course, thanks to social media or the era of the Internet in general, it's much easier for us to reach customers. Of course, on the other hand, there's also a lot more competition, so we have to cut through all the information that floods us in our daily lives.

‍

Well, but there is a method for that. We can easily reach customers, we can call them, we can write to them, and so on and so forth.

‍

Of course, this is not a very efficient method that will also allow us to scale our solution. So where should we start? Well, in my opinion, this is also confirmed by very many experts. It is worthwhile in general at the beginning to build, for example, some kind of landing page, landing page. This is something we can make ourselves. We can make ourselves a cottage industry, using just a tool like Bubble, like Webflow or even like WordPress. Build the first landing page, with which we tell what the problem is, what the solution is, how much it will cost, how we want to do it, and present that very value proposition on that landing page. Tell the story in such a way that every Smith who glances at our site will take a look at it. Because remember, now they're mostly scanning pages, they're not reading them in depth, they're not wincing, because they're just inundated with a cloud, a water, a waterfall of information. They are inundated.

‍

Well, they won't have time to analyze a random page they come across or an ad they saw. So here we have to reach our customers very precisely with a very precise message about what we want to do, how, etc.

‍

Well, and if we already build such a landing page, of course, with all the information about what we want to do, how to do it and how much it will cost, well, the landing page alone is a bit too little, well, because someone will read the idea and like it. Well, but how will we find out about it de facto? This person should have some way of expressing a desire to use this solution of ours. To say hey, listen, your idea appeals to me. Once it's out there, I'd like to use it. Well, and here, of course, the simplest such solution would be to sign up for an email list, which will be placed this our landing page some call to action. If you like my idea, you would like to test it, because you see sense in it, you see it as a solution to your problem, then please sign up for this list. I'll keep you updated on what's going on with this product and let you know when it's ready for use.

‍

This way, not only can we not directly reach interested customers, but with this list we immediately build our customer base. This is what I was talking about at the very beginning, which is the ability to build an initial customer base.

‍

And this method is somewhat based on the Lean Startup methodology, but they will not talk about it in detail today. We will talk about it in a separate episode in the future, where we will simply analyze for ourselves how it works. We'll also talk about it in its entirety maybe with someone who is familiar with it. Much better. He is a practitioner of this methodology. So we already have our landing page, we have our list. All right, but then we already have these first components, so our users, our potential customers, will know what we're doing, how we want to do it, and in general they'll be able to say they want to use it. Well, but now the main question is how to reach them? And as I mentioned a little at the beginning, a little earlier I believe. In the age of the Internet or social media, if we are a person who has already built some social media, has some circles, we are a person who is known for building some solutions or is from the construction world in general, they talk, then you know it will be much easier to reach there audience.

‍

Well, because we're going to start messing around, we're going to start dressing up some kind of marketing strategy, where we can organically reach quite a large number of our potential customers.

‍

Well, because at this point they simply already know us, we have already done something for them before, or they associate us with certain solutions. But if we don't know anyone, we don't have social media, we are just entering this market with our first company, with our first product. We have never run social media in any way. Then how do we do it? Well, the idea that comes to mind here right away is to run advertising. And what does it mean to run advertising? Well, again, it's not such a simple topic that we can dress up in 5 minutes for sure, about which we can say hey, make an ad. End of story, period. It's going to work. You will have a business Super, extra. Thank you, goodbye. Advertising, first of all, will not necessarily be cheap. On advertising you need to know, you need to be able to put together this marketing somehow. If, of course, we can lay down some funds for advertising, for promoting our idea, for promoting our product, but in my opinion, if we have, let's say, the whole budget set up for building our company, building our idea or realizing our project, it's much better to lay down, though.

‍

And this also applies to large companies or companies that want to run something internally. It's much better to devote more resources in the first initial phase to vetting this idea, to promoting this idea, to juxtaposing this idea with the users, with the people who are de facto going to use our solution. Why? Well, because at this point we simply increase our chances of success. We are causing possibly our application, our solution to be simply that successful. And, of course, advertising could be talked about a lot, because as I mentioned earlier, this is not a topic for 5 minutes. On the other hand, it is certainly worth mentioning that we must try to make this our message in advertising or anywhere else as targeted as possible. Of course, let's imagine that we have a multitude of different users all over the Internet here. Our users are here, our users are here, our users are here. If we do a carpet raid on this whole area of these users, we will spend a great deal of resources, and de facto 90% of these resources will immediately be burned for nothing on users who are not our customers at all.

‍

Social media, Google in general and so on allow us to do very targeted messaging to people who realistically might be interested in our products. If we know marketing or have some support from someone who could help us with this great, let's do it. Let's verify our message. Let's make it as targeted as possible in order to reach those customers. Let's look for Facebook groups, let's look for forums, discussion boards, let's look for all kinds of things, all kinds of sources where our users might be. We will reach them with the message. If we've done that, that brings up the next point that we should do at our stage at our stage of validating the idea, which is what is our de facto goal before we start building our product, when should we de facto start doing that? Well, let's say we establish that, for example, if 100 people sign up to our list, express a desire to use our application, our solution in some way, then at that point we know that, for example, it's worth starting to build the solution.

‍

And of course, this is some very simple overall goal. I think it's better to pacify it a little bit and also dress it up in some kind of smart framework, that is, to make it quantifiable, to dress it up in some kind of dates, in some kind of indicators that will realistically tell us ok, I've reached this milestone.

‍

Now it makes sense to start building my solution. Now it makes sense because I already have these potential users. Now I already have some information, I know what they need, I've talked to them, so I have some goal that I'm starting to build my solution towards. Well, and now yes building a solution. As I said, having all this big budget, let's say for simplicity we have 100 thousand to implement a certain project. And here we are already talking about the approach of companies that already exist in the market, that just want to. To implement something. Do they want to come out with something new or do they want to give something implementation in their organization? We have a certain set budget for implementation. Then what kind of budget? What part of that budget should we put into verification and what part should we put into implementation? How do we do that? How do we reconcile all this with each other? This is a very good question with no easy answer. And what does it mean de facto?

‍

Because I know it sounds a bit like an unanswered answer. De facto, what we will put more emphasis on, of course, is the verification of our idea, the verification of our idea, the realization, the realization, the verification, Of course, not the realization of the idea itself.

‍

Well, that will potentially increase our chances of success. But is that a reason to buckle down and do it indefinitely? Totally no. We should gather the first some feedback, the first some information about what our users have a problem with, what the problem is to be solved, Ask them for some preliminary, collect some data, based on which we will be able to build the first prototype. And this is where the Lean Startup methodology comes into play. This is where the biggest slice of it comes in, which is just building, researching and steering. If we have already done some preliminary research on our idea, our concept, we know how we more or less want to solve the problem. Do we have an idea for it? Let's build the first prototype and is it worth focusing on technology, on servers, on performance, etc. at this stage. At this stage we should prove that in general our solution makes sense. And of course we should make sure that if we are already building, let's build it according to the art.

‍

Let's not build it in a shoddy way, on the spur of the moment, so that we have to build it from scratch later.

‍

Let's build it according to some art, just so it has arms and legs. But let's not play around with wrapping it in pretty bows. Let's not play around with making it on super technologies. So that it's creating and whether we do server Waves on testing or googling or something, it doesn't matter totally at this point. Let's choose a technology that allows us to build this quickly, that we feel fluent in, and I'm not going to urge scientific, although it's great for this type of approach. Let's build the first prototype of the solution that we can release to our customers. I'm sure I've heard the saying that if I've released a product that your customers like, it means I just released it too late. The first product doesn't have to be beautiful, it doesn't have to be super efficient. Of course, performance affects user retention, so it's worth taking care of it however you can, but it's not crucial. What is crucial is whether the solution we have built will give us further answers to further questions.

‍

Because at the point where we've done this first survey, we'll build this first prototype that answers the very needs that I've inferred from this approach, from this survey.

‍

It is at this point that we collect more data, we talk to our users, they know that we have informed them, that we are in contact with them. Listen, this is the first approach, This is a prototype that solves your problem to some extent. Tell me what is good, what is bad, what is not working, what is missing? And I will put it on the list, I will build it one by one, I will do it slowly and those. I will build it together with you, responding to your needs. Not only that, it will give us trusted, loyal customers who will see that hey, this guy is responding to my needs. He's talking to me, he's asking what I need, it builds great relationships, it builds great loyalty among our users, but it also gives us the best scientific data we can collect on what we should do next. And then, of course, here we get into the next point, which is testing, piloting. By testing the beer, making changes, adding them, removing certain things, optimizing our whole solution we enter the development phase, where this whole solution of ours will be developmental.

‍

Customers will start recommending us, we'll be able to come out with a more accurate message, we'll be able to go in with some pricing, go out to more user groups, and so on and so forth, because our solution will start to have some momentum, it will start to function, it will start to respond realistically to users' needs, and at that point we can already start taking care of the nice packaging. About thinking about what kind of technology we need. Besides, when we reach a certain ceiling, we will also already be able to afford, for example, to rebuild the solution. Provided that it will be completely necessary. It won't always be necessary, because we will also be building the solution then. Not with what we thought. We, at that point, will already know what exactly we de facto need and what de facto is needed by our users and what technology will answer these needs perfectly. So as you can see, it's not a complicated process. At least it doesn't sound complicated.

‍

On the other hand, it certainly requires patience. It requires a lot of commitment on your part. And that is very often the problem, whether in companies or start-ups, that everyone these days would like everything.

‍

Very fast. Unfortunately, haste is the worst advisor in this case, and very often causes that unfortunately but contributes to our failure, and not to our success in business, as well as in applications in software that we need patience. We need time to collect data, to study something, to find out what our users de facto need and what de facto is needed in the total solutions. So as we've already discussed how this process of totality can look like. Then why do I think failure is the key to success? And I'm not talking that kind of you know, old-fashioned failure that will put us completely out of business, where we overdelivered all our money and everything went to hell. And unfortunately, it didn't work out for us. These things will happen too. We have to be ready for it, because not everything we do will work out for us. Anyway, as I say statistics. Our main task is to cheat the statistics. That is, so that not 9 out of 10 startups fail, so that not 45% of projects fail, but that, for example, 40%, so that 80% of startups only fail.

‍

That's how we're able, that's how we're going to verify these ideas of ours and plan them.

‍

This is also very important. Just this budget, where we put emphasis on what, then we will be able to cheat this statistic a little bit. What kind of failures am I talking about? I'm talking about minor failures. Remember, if you build a solution, the first version of it may be a total failure, but again, it will give you a lot of answers. And again, if you put only, say, 20% of the budget to verify the idea 20 to make the first version, it turned out to be a flop, that users didn't want it. It is at this point that you are much richer in knowledge, real knowledge of what those users who want to use this solution, who still have this problem to pronounce it, need? Okay, look, this is what failed, but now I still have the budget, we can implement this idea and you will do this idea. In the end it may work, So we have to steer, we have to, we have to try and collect this data from our users to de facto find out what has value, because by doing so we will be able to build a better solution just to cheat this whole statistic.

‍

It can also turn out very often that if we put too much emphasis or take too long to do the verification itself, we have collected, collected, collected, collected.

‍

But once we've built, the environment has changed or some new technology has come in that has solved part of the problem, and what we've built no longer meets the exact needs of our users, so we also have to remember to properly balance, balance this study over time as well, so that it doesn't take too long again. Because, as I say, if something takes too long, it may turn out that a lot of the conditions around business, environmental conditions have changed, and unfortunately it will no longer be right. Therefore, at this point we should properly balance fast, accurate and collection. It is these three values that we should properly balance for ourselves. We can't do something very slowly, and we can't do something very quickly, because if we do something very quickly, collect all the data in a week or two, then de facto we won't collect all the data, because we don't know if we will get the right users or the wrong users. That's why it's so important to plan, to think about ok, what period of time do I think will not affect my environment too much?

‍

How much of this data do I need to collect so that it has real value, that is, so that it's not two or five users, because that may not be enough of the environment, in some it will be enough, but we just need to think about all these indicators, how much do we need, which will be real, How do we balance this against time?

‍

To see how we are able to put a budget, for example, for advertising, or how much time we are able to spend promoting our solution organically, just to collect all this data, analyze it, draw conclusions, build our solution, send it to users. How much time will we give them to test, to collect some more data again? What will it be like? What will it even look like to interview our users on which we will collect more data? How much de facto time does the development itself take? Or the planning of all that we are going to introduce? How will it work? These are very important questions that we always need to find answers to and that we will also de facto go much deeper into. In the next episodes of our podcast, where we will already talk about very specific methods of examining just what value. We are supposed to deliver to users and this de facto delivers that value to them. We will be talking about exactly how such a process should go, exactly how it goes with specific examples.

‍

Finally, I would like to talk a little about the readings that can help us. Which, by the way, I have also already mentioned, such as.

‍

Just Lean Startup methodology by Eric Reiss. It's a great read that helps us, helps us understand how we can set up just such a process in a scientific way, let's say a scientific way, so that it responds realistically to those needs, to just increase our chances of success. This is a great read, one of the better ones for sure. A very scientific approach, but understandable also to the layman. Another reading is this problem. This is a great read that talks about it with vivid examples of just apps like Uber, Tinder. How to build apps that have two sides, that is, they have demand, supply, that have to face precisely that, like Uber, for example, that if there are not enough drivers, users will abandon our app. On the other hand, if there are too few people who order cabs, well, we won't have a supply of drivers in our app, which is how to solve this kind of demand-supply problem. If we have a two-sided marketplace, e.

‍

g. our app is a two-sided marketplace, how do we plan just the input of these two parties into our app so that it works properly?

‍

A great read that can help us. Another reading that I highly recommend is a reading just on the BCM methodology, or Business Canvas Model, which is how we should in general dissect our ideas for ourselves, see where exactly our value is, what is our competitive advantage against the company, what does our competition offer, what differentiates us, How do we even build just this idea for our, for our business? Where can we do it? How can we do that? You'll find links to all those books I mention in the description of this video, so it will be easier for you. The ones to track down. One of such books like this around, maybe not the construction itself, not even just applications or this kind of solutions, but for people who want to build their first business too, is the book The Myth of Entrepreneurship, which is about how we should plan our enterprise at all, because any enterprise can be planned in any way initially. Of course, it won't always go in accordance later on, because this environment changes very dynamically all the time, but it will help us to arrange this whole process of building a company in our heads at all.

‍

Not just building the product itself or some solution, but building the whole company around it. So I think these are the kind of four readings that can realistically help us build this whole business, whether it's just internally or externally. If we just want to go to market with some product. So in today's episode, that's it from me. I hope it was helpful to you. We just discussed why idea verification is as important as it is. How it can be done in a simple way, how we can approach it in such an organic way, spending as little budget as possible, focusing more on just the value on exploring what we want to do, building it at the lowest possible cost. And we discussed a little bit how they can, what kind of reading can help us do that. So as I said, I hope you found today's episode helpful. In the next ones we will go deeper into this topic. That's it from me for today. Thanks, hope to hear from you again.

‍