Mistakes that kill your cooperation with software development company

Business owners nowadays spent a lot of time making a selection of the perfect custom software development company. The one, that will carry on product development without much of a hassle at a reasonable cost and time. It’s a good thing. After all, their professionalism and efficiency have a great impact on the future of a product.

However, in reality, having even the best technological partner on your side does not guarantee success. Software development is way more complicated than writing code. It’s all about the people and interactions, not the tools and processes. Quoting a friend of mine “You don’t need to have a great team to build amazing products. It’s the team spirit, engagement, tight collaboration and mutual respect that makes the biggest difference.” The world is full of beautifully designed and built products that never reached adoption.

So, let’s look at the most costly mistakes made by business owners during product development. Hopefully, that will give you some sense of the way in which you can work with a custom software development company.

Underestimation of the product ownership.

Too often software development outsourcing is associated with just having a few developers writing code in the other location. Roles such as Product Owner or Quality Assurance are either neglected due to rigorous financial policies or simply forgotten until it’s too late.

In practice, however, it’s the product ownership which brings the biggest savings. Consider this simple example.

The team comes to you to inform you that integration with an external payment provider will take two months. The biggest obstacle comes from the fact that having a fully automated withdrawals policy is extremely hard. 3rd party provider uses a legacy, unstable API with dozens of corner cases. Unfortunately, that’s the crucial part of your system and you can’t go live without it. What do you do?

Well, it turns out you have plenty of options:

• Shout at developers and tell them to find a better solution.
• Accept the inevitable and deal with the consequences.
• Switch 3rd party payment providers and hope for the best.
• Ignore the problem and cry silently.
• Hope they were wrong.
• Look for the other, business-acceptable solution.

Smart Product Owner would go with the last option. One possibility is to implement a semi-automated solution which schedules withdrawals in an automated way but uses operations to review and accept on a periodical basis. After all, the product is not alive yet and you don’t have customers.

It takes experience and time to answer such questions. Having amazing developers onboard and weak product ownership is a pure waste of time and money. A custom software development company will happily take ownership in such cases if you just give them a bit of freedom.

Not having time for the team.

You are the young, ambitious founder of the next unicorn. Nothing stands between you and the wast majority of people waiting for it to be launched except… not having a product. Right? Product.

Truth is that no one knows it better than you. After all, it’s you who spent hundreds of hours thinking about it, playing different scenarios in your head and talking with customers. You did all the hard work to raise funds and explore your personal network in search of the first employees. Who can be better for the job of Product Owner if not you?

The answer is, no one. But do you really have time for it?

Let’s consider this simple example. The team is in the middle of a sprint adding the first features to the web-based version of the platform. In the meantime, you did an amazing sales pitch at the conference. Many people approached you asking for the mobile version of the app. Literally, no one even considered the web. It’s obvious that you need to do it sooner than later.

Unfortunately, you have four weeks of conferences, interviews and meetings with investors scheduled. On one side, you can ignore potential customers and continue with the web. Maybe they will use a responsive version, you say. On the other side, your internal voice tells you that you should make a pivot but that’s a lot of re-planning and coordination.

Wouldn’t be great to have a Proxy Product Owner? Someone who can do all of the work and coordinate with a custom software development company, someone who you really trust.

I saw this pattern hundreds of times. Sooner or later there will be a situation that can be addressed only by a full-time Product Owner. Successful start-up founders never have time for proper product ownership. They get dragged into various discussions and activities. The cost of delay can quickly exceed savings that came from not having a Proxy-Product Owner.

Refusal to confront the facts.

More than 10 years in the software development industry thought me one thing. In 9/10 cases there is more work to be done than people involved in the project. Moreover, teams get overly ambitious plans from product owners long before the work begins. All in all, since sprint one software developers are in a rush, even a single week of unplanned absence can make a difference. Not to mention a lack of time for innovation or research. The effect is easy to predict – overdue projects, unhappy developers and angry customers.

How one can end in such a situation?

It turns out it’s fairly easy, almost inevitable. You are the CEO building your first startup, with great business experience but little knowledge of software development processes. Naturally, you read about Agile and worked with developers in the past. However, your 6th business sense tells you that during the selection of a custom software development company you should press a little to get a nice estimate and lowest possible prices. So you did.

