Throughout my career I've been working on many side projects, some of them which I don’t even remember today. Despite that, there’s NOTHING out there.
This is something that has been around my head for a while now, and I have to admit it: It frustrates me.
(This is a list of the side projects I've been working on recently. None of them are finished)
If we look at the image, which is only counting some of the side projects I started during the last 4-5 years, we can see how much time I invested in things that never went live. The sum of it would be roughly 4 years. That means that within that time frame I've always been working on a side project. What's out? Nothing
While I’ve been part of awesome projects, and helped getting out really good products, there’s nothing that I shipped. And don’t get me wrong, this has nothing to do with money nor “having a company”. I am talking about the satisfaction around owning the end to end development of a product. And this has nothing to do with proving myself to others either, but to prove it to myself. That would make me really happy.
After a lot of thinking, I think there’s a common denominator:
When is a product good enough for it to be shipped?
We sometimes refer to this as MVP.
While this is a widely used term, there are multiple interpretations of it that are used. And I think that I have failed at both interpreting and implementing it (and hopefully learned by my mistakes). By wanting to ship an awesome product that had ALL the features that I thought the final product should have, I was violating the concept of MVP. And I was contributing to my frustration.
So what’s an MVP?
If we refer to Wikipedia, an MVP is:
A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.
While in theory this is pretty simple, let’s get a bit deeper.
In my experience, there are 4 really important things that should be kept in mind. Those being:
- Time
- Balance
- Customer value
- Iterate, iterate, iterate
Time:
Let’s start with the most basic thing. Time is ALWAYS a constraint. Whereas we talk about real life or a business, time matters.
Shipping a product in 3 months, or shipping it in 2 years, is a BIG difference. You might even lose your opportunity.
As an engineer, I sometimes have failed at understanding this point. Both while working on a company’s project or on my own. Having a perfect solution but late in time cannot only affect market fit, but it also frustrates engineers (and the company, if applicable).
Balance:
I really believe that everything in life is about balance, and this is not an exception.
If we sacrifice time, we end up not testing a market fit, and we frustrate people. And by the time we ship it, it might be that there’s no market fit, and everything goes to trash (I’ve seen this happening. And, as an engineering manager, it is really tough to get your team motivation back to healthy levels after that)
If we sacrifice quality... Well, we all know what happens here. Nobody wants an unusable product. No way to test market fit, engineers are not happy (if in a company, you might have pissed them, and even your position might be at risk)
If we sacrifice customer value, we end up in a pretty similar situation as the previous one. No one cares about a perfectly engineered app that does nothing. How are you going to test your market fit if none or most of the core features are not there?
Customer value:
Here it comes a tricky one. I should have "just enough core features to effectively deploy the product, and no more". Ok, so what's that?
It is common to mix personal preferences with this definition. While in a company, it is common for Business, Product and Engineering to have different views on this one.
How can we ensure we only work on the correct ones? I'm still trying to figure out an answer for this that would not be just theory bullshit.
In my experience, the approach that works better (in a company) is to sit directly with Product, understand the concrete needs we have, to then provide different options highlighting effort and trade offs of each of them. Product is supposed to have all the needed context from Business, so they are going to be able to determine which of the options we provided are meeting expectations. As engineers, it is also our duty to ask the right questions, and to provide the needed explanations.
With all of this on the table, the decision should be trivial.
Iterate, iterate, iterate:
Ok, this is not tied to the concept of MVP, but it is extremely tied to the way of working with them.
I'm pretty sure the product team at Careem is tired of hearing me asking them to narrow the scope to then iterate. But it is because I extremely believe in this approach. I've seen products shipped for the first time that should be a 5th iteration!
I can only think of benefits when I think about iteration.
- You get to ship stuff out to customers earlier.
- When shipping a product earlier, you get to test your market fit. Shipping early means early feedback
- Pivoting. If you don't get good traction, you can pivot and try again without trashing a lot of stuff
- By providing engineering small and context based problems to be solved, you improve the focus, and most probably the quality as a side effect.
- If you have an iteration mindset, you can have multiple things running in parallel instead of having a big ass feature in which your whole team is working on.
Just for fun: edge cases I’ve seen:
Disclaimers:
- Not trying to generalize, just giving examples that I’ve seen. Don’t feel attacked, please.
- I’m not here to tell you how to do things nor I have a silver bullet, just sharing some thoughts about it.
For Product Managers:
As a quick way to get things out
Translation: No quality involved. Pile of hacks put together.
For Business:
A product that fulfills ALL the needs the client has, as fast as possible.
Translation: Extreme pressure that ends up burning out the team. Poor quality, nobody is happy.
For "hacky" Engineers:
Same as Product Managers
For “looking-for-perfection” Engineers:
A perfectly crafted product, with top standards with ALL the functionality.
Translation: Everything, with high quality, but in 3 years.
We can see here how sometimes our own interests may affect the way we (want to) interpret things.
Summarizing:
Ship small quality pieces, analyze, fix/trash, repeat
This write up started as a self reminder of the mistakes I've been doing in the past (and that will hopefully not do again), but then decided to post it for it to be a self wall of shame if I ever repeat them.
I hope it is also useful for others. My idea is to update it based on feedback and/or experiences. So happy to hear you out. Expect it to be updated/polished.
While in this post I mostly cover MVP related stuff, there were other factors that also contributed to the fact of not having shipped anything until now. I might be covering those in a future post.
That said, I hope the situation changes soon, since I am working on pretty cool side projects at the moment.
Stay tuned!