How entrepreneurs sabotage their own product development.

Published in

The Startup

8 min readSep 7, 2018

Business owners nowadays spent a lot of time making selection of the perfect custom software development company. The one, that will carry on product development without much of a hassle in reasonable cost and time. It’s a good thing. After all, their professionalism and efficiency have 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 that writing code. It’s all about the people and interactions, not the tools and processes. Quoting 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.” 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 on the way in which you can work with custom software development company.

Underestimation of the product ownership.

Too often software development outsourcing is associated with just having 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.

Team comes to you to inform that integration with external payment provider will take two months. Biggest obstacles comes from the fact that having fully automated withdrawals policy is extremely hard. 3rd party provider uses 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 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 provider 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 semi automated solution which schedules withdrawals in an automated way, but uses operations to review and accept on periodical basis. After all, 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 pure waste of time and money. Custom software development company will happily take ownership in such cases if you just give them a bit of a freedom.

Not having a 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 launch except of … 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 first employees. Who can be better for the job of Product Owner if not you?

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

Let’s consider this simple example. Team is in the middle of a sprint adding first features to the web based version of the platform. In the meantime, you did 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 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 Proxy Product Owner? Someone who can do all of the work and coordinate with 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 full time Product Owner. Successful start up founders never have time for proper product ownership. They get dragged into various discussions and activities. 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 lack of time for innovation or research. Effect is easy to predict — overdue projects, unhappy developers and angry customers.

How one can end in such situation?

It turns out it’s fairly easy, almost inevitable. You are the CEO building 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 selection of custom software development company you should press a little to get nice estimate and lowest possible prices. So you did.

Development started, things are going great accordingly to the plan. Everything is like, perfect. Software developers nail down features in the speed of light, UX agency finishes designs, new people join the team. Suddenly, things start to slip. Few sprints into the project, new features 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 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.

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 community. Problem is, 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 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 very limited budget. From purely technical perspective, there is a great difference between building a minimal viable product to validate an idea vs full-fledged, bullet proof solution. Simply put, you can either spent 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. Hacky app will validate your idea and attract first customers but it’s impossible maintain it in the long run. On the other side, microservices offers great scalability and development parallelism for much higher cost. I bet that you heard stories of products that were put together in garage in no time. Guess which approach they chose?

Having correct business goals in 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 well known truth that when you micromanage, team loses feel of a control and shortly after a desire to go beyond expectations. Things start to get slower and in the effect no one has 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 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 sense of ownership and commitment or will you make all hard decisions for them? It’s very difficult decision. On one head, each potential mistake means lost 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 worst results. Business is the infinite game where only some of the players are 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 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 feeling of purpose and fulfillment. Easy to get entirely lost into it. And this is what most business owners does.

It’s a common belief that MVP is needed to raise the funding, perform a successful marketing campaign or get first users. However, most successful companies proved that wrong. I really encourage you to read the story of Mint who used blog posts to get 20,000 customers pre-launch or Robinhood who built a waitlist of 1M+ people with a referral priority program (entire paper can be found here). 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 custom software development company.

Originally published at pragmaticcoders.com on August 27, 2018.