Working on startups made me understand that metric is one, if not the most important thing we need to focus on daily. And why do I say it? Because it’s something that people are not engaged in every second of their startup life, but they should.
Some years ago, my startup had the honor to be chosen to make part of the acceleration process from 500startups, one of the most prestigious accelerators in the world, and there everything was about metrics. “Are you going to change the color of this button? OK, but why? What do you want to prove and test? Just to make it prettier?”. Yes, everything needs a reason. After the first shock, I started understanding that if we want to spend some time coding, there must be a reason for it, otherwise, we are just wasting our time and $$$. So, before changing something and head jump on something, elaborate a strategic flow and have in mind something you want to measure and learn.
Sometimes we just enter an infinite loop of coding, launching, making more functionalities, correcting bugs and we are absorbed by this endless flow, but we forget the most important thing: the users. Are they using what you are creating? Do they understand why you have those functionalities? Are they really necessary? How many users were affected by your new functionality? What good did it bring to the company?
So let’s take a breath and start using a process for each detail and new functionality we decide to code, let’s create some theses and validate them. Let’s run away from the disappointing process of creating new web products, the famous “Build the product, code like there’s no tomorrow”. That’s a certain recipe for failure and money waste!
There is a better and modern way of making it. A lot of you know about it already, it’s the Lean startup way of making things. This is not just for software, you can use it anywhere. I personally started using a lot of these principles in my life.
- Build an experimental product.
- Measure how people respond to your experiment.
- Learn whether your experiment worked or not.
You need to know exactly what you want to learn. Then, how you are going to measure it, and last, build the experiment. Keep repeating this loop.
We can make these steps in almost, if not all the scenarios from small to big companies, from new products to new features and much more.
Every time someone comes to me asking a new feature or a new module for our projects, I always ask: “Ok, for what do you need it?” and after understanding the needs the next question is “Which minimum features would you be happy with?” (item 1). Here I try to limit the scope of the project to the minimum possible, because we really don’t know how the feature will be received and used by the users. So there is no need to try to make an entire long project if we can try with one or two smaller new modules, and then measure the response of the users. This way of working saved me and my team a lot of time already, because people tend to create a long list of things that they think they (or the users) need and will make their lives easier. This interaction always reduces the project drastically and we can deliver it faster.
The next step is to understand what they are using (item 2) and measure it. We can track how much the new module is used. How much work time does this feature save (if it’s an internal tool)? How many people are using it?
Finally, learn and try to evolve from that point (item 3). Are they really interacting in an expected way? Is it solving the problem we believed? Does the interaction with these new features explain the need to create more features that were previously asked? Then analyze what worked and what didn’t from your “guess” and evolve from there.
In my experience, a lot of the things that were first asked were proved to be unnecessary. Working this way helped me and my team focus on always delivering the most important features first and avoid loading the apps with a lot of things nobody will ever use.
Photo by G. Crescoli on Unsplash
If you enjoyed this article, be sure to like it give me a lot of claps — it means the world to the writer 😘 And follow me if you want to read more articles about Culture, Technology, and Startups.
Flávio H. de Freitas is an Entrepreneur, Engineer, Tech lover, Dreamer and Traveler. Has worked as CTO in Brazil, Silicon Valley and Europe.
Think, do, measure and learn was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.