Development started, and things are going great accordingly to the plan. Everything is like, perfect. Software developers nail down features at the speed of light, UX agency finishes designs, and new people join the team. Suddenly, things start to slip. A few sprints into the project, new features start to appear one after the other. Everything looks equally important. After all, how come one can release an application that does not have multi-factor authentication or a user management module. Integration with 3rd party provider didn’t go that well. There is some technical work to be done etc. You see the pattern.

There are at least two possibilities, decrease the quality or scope. Custom software development company pushes for the latter. Unfortunately, too many business owners just refuse to make that difficult decision in the hope that “they will figure it out”. Sometimes they do, most likely they don’t. It’s hard to admit that plan was too ambitious but the cost of delay is enormous.

A good rule of thumb is to assume that 40% of the work is not yet discovered, so leave some spare time for it.

Building MVP the wrong way.

It’s true that we live in an age of Agile and Lean software development. Times of traditional project management are long gone and forgotten. Term MVP (Minimum viable product) is known by everyone from high school kids to senior members of the community. Problem is, that not that many people truly consider what it means to build MVP.

Think about it for a moment.
– Is it going to be used by real customers? Probably.
– Will you add new features in the future? Definitely.
– Do you want to show a half-baked product to the customers? No way.
– Should it be pretty? Absolutely.
– Does it need to have high quality? Yes.

Hmm… really?

Most likely at the time of writing MVP, you will not have customers but a very limited budget. From a purely technical perspective, there is a great difference between building a minimal viable product to validate an idea and vs full-fledged, bulletproof solution. Simply put, you can either spend a lot of time configuring scalable infrastructure, failover mechanisms, perfect CI & CD pipeline, Domain-Driven designed microservices or write a bit hacky app that does the job and looks good.

In software development, there is time for both. The hacky app will validate your idea and attract first customers but it’s impossible to maintain it in the long run. On the other side, microservices offer great scalability and development parallelism for a much higher cost. I bet that you heard stories of products that were put together in the garage in no time. Guess which approach they chose?

Having correct business goals in the proper stages is crucial.

Micromanagement.

In his famous book Drive: The Surprising Truth About What Motivates Us Daniel H. Pink points out three main motivators – autonomy, mastery and purpose. It’s a well-known truth that when you micromanage, the team loses the feeling of control and shortly after a desire to go beyond expectations. Things start to get slower and in the effect, no one has a sense of control or purpose. So why do we do it?

As always, it all starts with good intentions. Quite likely, over the course of the development team will make mistakes. Some of them are hard to predict, but others are surprisingly stupid. Question is, can you let them be wrong from time to time to build a sense of ownership and commitment or will you make all the hard decisions for them? It’s a very difficult decision. On one head, each potential mistake means loss of time and money, on the other hand, it’s the interference in the most basic motivators. Moreover, you are paying a professional custom software development company for their services.

Mind that, those who prioritize short-term gains over long-term team health and sustainability usually end up with the worst results. Business is an infinite game where only some of the players know and few of them play accordingly to the rules. The game that you can’t play for a long time alone.

Lack of focus on marketing & public relations.

Building a product is an extremely fun and rewarding experience. You need to think about the users, their experience, added value and various business models. Then coordinate activities between marketing agency, custom software development company and other 3rd parties. Not to mention countless questions, discussions and hard decisions waiting for you to save the world. Pure fun that creates a feeling of purpose and fulfilment. Easy to get entirely lost in it. And this is what most business owners do.

It’s a common belief that MVP is needed to raise the funding, perform a successful marketing campaign or get the first users. However, most successful companies proved that wrong. I really encourage you to read the story of Mint which used blog posts to get 20,000 customers pre-launch or Robinhood which built a waitlist of 1M+ people with a referral priority program. The entire paper can be found here, have a good read. Instead of being overly optimistic about their MVP, those companies built tension and communities which gave enough time for developers to finish the product. Not to mention that it’s way cheaper to do it that way.

Summary.

Clearly, there is much more than can go wrong. Building a product is a very complex process that involves all types of activities from writing code to running marketing campaigns. Unfortunately for us, there is no one size fits all receipt. Everything depends on the context, market conditions and smart choices.

Hopefully, with a bit of advice and additional knowledge, it will be easier to work with a custom software development company.