On Motivation, Optimization, and Common Errors with Startups

Alexey, what are the most common pitfalls for startups?

Quite often, when we start working with a new startup, I ask a question: what is, in your opinion, the most important thing for your project in the first weeks and months? I get very different answers: to attract clients, to come up with cool new features, to do a market research, to build new relationships, and many others. But in fact, your most critical task at the very beginning is to test your business idea for viability and check whether it is working or not.

Here is a simple example. Suppose, you’ve decided to start a window-selling company. What are you going to do first? Probably, you will think about how your windows will be different from the competitors, decide on the materials and colors, order handles that fit your fingers – that is, you will spend a whole year and all your resources on it. All this just to discover that nobody is going to buy your windows because the materials you chose get cracked in the wind anywhere higher than the tenth floor.

So what should you do?

Proof of concept. Using a minimal set of features and spending a minimal share of your resources on it. You have to continually crash-test your project to detect problems, which can fail your product at the very beginning. Going back to the windows – instead of wasting time and money on choosing colors, handles and other stuff, you should test how one material you have chosen behaves in various conditions. If it gets cracks, you need another one. You test another one, and it proves too costly? Test more, and keep testing until you find the ideal option, which will allow you to work further.

Your business model has to work in reality, not in your imagination. To understand this, you shouldn’t overload your product with extra features. Opt for the minimum. But when you choose, do it wisely. One common mistake of startups is choosing wrong or unnecessary features for the first stage. Your functionality, however minimal, has to provide the full cycle already at the initial stage. If you have made windows, but failed to consider glass panes, you will not test whether your business model is viable. It will not work just because it lacks essential parts.

This idea is best represented in the Minimum Viable Product diagram. You have to consider all layers rather than focus on just one of them.

Another common misconception is that “Signing contracts is reasonable only when the product is fully ready to use”. It is wrong. You should look for clients and sell them your product right from the start. Sure, in the beginning its price will be far lower than what you were planning – just because your solution is not quite ready yet. However, it will give you a chance to test your idea in real-life conditions, get some customer feedback and, finally, get some money to invest in refining your product.

By the way, it’s best not to linger with monetization either. You can often hear, “We’ll launch the application for free, win some target audience, and then start charging for it.” It is a mistake. Trust me, the users who have received your product for free will not want to pay for it later on. Some other users will have installed your application exactly because it was free. It is important to monetize from the very beginning – maybe, at a lower price.

One more thing – don’t overdo with improvement and optimization – this advice is both for those who own a startup and those who work with one.

Looking for a technological partner to help implement your idea into a software product?

Read how we work with startups

Won’t optimization improve the product and make the software development faster and less costly?

It will, if you take a balanced approach. But you don’t often see this.

If your team is motivated and feels responsible for the product they are developing, it is evident that each of them will want to improve something, whether in the processes, approaches, the code, etc. But no one monitors or analyzes whether this will really do good, or it will about those ‘good intentions’. Will the refactoring suggested by a developer really be a benefit, or only a setback?

How can you control this? First, you have to do research to determine what factors will be important for the business, which improvements will really enable a faster development and which will not, to draw some metrics and define the KPIs. The latter have to bring value to the product and to the business. Improvements like “We used to have 100 lines of code, and now only 90” will not do. Your actions have to cut costs, reduce time, or help to sell the product – only in this case they are worth spending time, money and energy.

You said “if your team is motivated.” What can be done if they are not? And why does this happen? Startups are believed to be the most interesting projects, aren’t they?

Team motivation doesn’t depend on the project but rather on how the work process is built. Quite often, you get to observe situations where the team members don’t know the concept and don’t understand the specifics of the future product, who it is for and what problems it will help to solve. To fill in this gap, all team members make their own assumptions, which can be very far from the truth. Lack of communication between the business and the team leads exactly to this problem. Sometimes you see how developers are intentionally ‘shut out’ from the customer, where they can only communicate with the project manager. This style of work will inevitably lead to some information loss. The team will not feel involved or committed to the project, they will not understand why certain decisions are made, they will not take pride in the work done – as a result, the team will be demotivated.

Whether you are a startup founder, a product owner, a project manager, or a developer – you are to be interested in establishing continuous effective communication with one another 🙂

• #Software Product Development