How much should you invest in creating a new application?
You often find out that something is wrong when you receive very different answers to your inquiry about your new application's valuation. One valuation is up to five times greater than another. Are you starting to ask yourself what criteria should be followed when choosing a supplier? Maybe reject those who are the cheapest, most expensive, and pick someone in the middle?
The next question you ask yourself is, is this any selection criterion? It probably isn't, and you know it well. What to do? How to avoid this type of problem?
If you find yourself in this situation, it means that you most likely made one or more mistakes in preparing your digital product for development. I invite you to read it.
Typical mistakes made when creating the first version of a digital product
You start developing your product too quickly.
This is one of the most common mistakes. It consists of building a picture in your head of how your new product should look and work. You think the only way to find out how your digital product will perform is to make an initial version of it and make it available to users. Fortunately, this is not the only approach. Moreover, there are many ways to verify hypotheses (your ideas) before development starts.
There is a whole concept of product development that describes these methods; it is called product discovery. In the following paragraphs, I will refer to some of the product discovery techniques used in product discovery.
When is the right time for product development? In my experience, this is when the tools, methods, frameworks available as part of product discovery have been used, and you have obtained hard analytical data that indicates that there is a high probability that your new digital product will be the right one. You know what the first version of a digital product should be; you have access to users interested in it, ideally if they want to pay for the opportunity to use it. Later in the article, I will tell you more about the methods and techniques mentioned above.
More functionality - more choice
It is an approach in which a hypothesis is built from the very beginning that more functionality in a product means more choice for users, and thus a greater probability that one of the functions they will like and will want. Use your product. Usually, this hypothesis does not hold. You have to remember that you are more of a sniper than a carpet bomb pilot with your new product. The technique of diversity sometimes works in large corporations that have a market, and adding another functionality will suddenly cause another increase in sales, etc. Unfortunately, this situation does not apply to you.
More functionalities in a new product also mean higher development costs, product testing, sales, and marketing costs. You are weakening your power of action - you are attacking a more extensive market where you are usually unknown to anyone. Your power of influence is much smaller than an exact definition of the market and the target group, which will be willing to use some advanced functionalities. Try to avoid the approach something cool for everyone - it doesn't work for new product development
We are targeting the primary market instead of early adopters.
Do you think half the world will start using your product - that everyone is waiting for it? Error! Even if you will deliver something groundbreaking to the market, be aware that it will be a long, long time before the average blacksmith finds out about it.
Geoffrey A. Moore described this problem correctly in the book Crossing the Chasm
The path you will have to go through with your product is shown in this chart.
At first, focus only on people who will benefit the most from using your product - even if it is imperfect.
We call them early adopters. They must be in one target group - which we call the beachhead market.
Here is the definition of a beachhead market:
All customers in the market buy similar products.
Customers in the marketplace follow a similar sales cycle and expect digital products to be of equal value.
Oral communication exists between customers in the marketplace. For example, existing customers serve as a valuable benchmark for potential customers. They may belong to the same professional organizations or operate in the same region.
Lack of knowledge of user problems/challenges
It often happens that the application being built solves problems that do not exist, or there are cheaper / better / more straightforward solutions available. You create something unique just because nobody needs it. Beautiful :) So what if a stunning digital product will be made, excellent working, that nobody needs for anything?
Investigate whether the problems you want to solve exist for real and whether they relate to the target group you are targeting. Check what alternatives users have, how do they currently solve the problems you want to address in your product?
One of my clients worked on an application for the beauty industry. It turned out that his clients could be divided into two target groups.
The first of these were people who have been providing beauty services for five or more years.
The second target group started in the industry - they usually worked for no more than one and a half to two years. It turned out that experienced people needed a tool to help automate the process of arranging a meeting - they had a lot of clients, and each missed visit was a measurable financial loss for them.
People from the second target group who provided similar services had a completely different problem: they started and built their market. For them, the most valuable thing was that the client's platform generated more meetings for them each month. Something for the first group was "nice to have." As you can see, people who did the same thing (beauty services) had completely different problems and challenges. Moreover, there were many more starters than those on the market for over five years. Simple choice - the client should focus on the market of people who have just started their adventure with beauty services.
How do your user's processes work?
A fundamental question in particular if you are developing b2b digital products. It would help if you precisely understood the marketing and sales processes, service performance processes, and upselling for the users for whom you are creating the solution. Remember that your digital product will impact the process, tools, and people who need to control it all. Once you understand how it works today, it will be easier for you to put your solution into the process to benefit your users and their customers as much as possible. If you don't, you will likely lengthen your users' path to walk to start using your product successfully. Thus, you increase the likelihood that for some reason, they will not want to go through it, and therefore you will be less successful.
If your digital product requires substantial changes to customer processes - the probability of success will decrease even more. Remember that people don't like change, and they do a lot to defend themselves against it.
To describe processes and services, methods such as customer journey mapping or describing functions using the BPMN language are instrumental. Read about them - it's worth it!
Is my solution what users need?
This question concerns the part of product design, which we call solution discovery. While users are very eager to tell you what they have problems with, asking them how they would like to solve the problem and what they need usually fails.
If at the beginning of my career as an entrepreneur, I asked my clients what they wanted, everyone would agree: we want faster horses. So I didn't ask them.
Steve Jobs said:
People don't know what they want until you show them.
You need to separate talking to users about their problems from the proposed solutions. However, the solutions must be tested with users before they go to development.
The known techniques for testing include the following:
high-quality digital product designs
prototypes that pretend to be working digital products
programmed pieces of functionality, the task of which is only to test a given functionality - after testing, this code is not used in creating the final solution
All that I wrote does not mean that users cannot be invited to co-create the solution - you have to be careful not to create something that will be a solution for one user only - then it is unlikely to be scalable.
Well ... how to do it correctly?
First of all, make sure that everything above is done before you start thinking about developing your product's first version. Secondly, use the advice I write about below.
A business goal above all else
I always tell all my colleagues that we do not create applications, IT solutions for functionality. We make them so that users solve their problems and our clients achieve their business goals.
The business goal should be what is clear and understandable to everyone involved in software development.
One situation from the past. We create an application for a particular startup. The client came up with a proposal to create a very complicated onboarding system consisting of eight steps. After lengthy discussions, it turned out that the implementation would be cumbersome and take a lot of time. In the meantime, it has become clear that the business goals for the product are to make the platform live. We started asking the client what does it mean that the platform is alive? After reflection, we decided to consider the forum "alive" once 100 clients are onboarded. For his part, the investor declared that he would be willing to launch another tranche of the investment. The client had a team of two people who worked full time as customer success managers. The Leaware team suggested that instead of spending money on complicated onboarding in a mobile application, a simple web form should be created - without unnecessary bells and whistles, which will allow the client's employees to do the same. Ultimately, each employee onboarding an average of seven clients each day. After less than two weeks, the next investment tranche was launched ... If we had followed the path of onboarding development in a mobile application, the process would take about two months. What's the conclusion? Each business goal can be achieved in several ways. The development team will also tell you how to achieve it - they often have an experience that you do not have, but there is one requirement - they must know this goal and understand it well.
What business goals will be reasonable goals for a new digital product? For me, it works best to imagine that we have a digital product that has been officially released to your customers. What are you doing now? What do you want to achieve? When will you know that it is worth working on its development, on the next versions? What are you going to do with the product in the next 2-3 weeks? Remember that using common sense, you target early adopters - users who are the first to use your product. What you'll probably do is start working with them, showing them your digital product, giving them to them for testing. You will begin collecting their feedback, requests for changes, and functionality improvements that have been developed. Your goal will be to make sure you are going in the right direction - to see that early adopters want to work with it. Their feedback will be precious, and you have to be careful that it does not turn into a wish concert - so that you do not go in the direction of developing an application that will suit the three early adopters and no one else. Perhaps the business goal will be similar to the example I showed? Is it to convince the investor to invest another tranche of money? Whatever it is - you need to be prepared for the next steps, improvements, and further development of your product. Growth never ends after the first version of a product is released to the market.
When do we know that we are getting closer to our goal?
A goal is a goal, but it's also worth knowing when you are approaching it. You should make sure the measures are clear and understandable to all. There are many techniques for determining standards for goals. My favorite is the so-called OKRs. You can read more about them [here] (https://www.leaware.com/post/how-to-combine-okr-methodology-with-a-scrum). In the example above, the plan that is usually defined in an uncountable way was to "make the platform live" - our objective. However, the measure (key result) was the number of users who underwent onboarding - very countable - 100 people. Thanks to this approach, the whole team knows how direction the boat is to go so that the project reaches the shore. As you may have noticed - we are not telling the group "how" to achieve the goal - it is essential that the team can take responsibility for it. We only show when we can consider that the goal has been achieved.
Are you sure you need to build a product to achieve this goal?
Some time ago, we talked to a startup that decided to help people build their homes. The goal was to provide the know-how that would allow people to do most of the work independently without involving specialist companies. The startup asked us to make an application that would help generate a cost estimate. The budget is about 50-70 thousand euro. We started to define the business goal for the first version of the product. After a few talks, it turned out that they planned to make four such cost estimates next year to test their concept further and look for customers for it. Was it worth building any digital product at this point? There was a very high probability that after making these four cost estimates, based on users' feedback, working on the cost estimate will change.
We persuaded them to use an excel tool and add some automation to achieve a similar effect as when we wrote the software. It wasn't worth spending money at this point. We agreed that we would come back to the topic if it turned out that these four clients would manage to refine the concept of costing mechanisms, which would start to be scalable and justify development work.
Application functionalities that you include in the first version of the product
As you already know what goal you want to achieve, how you want to measure its implementation, go to the functionalities that must be included in the product to make it possible. Think of it this way that if you have too few of them, they won't generate value for your users - who needs an application that only works with login and registration? On the other hand, the functionality of calculating the amount of the insurance premium, without the registration and login process, will generate such a value. If you do not need to identify users at this stage, give up registration, and login and focus on the functionality of calculating the premium. Think this way to minimize the amount and complexity of functionality and maximize your users' value. All the time, remember that your solution will be used by early adopters who can compromise and understand why they did not get a product with multiple functionalities.
Think about how you will interact with your users. Will it be sessions where you sit down together and start using the product, or will they do it independently without your participation? This is important for something that virtually nobody does, and which is crucial - collecting data about how they use a digital product. Think about what data you should collect. Is it worth knowing that the early adopter uses the application every day? That it activates the functionalities that you have created that they use at work? To learn about these things, you must integrate your application with tools to measure it from the very beginning.
Errors, errors, errors.
This is another important topic. The first version of your digital product is likely to be buggy. It is even justified that it is not worth spending a lot of money on in-depth and comprehensive testing at the testing stage and using early adopters' application. However, you cannot afford to have bugs in the product that will deter early adopters - or worse, prevent them from taking advantage of the digital product. Therefore, it is worth connecting a tool that will report severe problems so that you and your development team know what needs to be improved.
Leave part of the budget for the next versions of the digital product.
I think you perfectly feel that the first version's release will only be the beginning of the journey. Therefore, you must save some of the budgets for the next versions of your digital product. So that you can refine the product before a wider group of users uses it. Moreover, refining a product should be done more by bringing the functionalities to perfection and not by adding new ones. You have to be very careful with this - any new functionality hurts your product and maybe more of a threat than an opportunity for it.
So what budget is needed?
A too-small budget will prevent you from creating a solution that will generate value for your users. Something will be created that they will not want/be able to use in their daily work.
If the budget is too large, it will quickly turn out that you can stuff into it many things that will not necessarily be important at this point and will not generate added value for your users.
From my experience - as a person involved in building products in Leaware, I know that the budget for the first version of a product rarely exceeds 15,000 euros. I have also not come across a project with a budget of fewer than 7,000 euros. I believe that a budget above 15,000 euros is already a large budget for the first version of the product, and if anyone offers you a much larger account than 15,000 euros, you should at least be alert.
We start development
Before the development of your digital product begins, it must be adequately prepared for it. There are many questions that you should know, answer before developers write the first line of code.
Some of them are:
What architecture will be used to create your application?
What technologies will developers use?
How will digital products be tested?
How will developers know that a given functionality of the product has been adequately made?
How will your product testing process be documented?
Will developers are versioning digital products?
Are there no "holes," areas, screens, flows in the product that are not well defined enough?
With what tool and measures will we measure how users use the product?
How will developers know about problems in the operation of the application?
Does the development team know about the business goals and understand them?
How will the next versions of the application be released for testing? Will the team test internally?
What ideas does the development team have for managing regression bugs?
Depending on the type of solution, there may be many more questions - remember that knowing the answers to them reduces the risk of code creation, which will have to be rewritten in six months.
It is essential to establish how the team will work on the product. If the SCRUM methodology is used, you should be interested in determining who will be in the role of SCRUM MASTER, will you be the OWNER PRODUCT, or maybe someone else? How long will the sprints be, how many are we anticipating?
We are releasing the first production version.
The day had come when the first production version was released. You can go to early adopters and ask them to use the application for the first time. You start collecting feedback from them, tips, and information about errors. Think about how and when the development team should start working on the next versions of your product. Should it be done immediately, or do you need 2-3 weeks to collect the right amount of feedback from users? This can be crucial for the cost of developing your product. Don't fall into the trap of developers waiting and having to do something while you're testing a digital product with early adopters. This can cause them to start working too quickly on things that are not well defined and increase the risk of developing functionalities that are not necessarily needed by your users. This is an important topic when you are working on a new product. The team needs to match what will happen with the product, not the other way around.
Next product versions
If you have enough positive signals - you can go ahead and invest in further product development. Calls are best expressed in terms of the goals you have achieved, the level of user satisfaction. Never act in the dark - even if you are convinced that you are building great applications - rely on facts - and facts are hard data from the market showing that you are on the right track.
Ensure your development team is adjusted to the size of the product and the amount of development work. At the same time, take care of collecting feedback on how the product works, how users use it, and it's quality. If you will expand your digital product with new functionalities, make sure to go through the full path of problem verification and solutions with users before the new functionality goes to the development team. It is essential to involve early adopters - so that they help you refine the product and its functionality. Eliminate working in the dark, based on hypotheses.
One of the biggest mistakes I saw in new digital product development initiatives was entering the broad market with version 1.0. This resulted in many consequences in the form of a large amount of functionality - to meet all potential users' requirements. A large development budget - so that you do not forget about anything and that the digital product has excellent quality. The reality most often quickly verified this approach, usually giving critical feedback from users. Fortunately, when the company could swallow a pill - it had a sufficient budget for the required changes. Worse, it turned out that the adventure with a new product - where problems were often correctly identified, there was a market, there was a demand to end before it started.
As always, the old rule was that it is not the idea that matters, but the execution.
If you have any questions, write to me or choose a convenient date for a short interview during which I will answer your questions: ➡️ https://calendly.com/tomasz-soroka/30min