This is not a technology presentation, it’s not aimed at technology people but at the business side, so it’s important to organize the information around business decisions that are related to how technology is used. For that reason I’ve tried to organize the mistakes that based on my experience I’ve seen working with the Corporations, startups, different types of companies and organize the mistakes into the business stages because they probably make more business sense that way.
This article is taken from an interview Prof. Dr. Sven Prüser conducted with me for the Friday Afternoon Chill-out series organized by UBE Academy on 22/01/2021, which you can see in full below.
The UBE Academy are experts in the field of management trainings. Not only do they master their own field of expertise, being it leadership, management, strategy, operations, sales and marketing, supply chain management and finance. But they also know how to utilize modern technologies in order to make also your business future proof.
Mistakes in the Validate Phase
This is probably the best time to go in and create the right solutions.
What happens with startups is that they usually look for help on the technology side: what is the best technology to use? what is the team that could help them with that? and they have a lot of enthusiasm as you were saying. They are thrilled with their idea, they have great feedback from their friends.
At a certain point they are so in love with their idea that the next inevitable step is to build the software solution that will support their business.
And this is the best time to think about what they are considering.
Building too much too soon
They’re going to invest a lot of time and a lot of money to launch this business idea and develop this platform and, as a technology provider, I think that’s great. But they should probably reconsider that and see if they can do a cheaper validation of what they are proposing.
That’s the best approach they should take before they go into the process of building an entire software system.
There are multiple ways to do this. Try not just to probe the market and see if there is an audience, but to validate if the price is right, if you can reach customers in a cost-effective way, if your numbers and estimates can be validated before you make all this investment.
Maybe you can try to use some kind of crowdfunding so that, before you start building something, you can get some validation that people are willing to show the money and pay for it, not just saying the idea is great.
My first recommendation to people is to have a clear vision before they dive into the process of building a software solution.
Mistakes in the Launch Stage for Statups
The special thing about start-ups is that they don’t have a lot of money in general, but they have a lot of enthusiasm and flexibility.
Outsourcing key software knowledge
The first mistake that is critical at this stage is to outsource key software knowledge.
And the key word here is “key”.
Not all start-ups are digital technology-based companies.
If they are producing shoes, that’s great. They will probably need some digital tools to buy, to produce, to sell, to run the administration. They might even need an e-commerce site to offer their product. But they can still do it through other channels. So, in this situation, software is not a critical element for the business.
But when it comes to building a platform where the value proposition is based on the existence of this software, then this part is business critical and if it is business critical you need to have knowledge of that key element in your core team. You probably also need an industry expert or a marketing expert if you are going to sell it. Perhaps administration is important but not critical.
But again, if software is key, it is important to have ownership of this system.
And this requires a CTO in your core team or at least with a long-term relationship with them.
The CTO doesn’t have to be the developer. Maybe you can outsource the development, you can outsource the project management or you can even outsource the architecture to a consultant. But someone who is in the core team of the new business should be in charge of the whole technical solution that is being built and be aware and in control of what is being created, so that if later on, they decide to change suppliers the CTO should be able to manage all this knowledge.
Develop monolithic solution
Another mistake I have seen is to develop a monolithic solution. That is, a solution that solves all the needs of the company.
Today there are a lot of tools that cover different parts of the business lifecycle. You can find administrative systems, you can find ticketing systems, you can find CRMs, CMSs, messaging systems and so on.
So, basically, you can try to build your software solution by integrating different tools that are on the market that solve certain specific needs.
What you have to develop are those specific components that nobody else offers.
And this is not just for the cost reason. It’s because those specific tools will probably be much more powerful than anything you can create, but also because they will encourage you to create a modular solution. So, if you reconsider some decisions in the future, it is much easier to replace a module with a new and improved version than to try to extract some of the functionality from an existing monolithic solution.
Oversized platform
Another typical mistake is to try to use an oversized platform. That means trying to choose a big tool that will scale with the business as the business grows.
The business right now is new and probably right now cost is important, and time to market is really important for you to start selling and start seeing your product in the market.
The big systems that can scale are probably expensive, but they also have a long learning curve. So this is something that at the moment can be a big disadvantage at the moment.
I recommend selecting the right tool for the short term. Later on you may be able to reconsider this decision and replace the components that are affecting your growth with more scalable solutions.
Using lock-in modules
Of course, all the components you are using to build your system must have some kind of integration, but you have to be careful that those solutions don’t have some kind of lock-in for you. That means that, if you have to replace them later on, you may lose a lot of information or a lot of time or a lot of value in the process.
You should be able to extract the information from the component with reasonable effort to move to a new system.
An example of this is if you are using a payment system, e.g. PayPal or Stripe. If you then decide to change one of those solutions and you have customers with automated recurring payments, you run the risk of having to renegotiate with them to get them to authorize the new system, and this, depending on the service you offer, may result in a loss of customers.
Mistakes in the Launch Stage for Established Businesses
Of course also bigger companies sometimes try to launch business solutions.
In this situation the situation is quite different. Probably the company already has financial resources, has products on the market and also has a history. And this history is probably creating some kind of limitation or constraint based on previous decisions.
Not running as a startup
My first recommendation is to try to avoid executing the new initiative in terms of already established products. As much as possible, try to run the new launch as if it were a start-up.
The process is more or less the same as we have seen above. Try to create a core team for this new product that controls the critical elements and activities of the business model canvas. Try to launch the new product with the minimum software solution needed based on the needs of a new, unvalidated product.
Running as a side project
Create a core team to lead this part of the process. Include those people who can take charge of the critical parts of the process. Such as the industry specialist, the marketer and the IT person, again if software is key. And make sure they will work full-time and focused on that project.
If the launch phase is run as a side project, there is a high risk that it will fail, even if the idea is a good one.
If they do not have specific people in charge of these key activities, but are diluted in departments that serve other parts of the organization, it is very likely that other priorities will take over and break any plans that may exist during the launch.
Not giving freedom
Another typical problem for organizations is that they tend to require the new initiative to use the common infrastructure and services used by the rest of the company. This means using services from other departments and globally used applications.
Usually, the two concepts go hand in hand: in order for that department to perform its function, it is essential to use this software because it is already integrated with what that department does.
The question here is whether these requirements will help or hinder the development of the new product.
Bear in mind that the new product has not yet been validated and there is a risk that it may not pass the test. Therefore, any effort to standardize its operation with that of the rest of the organization may be a futile effort.
That is why it is necessary, a priori, to leave freedom of decision on the global services to be used by the new initiative and to make a careful cost-benefit assessment to decide whether it is more convenient to use the global solution or whether it is better to try a new one.
Mistakes in the Growth Stage
At a certain point, if the new project or the new initiative that you are undertaking is proven and has passed the break-even point, you move to a new situation: it is an established product that has become part of the product portfolio of the organization.
Not removing silos
If you have followed the above recommendations, there is a serious risk that we are creating silos. Different parts of the business not communicating with each other.
This is the point at which I suggest trying to merge the software solution built for the new product with that of the rest of the organization.
On the one hand, it is important to achieve an economy of scale.
You don’t want to have 10 different solutions for 10 different products with 10 different vendors, with 10 different architectures, with 10 different expertise.
So it’s important to put them in one place. We don’t want that, if the data policy regulations change, we have to change them in 10 places. We don’t want that, if a technology becomes obsolete, we have to update it in 10 different places. So it is important to do a standardization process, trying to integrate everything into one architecture.
Not questioning architecture
A second problem is the decisions we made at the beginning under the pressure of speed and uncertainty. Now is the time to question them and see if they are able to scale with the business with reasonable cost and effort.
So maybe it is time to replace the simple accounting system with an SAP solution.
Because at this point in time it is justified to make that investment of time and money in a product that we know is going to be in our portfolio for a long time.
So now is the time to review each of the components used (in this non-monolithic solution, remember, otherwise it would be much more complicated) and assess whether it is worthwhile to continue with the initial solution or to look for a new one.
This is true even if it is not a component that has its equivalent in the global architecture of the organization.
Not taking advantage of learnings
There is also another possibility to consider. It is possible that the components that have been used during the launch have some advantage over those that the organization has traditionally used. In this case, you need to be able to learn from that experience, and it may be time to see if any of those new components can actually be an improvement for the rest of the organization.
Perhaps the new component is faster, has better integration, new functionality or lower cost.
The launch phase has served to test them in a real environment and it may now be time to export them to the rest of the organization.
Conclusion
The concept is that when you are going to launch something, first decide what is fundamental and make sure that the company is focused on getting those activities under control, try to create a modular system, trying to use the simplest solution you can find at any given time, especially during the early stages, and then apply a standardization process to take advantage of what you have learned and eliminate silos and achieve an economy of scale.
This is a recommendation based on my experiences. It need not always be the best strategy, but it is at least worth considering these criteria and decisions when building software solutions.
The important thing should always be that the solutions developed serve the business and fit its needs. Long-term criteria should be questioned when the project is young and not yet mature enough to have a minimum of guarantees that it will be able to reach that long-term life.