In a lifecycle of creating products, it is required time and again to look back at the purpose and the goals the product is meant to achieve and build it further through feedback. This can only happen once it is launched and people are using it to solve their problems which is when the feedback is collected.
We recently launched CodeTrek, a product for the students in hills, to grow their software development skills. It received a great response as hundreds of students applied on it in a matter of days. One of CodeTrek’s goals is to create a talent pool, which makes it imperative for our product to be capable of measuring how many students were benefitted with this so that the product can be more effective and benefit more students. On the contrast we were only able to make it functional and get the users onto the product which we is a good start. We got a deeper insight into this as we heard from the users’ experience of using it.
Our team uses the product to connect with students and host courses for them. This makes two types of users for CodeTrek-the students and our team, and experience from both provide the feedback required to build it further. After conducting many sessions, we came together to analyse how the talent pool looked like, in-effect of this product and how far we got in the goal.
We had a discussion with the team, where product designers, and end users of the product which in this case was our team itself, that had gathered a deep experience of the product sat down to question what more we needed to reach the goal. We realised that all our efforts were focused on making the product work which was only one part of the goal and that sometimes the failure can be having the goals out of sight.
The best kind of feedback is the one that comes from the users directly. It helped us see how we can synthesise their experience to make them more empowered through the product. One of the feedback was that the product doesn’t yet help us identify the students that qualify for the talent pool. We brainstormed some solutions that would help us for what we would need to reach the impact. And solving this need gave us new ideas for building features further, that would help us take one step closer to the goal. Having a strong feedback loop and revisiting the goal gave us a chance to build a stronger product that makes its users capable of meeting the goals.
There’s so much more required to make a product successful, than building features and making it stronger technically, (not neglecting that it is the lifeline). Impactful products cannot be created without being focused on the problems it solves, which in turn gives rise to goals. And achieving those goals is a metrics of success. It’s not that there are no failures, and sometimes the failure can be in the form of being misaligned with the goals or not knowing what actions to take to achieve them and it can be solved by looking back at the goal and working on the feedback.