The Dilemma of Building a New Product vs. Rebuilding Existing Ones
7 February, 2022
The Sorry Tale of Poor Product Handling
When I was the associate director at one of the previous companies I worked with, I was given the responsibility of handling the product's website. As I got deeper into the role, I faced four different challenges at once:
- The website was poorly built and had collected a lot of tech debt.
- The team morale was low due to the quality of work which mostly involved bug-fixing
- There was an absence of a product strategy which led to a lack of alignment between various stakeholders and made the website a collection of non-cohesive features.
- The business teams, which depended upon the website for their goals, had a long list of requirements to be implemented.
As I stepped in, I was asked to look at the product holistically and develop solutions that worked for the business, the teams, and the consumers.
A Step by Step Product Management Approach
Alleviate the immediate pain
My first concern was to buy time and alleviate the immediate pressure on the engineering team by having a 'working' product. To do this, I partnered with the business teams and the engineering team to develop a prioritized list of 15-20 issues that required immediate fix. By sand-boxing, the things to be done and giving a timeline to the business team made the situation a little calmer for me, the engineering team, and the business team.
While the short-term work was in progress, I spent most of my time doing research, talking to all the stakeholders, whether it was business, marketing, content, product, or engineering. My intention here was to understand the needs of every stakeholder and make them feel that they are being heard.
Paint the Vision & align everyone on future
The most significant missing piece of the puzzle was to align all the stakeholders on the future of the website. For this, I came up with a product strategy. Since this strategy was based on everyone's input, in reality, it was "everyone's product strategy," and aligning everyone became much more straightforward. The basic premise of product strategy was to do a few things well and not be everything for everyone.
With the product strategy, it became evident to everyone what the website's goal was, what we would build, and what would happen in the future. As one of the key pillars of the strategy was to optimize the website for user acquisition, I could narrow down the scope, filter asks, and feature requirements in the future. The long-term impact of having this product strategy was that the business teams knew which product to use when and for what goal. So if they needed more users, they would bank upon the website. If they needed more engagement, they would focus on apps. This made life easy for everyone and helped us optimize and build our products for specific needs and build them well.
Assess whether to build a product from scratch or rebuild existing ones:
Both the approaches, creating a product from scratch versus rebuilding an existing product, have their pros and cons. Moreover, this decision was a product decision as it was a technical and financial decision. First, I looped in the engineering team for their recommendation and, together with the product team, thoroughly analyzed the options available. The lens for making this was the product strategy, and hence the focus was on the long-term. The proposal we came up with was to build the website from scratch.
Speak the stakeholder language
Once I was convinced that we wanted to build a new product, the next step was to convince the higher management, especially the finance team, to invest in it. I knew I had to convince in their own language and not just technical benefits. By creating a compelling story based on revenue projections, cost, consumer benefits, and business benefits, I was able to get approval from finance, CEO, CPO, and CTO to fund this project.
Fast-forwarding 45 days:
All the prioritized bugs in the existing product were fixed, product strategy was in place, and there was alignment on the future of the product amongst all the stakeholders. The team morale was high, and they were excited to work on the product from scratch. The higher management was also delighted since the immediate issues were taken care. Everyone was excited about the new product, and they knew what the new product would be capable of and could plan their strategies accordingly.
The entire work took about six months to complete, and we launched the new product in 5 countries at once. The website engagement, traffic, and users increased by ~5x, and all in all, it was a success.
What I learned from this experience
- As a product manager, you will always have to balance the short-term vs. long-term gains. Focusing on just the short-term or the long-term would not take you far.
- Before launching a product, have a product strategy in place, or else your team would become a feature factory. Focus on outcomes and not outputs.
- Whenever you get a new responsibility, a small quick-win that can make everyone happy can be vital to your and your team's success. A happy team is indispensable for success.
- Involve all the stakeholders from the start, understand their needs and concerns, and address them all at an appropriate time.
- Speak to stakeholders in their own language. For, eg. It is easier to convince the finance team by showing financial projections rather than technical benefits.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
As a Leader, can you show your weaknesses to your team? Your vulnerability to your team? Not only can you, you must.
Kamal Raj Guptha R
Engineering Manager at Jeavio
This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.
Chief Technology and Product Officer at Hive Learning
As a Lead or Manager, one could naturally incline more towards being either people oriented or task oriented. Which is better? Do you know which side you lean more towards?
Kamal Raj Guptha R
Engineering Manager at Jeavio
Supporting principles on why being data led (not driven) helps with the story telling.
Head of Engineering at Xero
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.
Google Cloud Practice lead at Contino