Not effective way to build a product

There are many ways to go about building and shipping a product. Countless product companies have shown how to be successful.

This article is not about that.

I am here to talk about a specific non-effective way to build a product I encountered firsthand and don’t think is right. This way is something I have seen variants of during my brief career as a software engineer. Due to the culture here, I feel pretty confident to generalize to the whole of the tech industry in Singapore. But I will not generalize it to else where in the world because I have not experience them firsthand. It just won’t be right.

Background

You are a company with multi-hundred millions in profit every year, and there are thousands of employees scattered across various business units within the company. These employees are required most of the time to take on multiple projects, applying their specific skills in those projects. As a company, you have been around for nearly half a century, have worked on countless projects, and successfully delivered them. Your core business is about delivering solutions on-demand.

Recently, a new project was awarded to you and you like to make the end solution a product as part of the company’s new direction to build products. The project was also sub-contracted out to another company from overseas to do the other part that you have zero experience in and is also more cost-effective.

What did you do?

You “parachuted” in someone who wasn’t included in the original tender process to lead the project. This person has no idea what just happened, no background, nothing. Shortly after, you got a new employee who only has prior experience in developing web-based products and working experience in data science. This new employee is responsible for everything backend.

Over the couple months, the project team was tasked with design of the application, with incomplete information, incomplete user requirement, and called upon to start writing codes because the project only has a six month before delivery.

Three months since the project started, you got a couple of new hires to fulfill the headcount that you submitted as part of the project tender. The new hires were “orbital dropped” in to think of, design, and implement functions that the users will want in addition to the pre-existing ones defined in the specification, which are scoped way out of the capability of the team, half of whom has zero experience in the specific technology stack.

You also expect the team to build the application (both backend and frontend) such that it is highly modular for “anytime” enhancements and capable of supporting future requirement of supporting mobile platforms. Full delivery is also expected within six month.

At the same time, you expect the barebone team to also deliver proper documentations in accordance to CMMI. These documentations will be subjected to audits in six months time, same time as the project delivery.

Lastly, you also told the team that the project is on very tight budget and can’t afford any delays.

What you didn’t do?

There isn’t even one full-time product designer taking care of the whole user experience because the project funds didn’t cater for that.

In addition, there is no product manager and instead you have a project manager who has zero experience in building a product and successfully deliver that.

Existing solutions from other projects that are very similar to the one the team is building weren’t shared and everything has to be rebuilt from scratch.

Design wasn’t done for even the individual components, with zero standards to follow when it comes to building the various software layers. Everyone is given free rein. The project isn’t following agile development and isn’t design-driven,

No additional backend developers were added due to budgetary constraint.

Information isn’t flowing freely due to compartmentalization or simply lacking because you didn’t get someone experienced enough to ask the right questions.

What is the end result?

Without a proper designer, the application is basically a bunch of duct-taped solutions with ugly icons and images without detailed care of how user will interact with it.

The application as it stands now also has poorly named classes, poorly defined functions, with zero standards on the APIs. Proper use of design patterns were non-existent.

Documentations are all still in rough drafts, with each person covering their respective portion, and not even complete despite audit is in few days time.

The team member who has to deal with the backend is so swarmed with work and has to stay back late for the last few months until it affected the husband-wife relationship and parent-child relationship. That team member did raised the request for additional manpower but kept getting rejected and was told by management to work even harder.

Of the new hires, one has zero interest in product development or thinking like a product developer, will only do as told, leave work on time, and has no further desire to climb the ladder. The code written was functional and in accordance to specification but lack any proper design, lack care for usability and performance. This new hire is focus only on frontend development and has minimal backend experience. The other became a full-stack developer, has product development root, has desire to grow as a product developer and designer but didn’t get any mentors because the focus was project delivery. This person has no issue with delivering but felt thoroughly dissatisfied with the job. This person also already has his other foot out the door, looking at a career change and is just looking for a reason to quit product and software development for good.

As it got closer to delivery date, the team is hit with new information about the customer’s environment that possibly wasn’t thought of early during the requirement gathering stage. Now the team isn’t even sure if it’s possible to replicate customer’s environment fully to test out any solutions.

Conclusion

With a dysfunctional team, dysfunctional management, poor information dissemination, the need to reinvent the wheel so often, product development just simply cannot take place no matter how much you wish for it.

The culture of the company, and the project-oriented mindset of the higher management and people on the ground is just very inconducive to product development and innovation. So that is another nail to the coffin for product development.

So if you are a big company and really want to build a product, please don’t do it this way.

One thought on “Not effective way to build a product

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.