Between a Rock and a Hard Place

Problem

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.

Actions taken

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.

Lessons learned

• 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.