Between a Rock and a Hard Place
15 July, 2021
Managing a product is no less than managing a small city. In this case, I was the product owner along with some others, and there were some other contributors too. While the ICs were rigorous with the technical aspects, they did not have the mindset to deal with the customers. Nor did they have any idea on how the product roadmap worked at the CEO level. What happened was, we had a top-notch product at a company where I was the founding member, and we noticed that over the years, it was only the features, and nothing new.
The challenges then summarized into the following:
- How could we compete within the market with the features that we had?
- How are the elements going to be helpful?
- Would the customers be interested to use it?
- Should we make it simpler? If yes, then how?
On top of that, we did not hire any UX designers or a product manager. The engineers thought that they were capable of handling everything, but it did not work in that way. After 3 years of working, we were in a situation that was not scalable and visible at all. The whole product was going in the wrong direction, and did not have the string with us. We thought that there should be a person who was familiar with engineering and the customers. Finally, we established the fact that we needed to hire an engineer, who had a clear idea about the product and its capabilities. Basically, a guy who had a sound-mind about the product, but also had a touch-base with an engineering background.
Besides, there was another problem. I do have an engineering background, but in this case, I had to put on the hat of a product architect. Basically, I had to decide on the product’s design, get some ideas and explain the complexities that toggled from the engineering side. For me, it was like a contest during the first few days. My mind could only think from the engineering perspective. My team kept telling me that it was kind of impossible to achieve what we were trying to achieve.
At first, We hired product managers, who had clear knowledge of the domain and quickly set up a team. We decided that our team should not be big, but smart. I identified a group of 4 people, which made the team pretty stable. Our CEO himself took over some of the product responsibilities, where he was taking care of the customer’s problems and dealing with the UX designer. Some of them were not able to make it work, so the engineers played a slightly different role of being the product architect.
We worked with the product from the user’s perspective, and how the customers would actually use it. Normally, when we work on the design part, we assign some themes. However, in this case, our designers thought about the complexity or the scalability of the product and how it would work for multiple users and customers.
After that, I brought the engineering aspects to it and re-invented it. Personally, I think it was like a tree problem; I had to solve it step-by-step, one branch at a time. When the design team came up with a solution, they were able to solve all the usability, and nail down the user experience. Although the solution was pretty straightforward, it was not optimal.
Finally, we migrated some of the things to the engineering team from the product team. However, we had to keep in mind that our customers were our first priority, regardless of what we decided to do. Since I had a vast experience in customer cases, I created some steps, converted them to the engineering council.
- Sometimes, something might be in your mind, yet you cannot make it work. However, you should not give up, but articulate it from the point of view of different teams. Try out different tools if needed, but still make it work.
- We learned from our mistake that we were migrating through the engineering process, but should have got periodic feedback from a more extensive team like engineering managers. When a product is involved, it gets a platform, security and many other things. We did not apply all the processes; instead, we only gave them ideas and got their feedback. When it came to implementation, they were not ready.
- We were spending qualitative time repairing the marks and writing precise product tasks. As a start-up, we could not afford to balance between not writing and writing the idea and notes in terms of marks. We did not have time to write the details because of the type of market, and express what is in our minds to the team, which is planning to get it. One mistake will be not evaluating UI engineers in the process.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.
Director of Software at JANA Corporation
Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.
Vice President, Product & Engineering at Amilla
Brad Jayakody outlines the roadmap to maintaining a healthy balance between technical debt and team growth. However, just as balancing acts go it is important to have a strong foundation.
Director of Engineering at Motorway
Alex Bekker, Former VPE at Cresta and HackerOne, shines a light on how to preserve company culture throughout a growth phase and shares actionable insights on reinforcing your core values.
ex VP of Engineering at Cresta
Mike Nuttall, CTO at MyTutor UK, puts emphasis on the importance of creating and reviewing company roadmaps to strategize growth and alignment within an organization.
CTO at MyTutor
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.