I’m looking for a little perspective from people who have gone through major product re-builds to help calm my mind:
I recently joined a 12-person software company as their first product manager. In my first 8 months, I was not able to deliver very much for a few reasons:
there are not sufficient engineering resources to keep up with both support and product development
spaghetti code and old architecture slow down development
the data model makes it hard to meet customer needs
the engineering leader is a poor manager
As a result, the CEO has decided (and I agree) to form a separate product team with me as the PM to rebuild our core product from scratch to solve many of the internal issues we’re experiencing and create a better product in the meantime. I think this makes sense. But, it’ll take 6 months to build. The “agile” part of my mind is freaking out because long build times can’t be good (right?), even though I feel it’s the right move for the company. I can’t get anything done on the existing product, though. I’m feeling like I’m in a bad position. Any advice to help calm my nerves?
@Marco, It sounds like a tough situation, for sure. Having gone through full stack rebuilds in the past, here are some suggestions for your consideration:
Make sure the objectives for the rebuild are crystal clear. This will help you limit scope and make decisions down the line. “Make it suck less” is a sure way for the scope to blow up and for 6 months to turn into 12 or 18. Make the objectives measurable.
Make sure your engineering leader and engineers are fully bought into the plan. It helps a lot if they are deeply involved in developing the plan, so that they will be invested in getting to the outcome.
Deliver value in small increments. When building your plan, create milestones that are anchored around customer value. If you’re delivering customer value while rebuilding the core, that will keep the team motivated, and keep the impatience from your CEO and customers manageable. Try to time the milestones so that you’re delivering something of value every few weeks, even if it’s seemingly insignificant compared to the larger goal.
Once the plan has taken shape, set expectations across the entire company. eg. “This is what it’ll take to be successful. We’ll have to be patient here and here. We’re consciously making these tradeoffs. Once we start, it’s a commitment we’re all making to see this through.” Having these conversations won’t prevent churn, but it’ll prevent surprises when churn inevitably happens. If you can, set expectations with customers as well.
Make sure the engineers that are working on this, their incentives and performance are aligned to the effort. Story time: during one of the ground-up rebuilds I led, I didn’t realize that the engineers were evaluated on “impact,” and one sure way to demonstrate impact was creation and ownership of a microservice. So what do you think happened? Our rebuild was designed with a dozen microservices, most of which we had no idea what they did, and there was a single engineer that knew the microservice inside and out. So if that person went on vacation or changed teams, progress would slow down considerably. People will do what they’re incentivized to do.
@MarcoSilva, Suggestions aside, the situation you’re describing doesn’t sound super healthy, to be frank. You have a lot of tech debt, a very small team, and poor leadership. That’s a lot of cards stacked against you, and a lot for such a small organization. Splitting a team of 12 into 2 might create focus but it’s a very drastic move for such a small team and might indicate some other form of disfunction. If you have team A supporting the existing core product and team B working on the rebuild, at some point you’re going to get into situations where you have to decide whether to fix something in the existing product or wait for the new rebuild to be complete, and meanwhile your customers will be waiting for their issue to be fixed. Also keep in mind that the existing product will continue to evolve, so the scope of the rebuild will increase as time goes on.
It’s tricky, it can be done! But you should also take a pause to consider whether or not it’s worth it? If you and the CEO are splitting the team to do a rebuild in order to avoid the engineering leader, that’s a very tough situation to be successful in.
Best of luck!
You nailed it @Nathan! There is some disfunction internally; let’s just say I was not met with open arms when I started here by the engineering leader. Plus, I myself am not experienced at “introducing product” to an organization, which I knew I’d have to do coming in (at least I’ve learned a lot!).
Thanks for the great discussion! One follow up question @Nathan, do you have some example on the objectives? Would the objective be very output driven as I assume the new product will need some degree of feature parity to reach outcome.
@MarcoSilva, - this is an ‘oldie-but-a-goodie’ on the perils of rebuilding from scratch. Maybe rebuilding is the only path forward for your team, but thought I’d offer a different perspective
Phew! that’s a tough spot to be in.
From past similar projects: While I dearly hope this is different for you, I’m pretty confident it will take longer than 6 months.
Also think through
how you want to migrate / handle the customer base?
Will this be a transparent change for them?
Will they have to migrate manually?
Will there be feature parity?
When or what if not?
How long are you willing to support 2 versions of your product?
Are you willing to lose customers?
When do you plan to get customers onto the new product?
How will you migrate customers, ensure data integrity, and uninterrupted service?
As long as you support 2 versions, how do you add new features? On both? Only the new one? Or does this mean you are not adding any new value or improvement to the product for the next 6+ months?
Think through the scenario if this doesn’t work out? Or takes much longer than expected.
What is the risk? How much are you willing to invest.
@SamanthaYuan, sure, I can try! From a past experience we were in a similar situation (albeit at a much larger organization of 100+ engineers) and faced with a bottoms-up rebuild. There were many good reasons for rebuilding:
The output of our systems were “dirty,” meaning we were outputting bad data to our downstream partners,
The system was too old and complex to create new product features that our customers wanted,
Speed of development and QA was too slow, and
We were concerned about ability to scale and bugs (eg. system resiliency and quality).
So, a lot of these reasons overlapped, but as you can see the focus is different for each reason. When we started planning with all of these reasons on the table, it was very hard to move the process forward because different activities would benefit one reason vs. another, and some people cared more about one reason and very little about others, so engagement was uneven across the team.
We solved this by going through a process of deciding on ONE focus and orienting our plan, roadmap, metrics, and outcomes on that. We chose to focus on 1, the output of our systems because focusing on that problem would create the most leverage - by fixing our outputs, we would be able to confidently develop new customer features; part of the reason why development was slow was because of the painstaking QA process due to the dirty data, etc.
Once that focus was decided on, we identified the outcomes/outputs that we would work toward and the metrics that would measure that progress. Some of those metrics were the match rate between the old system and new (in order to determine if the new system was better, we had to first get to par with the old system), the number of data exceptions found in the downstream systems. To a lesser degree we also tracked the operational efficiency of the downstream teams that we supplied data to as a proxy to whether or not we were making things better.
Now all that being said, the focus we chose made some of our stakeholders very happy (the ones dealing with dirty data), but made others less happy (eg. the ones wanting new features built). We planned our roadmap such that we would spend some time getting the foundation set up, and if certain metric milestones were met, we could start developing new features on the new platform once that area had been deemed “safe” for new development. Since this was a 12-18 month rebuild process, we had to do it this way as to minimize the impact on the business.
It’s a bit challenging to talk about this in the abstract, but i hope it makes some sense!
To all who have participated in this conversation: THANK YOU. Your thoughts and perspectives around rebuilds are tremendously helpful. @Heather, @Samantha, @Karan and specially @NathanEndicott & @NaomiNwosu.
@MarcoSilva, I was in a very similar spot 2 years ago. brought on as first product manager for small company, in midst of change from a legacy system that was same as you described. Some folks have already hit on it, but the transition from old to new is a tricky step. We had 6 months of build, then 4 months to get all customers over
