Shifting Bandwidth and Using POCs for Larger Projects

Problem

Working with small teams you always have to pick and choose your battles. Do you solve the immediate problems of today or do you take a more long-term approach? In my experience, with startups you usually end up prioritizing the short-term fix first and then you go find the long-term solution later. However, more often than not you don't end up solving the long-term issues and the problems cascade, piling on top of each other, continuing to mount and grow. Within a small company I was working for we were faced with this difficulty. We had problems with an analytics product that just wasn't serving our users' needs. There were problems with performance, frequent downtime on production, and other issues with the product. Engineers kept fixing the short-term issues that were arising but we did not address the overall problem that needed to be solved. Nevertheless, I did not lose sight of the long-term horizon and what really needed to be done to solve the problem. I knew that to fix the underlying problem it meant a full platform re-architecture, a complete re-platforming of our analytics stack. A long-term project with a heavy engineering effort. To achieve this there were two pieces of the puzzle that needed to be solved.

Actions taken

First, a lot of the problems that we were facing were because there wasn't a good proof of concept (POC) process in place. Decisions were being made yet there was no reasoning for those past decisions to be found. So I did a three-month POC process to find the main components of an analytic stack, query engine, warehouse, and visualization layer for creating reports, dashboards, and queries.

Second, a lot of times the focus is on short-term resolution because bandwidth is limited in both product and engineering, and this situation was no different. I convinced my leadership to give me the bandwidth to focus on the long-term while all the short-term fixes on existing products were completely transitioned to engineering. Engineering and operations started making decisions on the short-term, freeing up my bandwidth and allowing me to spend it on the long-term issues of re-platforming and POCs.

After 3-4 months I was able to present my case advising in specific query engine and analytics that we should purchase, along with how much engineering work was involved in integrating those pieces into our platform, the impact on engineering, and the cost impact. I made a case for all of those things that needed to be done. I rationalized that retention of customers was a huge problem and in order to improve our retention numbers we needed to fix the long-term issues. I also argued that if we had a good platform then we would be more efficient with our engineering bandwidth. For example, instead of managing and maintaining technical debt and recurring customer problems, let's redirect the engineering bandwidth to build something completely new where we are solving all short-term problems while also having the customer problems go away as a result. I was able to convince the team and actually it was a very seamless integration because all of those things were cut off during the proof of concepts process.

Lessons learned

Having a proof of concept for big projects is extremely important. It was something the old team didn't do and one of the reasons why we had all of the problems to begin with. I made sure to try out all of the POCs and use cases in the proof of concept space before I made all the decisions. So doing proof of concepts for big projects is a must when it comes to changing large parts of an application.

I also believe that we could have had a smoother roll-out of the product but due to not having enough bandwidth when launching became a tradeoff for getting the product out there. When it's a small team a product manager obviously needs to work very closely with engineering to get the product built right. Likewise, it's equally important to work with support, professional services, and product marketing. When a product is getting rolled out make sure that documentation and training for new users is ready, that sales are going out and selling the product, and that you are guiding clients through the migration process.

Lastly, get users comfortable with the migration process, moving from their old platform to the new one because there is some work involved for the user him/herself. Sometimes it takes convincing to switch over. To do so put the product in their hands to use rather than putting the product on slides and showing them screenshots of the changes and advantages to switching. People aren't easily convinced this way. Instead, when people start actually using the demo or are in their own environment they are more likely to make the effort to migrate over.