How we do tech and product at Joko
As a technology company, before we ever wrote a single line of code, we took time to think about our vision for tech & product. Three things have been consistent since day one: keeping teams small, investing in the process, and making data-driven decisions. In this blog post, I want to tell you more about how these three principles influence the way we build products.
A small tech team with a strong impact
Did you know that when Instagram got acquired for $1b, they had 30m active users, but only six engineers? Or that WhatsApp only employed 32 engineers when they had 450m users and got acquired for $16b? There are actually many other similar examples in the history of software, from Android to Minecraft.
Still, it is always perceived as contrarian when we say we want to keep our tech team small. When it comes to engineering teams, we really believe that bigger isn’t better. We have made the choice to keep a small but very strong tech team.
Of course, it requires strong ownership. At Joko, software engineers don’t just handle tasks, they own their features from A to Z. As technical counterparts of our Product Managers, they are involved in the product process from the very beginning: roadmap building and prioritization do not happen behind closed doors and engineers actively give input into the writing of functional specs. Then, they are in charge of defining technical specifications, implementing the actual feature, and deploying everything into production. We have experienced that our most successful feature are the ones where software engineers are most involved in the product process.
This approach also requires a full-stack culture. We don’t have backend engineers, frontend engineers, or data engineers. We have engineers. They get to work on everything and as a result, they never stop learning. Oftentimes, we ask the developer who is the least experienced with a part of our stack to work on a feature that involves this part of the stack. It may be a little slower to ramp up skills, but it definitely makes us win in the long run.
You may be thinking: that’s a beautiful idea, but in practice, how do you get a lot done with so few people? Believe it or not, but with a small team of strong individuals who are empowered enough and who can do whatever needs to be done, it can be blazing fast to get large-scale projects done. When we decided to build a web app to complement our mobile app, it took only 6 weeks to go from idea to officially shipping a fully functional product, and only one engineer worked on this.
A strong process to get things done
We are also big believers in the process. Process is one of those concepts that generate a lot of polarization. Many people dislike processes. They think processes kill innovation and remove agility. In many organizations, this is actually very true. But these are organizations that have forgotten a very important principle: processes should work for people, and not the other way around. Processes should make your life easier. They should allow you to focus on getting valuable things done, on creating new things.
To avoid this trap, we always make sure that changing the process is a central part of the process. Whenever a problem occurs, the process forces us to ask the question: what should we change in the process to avoid that problem from happening again?
For example, after experimenting with sprints, we decided to stop sprints. We realized that while sprints could be relevant for very large engineering teams, it created unnecessary frictions in our small teams with many rituals, and an unnecessary feeling of failure when estimations had been too optimistic.
From functional specs and technical specs to code reviews and QA, every single detail matters, and thanks to our process that has been fine-tuned over many many months of iterations, we rarely miss important questions before working on a new feature. Over time, this continuous improvement has incredible compounded effects, and it has turned our process into a real competitive advantage.
Data behind any decision
Successful companies have often been built against conventional wisdom. Think of Airbnb back in 2008. Who would want to have strangers staying in their apartment?
When it comes to product development, you need to make sure that you are making the right moves and decisions at all times. And to do that, it’s better to look at actual facts and data than to listen to what your cousin thinks.
Users are not always rational. We noticed that they often say something but then do the opposite. We used to have a feature in our app that many users said they loved. But we ran an AB test and found out that this feature had a negative impact on long-term usage and retention: users who used that feature loved it in the beginning, but it prevented them from discovering other features that would make them stay in the long run. So we removed it. We suffered some backlash from users of course. But we were okay with that. We were doing the right thing.
Reality is very counter-intuitive. AB tests have often proved our intuition wrong. That’s why we run a lot of AB tests. We constantly have multiple of them running in parallel. We just know that we don’t know, but we have built our process in a way that we never forget that.
We measure everything: not only did we invest a lot on our analytics stack from day one, but not a single feature goes into production without an AB test or a detailed impact analysis. It’s part of our specification template to ask these questions: what do we want to measure? Do we have the right analytics in place for that? And our Product team is completely autonomous in making these analyses.
Want to know more? joko.com/join
