Picture the scene: You’ve been working on a product with a transformation goal for several months. You are getting closer to defining the solution, gaining stakeholder support and starting to see the reality of the team’s work coming together. You’re then hit with the news that for reasons outside your control, there’s a significant amount of change and backtracking needed. Instead, you’re now tasked with delivering something very different and less ambitious.
This was my reality recently, and I’ve been reflecting on how this influenced me and the team, alongside what learnings I might take into the future.
The first few weeks there was lots to untangle and discuss. It started with denial - couldn’t we still deliver the same end result with a smaller scope? Did we really need to go back to the drawing board or could we still largely continue as planned, with some tweaks? It soon became clear these weren’t realistic options and that there was no choice but to take a bigger step back from the work we’d done to date. Things would need to change.
The changes to the product’s development can broadly be broken down to addressing the why, the what and finally the how.
Why
Reflecting on the reasons for building the product and its importance both internally and externally.
Revisiting the vision
This was a necessary first step. With a change in direction, it was important to know if the fundamental drivers behind the product had changed. This had to happen before restarting work, to validate or invalidate any assumptions about what was to be built now. Conversations around the vision that had brought everyone in the team together at the start needed to be had again, and while our overall objective remained the same, the vision no longer stood and had to be rewritten.
Rebuilding trust
Outside the core team, there was also a question over how to handle relationships with those invested in its success. With less to get excited about, there was a real risk that the wider stakeholders would lose their enthusiasm and shared understanding - which could impact their buy-in and ultimately the end result of the product.
Sharing the revised vision was an important part of this process. In hindsight, a less ambitious vision which overlapped more closely to other areas made our goals more tangible and understandable. This was ultimately easier to communicate and generate support for.
What
Assessing the impact on the product itself, its users and their perception.
Drilling down further, there was some doubt around if the new vision could deliver the same impact. Having already been through the process of identifying which unmet needs the product would solve, these had to be reviewed again to see if they were achievable.
Fortunately most of the same requirements were still going to be met. The main difference that could impact success upon launch was users’ perceptions and feelings; something that wasn’t a consideration in the initial research phase. This ended up having to be factored into the concept testing process to see if it was really a potential problem.
How
Re-evaluating the implementation and finding new efficiencies.
Now that the main ambiguities had been tackled, it came down to how the build would be impacted. Again, it turned out that there were areas of the existing infrastructure that were now accessible and usable that hadn’t been before. There was a lot that could be adapted, to make things more agile.
There were also new opportunities that wouldn’t have been possible to implement with the original scope. Features that could be improved to the benefit of the user because they weren’t brand new. There was also time for A/B testing due to not needing to build as much from scratch, so we could explore refinements and improvements.
Looking back
By this point I’d accepted that the product was not going to turn out as it was originally intended. There were undoubtedly downsides to this, especially from a launch point of view that it wasn’t going to be as noticeable a change for users, or as much anticipation for its reveal.
Despite this, in this instance having a much narrower scope that had less of the ‘brand new’ ended up making sense from a PM perspective. It was a lot easier to communicate and to understand than the original vision. It became faster to build, which meant there was more to take advantage of and to learn from which actually led to improved outcomes.
If I was in a similar situation again, the main learnings I’d take forward would be:
Not making assumptions about the direction to go in - even if it means taking a few steps backward
Accepting it’ll take time to rebuild relationships and understanding
Revisiting ideas that have been discounted in case they’re now feasible
Keeping an open mind that ‘different’ or ‘scaled back’ can still bring good results