After the principal customer backed off a requested new feature, I decided to quickly wrap up our discovery work.
Large feature requests require more time to plan and necessitate more resources. Collecting and sorting through customer requirements may stretch out over weeks or even months. And once these initiatives get going, they can gather momentum making it more difficult to shelve everything when the team's priorities change.
What drove this decision
One of our largest customer had asked us to help them with a problem that was tied to how they were using our software. It was a new problem for us but one that we felt would likely benefit other customers.
We had acquired a solid list of initial requirements but we knew better than to rely on only 1 source. So the Product team started researching the similar needs of other customers to begin the work of scoping out a new feature.
Not long into this effort, the original customer reprioritized some of its own, internal initiatives. The urgency around this problem diminished and the feature request dropped much further down the list.
The decision: Suspend ongoing product discovery and shore up the current state of requirements.
I wanted to make sure that if and when the feature came back around, we could resume quickly and regain some of our initial velocity. We had made good headway and I needed to preserve as much of that as I could, especially if a different team would be picking up the feature next time.
Plan of attack
I was confident that the next team to work on the feature should not have to start from scratch.
Requirements change, technology changes, and priorities certainly change. And I was sure that if we restarted this effort even 2-3 months down the road, we would have to revisit our assumptions. Still, I felt confident that we had been on the right track and wanted to preserve our progress as best I could.
Review the current hypotheses
I started by capturing the hypotheses I had developed around the proposed feature. I made sure to describe the thinking that went into the current hypotheses, to highlight assumptions I was in the middle of testing, and to list some of the ideas I had already ruled out.
Obviously some of these assumptions would - and should - be revisited but the next group would certainly benefit from the validation work I had done for the parts around which I had more confidence. For example, rather than build an entirely new scheduling tool to orchestrate and run a proposed background process, I had intended to leverage one we already had, even if it didn't completely accommodate all of the new requirements.
Create a list of next steps
I was forced to pause in the middle of the feature discovery but I had been working through a rough plan that would have resulted in a path forward. I felt it was important to document that plan, showing where I had left off and where the next team might pick it up and continue. I tried to anticipate and answer questions they might have such as:
- How far into this effort did the previous team get?
- How would they have scoped the work, knowing what they knew at the time?
- What were the dependencies if any that would guide the order of the proposed work?
- Did they identify technology limitations that would have dictated what was feasible at the time?
Preserve the notes in a convenient, accessible place
An obvious measure perhaps but I did not want to make it hard for the next team to find my notes. At the moment, our team uses Confluence for capturing early product discovery work. It is hard to believe that we would have moved on to another tool but anything is possible. So I made sure to create prominent links to the repository from Trello, the tool I use to corral Executive input; from Slack, the new tool of choice for our Dev Ops and Customer Support teams; and in the primary email thread we had been using to communicate with the original customer.
The impact
Part of me feels that there was some wasted effort both in the original work and the steps to wrap it up for a future phase. But that feeling is not as strong as the one that is happy not to have invested even more time building a feature that may have been excessive or unneeded.
With a pay-it-forward mindset, I tried to think about helping the next PM to inherit this feature as I went through these steps. I know I would appreciate someone doing the same for me. And if it is me that opens the product feature time capsule down the road, I promise to be kind to my former self when writing up that experience.
Look for more reports from theProductPath around product teams, feature prioritization, and product investments here on PM Decisions.
In a dauntless attempt to answer the near ubiquitous question, "What does a Product Manager do?", I decided to dedicate an entire year to recording and sharing my own journey down the product path.
The Product Decision: Contribute to the growing body of knowledge by sharing weekly accounts of my on-the-job product experiences as the Head of Product for a late stage startup.