joesantos

I was a single developer on a 10+ developer team on this project. My role was essentially to work on the notification system, ticketing system, translation tool on the front and back end side of things. I've done more around the project but that was my specific role. Let me state straight away that this is my pure opinion and analysis. You shouldn't take this rant as more than that.

Wrong development stack

At the time, there weren't many frontend library projects. We are talking about Backbone era. As any good development team, a new library was sent to the world. This meant that we had to develop a framework and a product at the same time. The concepts behind the framework were good (for the time) but the mindset should be to send out a product.

On the backend, we had a microservice architecture on top of Node and a NoSQL database and I mean, a lot of microservices. We could probably have used a simple monolithic backend, remove a lot of the complexity and be quite fine with that solution for quite some time. We tried to be on the edge of the development world, added complexity and accounted to issues that didn't exist yet, consequently, wasted most of the workforce time.

Workplace to feel like home

Management used to say: "we want the workplace to feel like home". What? I don't want that! I would rather just be home. I don't want to spend any extra time on work. With that mindset a lot of money was wasted to rent a big house on an expensive location, buy big sofas, tvs, sound systems, meeting room tables and carpets... Living the "workplace dream". Most of the team didn't even have a good chair, none had good ergonomics at their table in matter of fact. If we hadn't spent this much money on frivolous and unnecessary things we could probably have more money to extend the deadline of the company. Also, the team was getting quite tired of the extra daily hours we had to give at least once a week.

Please stop with this culture. Productivity comes from a happy family and home, good experiences, good night sleep and a good social life, not a bunch of shenanigans at work.

So opaque

Even though we all knew each other and we were all on the same house working, transparency was close to zero from management to the "lower" teams. There was a very strict hierarchy and a hole between management / product decisions and design / development team. Everything was a mistery. Specially on a startup environment, the team should know about most of the business and product decisions so that they feel part of the product and I bet that you heard of the expression "two heads think better than one". Why not use your team to create a better product as a whole? Why have feature wise decisions being made by 2-3 people when you have 20 people ready to brainstorm it out? I guess you could argue that being surprised every day with new features or events already decided for you is an exciting life. Not for me though and probably not for the company health and sanity.

Money talk

Started as a sole independent team but gradually, investors started to have a say on everything within the company. They were making product decisions to the micro. You envision a product, you hire a team, you think about that product every single day, probably you have a good experience on the subject you're developing and you are definitely the one who knows the product better than anyone and what do you do? You let investors make all the decisions on the product. If they invested is because they believe in the vision you've set for your product. Have you lost vision to the point that investors have to say something? That is problematic. There was even a point in time where the team was creating websites for political campaigns (what?).

Scrum

I like books like Lean Startup or product management strategies in general but that doesn't mean that every single company needs approach X or Y just because it worked for Z. We had 1-3 meetings per day and for those you had to stop everything you were doing to have them, defocus and waste your valuable time. To be honest, I don't even think that most of us heard anything on those standups and review meetings. It was just something we had to do and get over with. 10+ boards on Trello with stories and issue templates... There are other ways to go about this.

Every one on the team was trustworthy, capable and responsible (well done human resources) so why not rely on them to manage the micro? We are not talking of a company with 50+ people where it is hard to communicate. The dev team was around 10 people, they were all on the same room, they should be able to manage themselves quite easily in a very fluid and fast way. You, as a product manager, could just set the tasks that need to be done and let the team organize themselves. Believe me, it is fine, I've tried it and succeeded at it.

Never ending story

The project took 3-4 years to be launched. It started only as a high quality audio streaming project before Spotify. Manage approaches and states "It was decided that we need more. Lets build a ticketing system.". We were building the project as the management felt like it was the way to go and that could easily just change on the next month. We were trying to become the next Facebook on day one but let me tell you something, Facebook didn't become Facebook on day one. Are you scared that someone steals your idea? If they are, you are already ahead and now you have an user base, you can focus on growing the parts that make sense.

Three things happened because of this "no deadline big project launch" issue:

• Investors grew impatient. They wanted their money value and rightfully so and as such they wanted to have a say on everything
• Spotify was launched with just the streaming part. Later, they launched notifications and the social part of it but first, they launched the streaming part and they got a lot of traction
• A buzz was created around the project for over these years of development and because one of the investors was famous, we got 1 million users on day one (impressive actually) and even though we were prepared for scalability, the servers still went down and the project was subpar. If we gradually opened it we would more easily account for scalability growing pain

Conclusion

I've learnt a lot on this project. Learnt a lot as a developer with the amazing team I was part of and learnt a lot as an entrepeneur. I don't think that the project failed because of the poor idea. Sadly it failed though and it failed because of the poor execution. Lack of transparency, aiming for the sun and lack of trust on your team were the major culprits. A good idea isn't enough, execution is all.