Today we are publishing an article from Alexey Stoletny, who would like to share his knowledge and expertise with the Øresund Startup News community when it comes to startups’ common mistakes and how they could be avoided.
Alexey has more than 10 years of experience working with startups in Europe and North America. Currently he is employed as CTO at Clean.io, as well as Managing Director at Sigma Software Inc. in the USA.
This article will be of interest not only to those who are only launching their projects, but also to those who are working with startups.
Read Alexey’s tips below:
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 market research
- to build new relationships
In fact, your most critical task at the very beginning is to test your business idea for viability and check whether it’s working or not.
Here is an example.
Suppose, you’ve decided to start a window-selling company. What are you going to do first? Probably, you’ll 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.
What you need is a 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.
Don’t overload your product
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.
Search for clients and monetization model from the start
Another common misconception is that “Signing contracts is reasonable only when the product is fully ready to use”. It’s 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’s 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’s 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. The optimization will improve your product, if you take a balanced approach. But you don’t often see this.
Determine key success factors
No one monitors or analyzes whether your product 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? 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.
About team motivation
If your team is motivated and feels responsible for the product they are developing, it’s evident that each of them will want to improve something, whether in the processes, approaches, the code, etc.
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.
***
Thank you, Alexey, for sharing your tips!
