On failure

Every day we see statistics about failures, affecting either new companies others or companies with an important background in software development large companies or start-ups, impacting either top edge mobile applications or state of the art web applications.

Since software development methodologies and frameworks are there for quite some years now and technology improvements are being delivered as we speak we could consider that there is already a proper setup for having successful products and/or teams. Yet the reality proves to be different.

 So why do our products and/or teams fail?

 There are a lot of reasons out there and I listed below the ones I encountered over the years:

  1. Difficulties in implementing software development frameworks at organization level – Usually most of the teams in an organization use the same software development framework but it happens to have many different practices from one team to another. I do agree that it is always beneficial to have flexibility in how we do our work, but at the same time when you are part of enterprise architecture, it is even more beneficial to have common practices.
  2. Difficulties in handling complexity – This is one of the main reasons when you ask someone why about failure: because our project is complex/because our software product is complex/because our team is complex. In my perspective, this an incorrect perspective since every complex thing can be drilled down in smaller pieces, which can be handled more easily. But in order for this to happen, you need someone in your organization capable of realizing this and being able to divide and conquer complex things.
  3. Difficulties in handling dependencies – When dealing with dependencies, either in the same organization or with 3rd parties it is strongly recommended to have a clear structure of the work to be done, clear timelines and also buffer time for unexpected situations. And also it is relevant to mention here the importance of having an open line for communication and an effective communication plan.
  4. Lack of a clear product vision and product strategy – Usually the vision and the strategy are sums/lists of ideas, not necessarily making sense altogether or being part of a broader perspective. Most of the times it is about short and medium term, in the long term they are not making much sense or the long term is disregarded.
  5. The product vision isn’t shared properly with the team members – Thus team members don’t engage too much with the product, they aren’t that creative, they are not embracing the product vision so they don’t have a real connection with the product, they don’t feel like they are part of something important and don’t take too much „pride” in the work they are doing (mainly doing task execution as long as it gets the job done).
  6. Endless changes in the product roadmap – Shifting the focus of the team, making team members less efficient and sometimes comfortable with the work that they do. And when moving from interesting and challenging work to less interesting and less challenging activities then demotivation starts knocking at the door.
  7. Not having a minimum viable product (MVP) mindset – „Until we don’t complete this large list of features we can’t say that we have a product”. This is one huge mistake which shifts the focus from the real problem of an organization, this being having efficient continuous delivery systems in place. Instead of putting pressure on the development teams in the organization with the high workload in short timelines why don’t we invest time and money in having the proper setup for releasing in production our software more often. Which is the sense of implementing a lot of features when you don’t have any clear way of determining how is the product success impacted by each feature? Why don’t we invest more time in user research, A/B testing, user personas, product analytics and double check on product vision based decisions with facts instead of hints or gut feelings? Why don’t we apply more often the MVP mindset on most of the pieces of our work and not only on a product level?
  8. Not leaving the room (time and/or budget) for unusual/out of the ordinary situations – Whether we like it or not unusual situations are there for our products and/or teams. Even with the best preparation and risks mitigation, there will be events which will impact our work. So let’s not forget to include them in our plans.
  9. Disconsidering the lessons learned from past failures
  10. Not being able to replicate success stories

… and the list can continue with many others for sure.

The Take-Away

Whether we like it or not sooner or later we may encounter failure. What we can do to prevent failure is to put great effort and attention in preparing our work, so that we reduce the chances of failing. But even when failure happens it is very important to learn the lessons from it, so that next time your product and/or team will be for sure successful.

Having difficulties in creating success stories with your products and/or teams? Let me know and I will guide your stories towards success.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s