How to build your first application right?

There are many questions you should ask yourself before building a software product like a mobile app. How to choose a supplier and the best offer? How to estimate a budget? How to find real users’ problems? There are also some mistakes you can certainly avoid, having that knowledge. Build it right from the beginning!

So let’s see how many mistakes you can make and how to avoid them and not be lost in the whole app development process during building your first version of a software product.

You start developing your product too quickly

This is one of the most common mistakes. You build a picture in your head of how your new software product should look and work. And 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 your software 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 that process.

When is the right time for product development? Speaking from my experience, this is when the tools, methods, and frameworks available as parts of product discovery have been used, and you have obtained hard analytical data indicating that there is a high probability that your new software product will be the right one. You know what the first version of a digital product should look like, 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 functionalities = greater choice?

This hypothesis says that more functionalities in a product mean greater choice for users and a bigger probability that they’ll like one or more of the functions and they would like to use your product. Usually, this hypothesis does not work. You have to remember that you should be more like a sniper than a carpet bomber with your new product. The technique of diversity sometimes works in large corporations that have a market, then adding another functionality will suddenly cause another increase in sales. But this situation does not apply to you.

More functionalities in a new software product also mean higher development, product testing, sales, and marketing costs. You are weakening your power of action when you are attacking a more extensive market where you are unknown. 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 “different strokes for different folks” because it doesn’t work for a new software product development.

You start targeting the primary market instead of early adopters

Do you think that maybe half the world will start using your product and 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 ordinary people find out about it.

Geoffrey A. Moore described this problem correctly in his book “Crossing the Chasm”. The path you will have to go through with your product is shown in the chart below. At first, focus only on people who will benefit the most from using your product – even if the product is imperfect. We call these people 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 on 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 real users’ problems/challenges

It often happens that the application that is being built solves problems that do not exist, or there are cheaper / better / more straightforward solutions available. So what if a stunning digital product will be made, excellent working when nobody needs it at all?

Investigate whether the problems you want to solve exist and whether they relate to the target group you chose. Check what alternatives do users have, and how 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:

people who have been providing beauty services for five or more years
providers starting in the industry, usually working for no more than 1,5-2 years.

It turned out that experienced people needed a tool to help them automate the process of arranging visits – they had a lot of clients, and each missed visit was a measurable financial loss for them. People from the second target group providing similar services had a completely different problem: they’d just started building their market. The most valuable thing for them was generating more visits for them each month through the platform (something that was “nice to have” for the first group). As you can see, people doing 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?

This is a fundamental question especially if you are developing b2b digital products. You should precisely understand the marketing and sales processes, service performance processes, and upselling for the users for whom you are creating the solution. Remember that your software 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 probably lengthen your users’ path to start using your product successfully. If your digital product requires substantial changes to customer processes – the probability of success will decrease even more. Remember that people don’t like changes and they do a lot to defend themselves against them.

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 that 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.

Two quotes:

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 proposing (suggesting) solutions. However, the solutions must be tested with users before they go to development.

The known techniques for testing include the following:

product mock-ups
high-quality digital product designs
prototypes that pretend to be working software 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-creating the solution. You have to be careful not to create something that will be a solution for one user only – you will be unable to scale it.

So how to do it right?

First of all, make sure that everything above is done before you start thinking about developing the first version of your product. Secondly, use the advice below:

A business goal above everything else

I always tell all my colleagues that we do not create applications, or IT solutions for their functionalities. We build them to help users solve their problems and enable our clients to 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 created 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” when 100 users 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. Leaware team suggested that instead of spending money on complicated onboarding in a mobile application, a simple web form without unnecessary bells and whistles should be created. It will allow the client’s employees to do the same. Ultimately, each employee was 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 your goal and understand it well.

What business goals will be reasonable for a new digital product? For me, it works best to imagine that we have a software 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 and the next versions? What are you going to do with the product in the next 2-3 weeks? Remember that 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 product, and giving it 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. 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 was about 50-70 thousand EUR. 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. 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. We agreed that we would come back to the topic if it turns out that these four clients would manage to refine the concept of costing mechanisms, which would start to be scalable and justify development work.

Functionalities that you include in the first version of your software product

As you already know what goal you want to achieve, and how you want to measure its implementation, go to the functionalities that must be included in the product to make it possible. 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 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 software 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

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’ applications. However, you cannot afford to have bugs in the product that will deter early adopters – or worse, prevent them from taking advantage of your software 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 your software 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 software product so that you can refine the product before a wider group of users see it. Moreover, refining a software product should be done more by bringing the functionalities to perfection, not by adding new ones. You have to be very careful with this – any new functionality hurts your product and may be more of a threat than an opportunity.

So what budget do I need?

A too-small budget will prevent you from creating a solution that will generate value for your users. 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 EUR. I have also not come across a project with a budget of fewer than 7,000 EUR. I believe that a budget above 15,000 EUR is already a large budget for the first version of the product, and if anyone offers you a much larger account, you should at least be alert.

Starting a software development

Before the development of your software product begins, it must be adequately prepared for it. There are many questions that you should 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 my software product 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 do versioning of software products?
Are there any holes, areas, screens, or flows in the product that are not defined enough?
With what tools 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 well?
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 creating a code that 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 PRODUCT OWNER or maybe someone else? How long will the sprints be, and how many are we anticipating?

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, tips, and information about errors from them. 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 software 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.

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, and 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 how is its quality. If you will expand your software 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 functionalities.

Summary

One of the biggest mistakes I saw in new software product development initiatives was entering the broad market with version 1.0. This usually resulted in many consequences in the form of a large number of functionalities – 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.

As always, the old rule was that it is not the idea that matters, but the execution.

In the end, I am sharing with you a free checklist that will help you check what budget you need to build your first application!