On leaving Eneza Education
Today happens to be my birthday. This week also happens to be my first week after leaving Eneza Education. Friday 29th of August was my last day at Eneza. I only worked there for 5 months!
Is there any better day to reflect on my Eneza journey? I don’t think so. In this post I will share why I left, some of my key achievements, what I could have done better, and what I am embarking on next.
Why did I leave?
I will keep this short and concise — the decision to leave was made by my former boss, Kago Kagichiri. Ultimately, he felt I wasn’t adding enough value to the organization and saw it better to take on the product manager role. This is a risk every product manager in any startup that hasn’t established product management as a role faces. Being a role that involves juggling a lot of tasks and working with different people it is easy for it to look like you are not doing much.
I wish him the best as he embarks on the role and I hope a lot of what I did will be used to accelerate the process.
What did I achieve?
Five months is quite a short time to have a lasting impact in an organization. However, I feel I did quite a lot at my time with Eneza.
1 — can the dev process get better?
My first assignment when I joined Eneza was to work closely with the development team to improve the software development process. Eneza’s team is agile but there was an opportunity to improve how they practiced agile. With my old team at the iHub we had made a lot of strides in this. Luckily the CTO, one Moses Mutuku, and the rest of the dev team were very supportive. We improved the dev process by:
- Planning our sprints better by making more realistic estimates of what could be achieved within a sprint. Previously, during sprint demo there were many incomplete stories from the previous sprint
- Improving how requests to the dev team from the rest of the team were handled. To do this we rolled out Jira Service desk and made it the only way anyone could raise a support request. This helped consolidate everything in one place and allowed the dev team to have one single place they could handle any requests that came their way
- Created a process document outlining how the different dev-related activities were carried out. It covered how bugs and feature requests were made, how the team built and deployed software, how documentation was done and so on and so forth. The document served as the on-boarding guide for any new developer. Luckily a lot of this was in place and so it was a matter of having it in one document.
2 — Developing a shared product vision and goal
I have talked about this extensively in a previous post and so I won’t delve deeply into it on this post. The premise behind having a product vision, strategy, and roadmap is to ensure the team has a clear idea of the company goals and how each team contributes to the goals. You can read more about this in the post below.
3 — Identification and implementation of a Growth Framework
As a startup with significant traction, Eneza was at a point where they needed a sharper focus when it came to their growth efforts. To get this going, I introduced the Startup Pirate Metrics (AARRR) to simplify how we looked at the customer journey. Pirate Metrics focusses on five key items in your funnel.
We then identified where we were struggling the most and worked together to improve. The product roadmap was also broken down into the above funnels.
The second action I took to get the Growth framework in place was creating a cross-functional team that would work together. This was named the Growth team and was originally comprised of one rep from customer care (Emma), one from content (Polly), one from tech (Henia), one from Ask-A-Teacher (Matthew), and our B2C guru Veronica. Each week we met and identified key challenges within the product and used our shared perspective to develop better ideas to solve the challenge. Later on I whittled the team to three (Customer care, B2C, and I) to get things moving faster. The Growth team wasn’t a new concept at Eneza. The team previously had an R&D team but it died after some time.
4 — Unified metrics and the rollout of a product analytics tool
When you have a lot of data it is easy to track a lot of metrics. It is also easy to have different definitions of metrics. To simplify this, I worked with the rest of the team to identify the metrics we felt were the most important. They were identified based on the AARRR framework. It cut it down into a smaller number that was easier to track and had more impact when they increased or decreased.
The next step after reworking the metrics was to identify what we referred to as the North Star metric. This was the one single metric which if we all focussed on would have a positive impact on everything else. For Eneza, we ended up choosing stickiness as our North Star metric. Stickiness is the ratio of daily active users to monthly active users (DAU/MAU) and it tells you how often users come back. It is measured using a scale of 0–1. Let us say you have a value of 0.3. What that means is your users come back to your service typically 9 out of 30 days (0.3*30). Our aim was to grow this and the spiral effect would have been positive on every other metric.
Last but not least, I identified and implemented a product analytics tool called Mixpanel. Mixpanel is one of the best product analytics tool out there in the market. It will quickly help you turn your data into insights. Rolling it out allowed the different teams to quickly understand what the data meant and what action they needed to take. It is a very expensive tool though and so was only an interim solution as Eneza tried to improve the internal tools they have.
5 — Refinement of our experimentation framework
I am a huge fan of the Lean Startup approach. One of the key things I love about it is the Build-Measure-Learn feedback loop. It allows you to quickly get ideas tested and validated before scaling or killing it. When I joined Eneza, the previous product manager, an amazing guy called David Henia, had created an experimentation framework that guided teams on how to plan and run an experiment. I build upon this by introducing the 5 whys as a way to think through issues we noticed and implementing the Build-Measure-Learn feedback loop for any changes we rolled out. Mixpanel helped quickly analyze and make the call whether to scale, rework, or kill an idea.
What could have I done better?
- Sought clarity on which stage the organization was. I spent a considerable amount of my time building for the scale yet there was still a lot to be done before that phase. Additionally, I mistakenly assumed I could let the team concerned with driving revenue continue doing it until I completed the other tasks. This was the same thing with user research — I left this in the beginning to the customer care team as I worked on the neglected areas. I failed to get that perfect balance.
- Gotten clearer goals and a way to measure what I achieved from my CEO. This kept changing and made hard for me to know if I was doing well or not. One of the companies I interviewed with before I joined Eneza asked for my goals for the first three months. I should have gone with the same approach with Eneza
- Hired a data scientist sooner. This is the one person who would have accelerated the visibility of what I was doing. My data analysis skills were rusty and so I had to spend a lot of time brushing them up.
- Communicated to the team better on how each of their individual efforts contributed to the success of the product. I did it but I am sure I should have spent more time on this
- Interrogated the company culture harder and made the call to join and fit in or not join at all. If there is one thing I have learned it is that changing the culture of an organization is one of the hardest things out there
The above contributed heavily to my termination and I now know better.
What next?
I have decided to take on the challenge of building a design consultancy firm based here in Nairobi.
I am starting out as a freelance product designer, UX researcher, and Sprint master but the long-term plan is to build a team. In a later post, I will share more about this. In the meantime feel free to ping me using hello@kirui.co.ke if you are interested in any of the services I have mentioned above.
Join the product and design professionals reading Noteworthy to understand the ideas and people that shape the products we use every day (and get an early peak at our product!).
If you have thoughts to share, we accept post submissions!
