For quite some time I dealt with pain in my feet due to plantar fasciitis and it wasn’t until a few months ago that I finally fully recovered from this injury. The difference between the last few months and the prior time period was that I learned that the cause of my pain was not where I felt the pain, but rather due to tightness in my hamstrings. This was hard to believe because my hamstrings felt fine, but as I learned more about this particular injury it was plausible that this was the root of the issue. Armed with this new information, I began to incorporate daily hamstring stretches into my daily routine. Within a week I started to feel a slight improvement and after three months the pain has completely gone away. Before I knew that the issue lied with my hamstrings, I spent a lot of time targeting remedial solutions at the point of the pain. I would stretch my feet, massage them, and even bought sneakers with more padding thinking that this would help alleviate the pain. Unfortunately, in the long run there was little to no benefit from those efforts.
In hindsight, I wish I had spent more time understanding the actual potential causes of this issue as it would have saved me time and money because I would have been able to implement better solutions from the moment I started experiencing discomfort. When I think about this injury and my path to recovery it is hard for me to ignore the parallels with this experience and the similar experiences that I have had as a product manager on software development teams.
As such I want to share some flags that you can look out for that are strong indicators that your team is experiencing pain in one area, but most likely the issue lies elsewhere. Furthermore, I want to give you some tips on how to resolve those types of issues.
The following issues usually indicate that the root of the problem often lies elsewhere:
Unexpected consequences or reopened defects from feature or bug changes
Flip-flopping of product requirements
Unexpected consequences or reopened defects:
Pain area:
The team frequently experiences unexpected issues due to a new feature enhancement or a defect fix which then leads to fire fighting and additional development work.
Actual problem area:
In my experience the common culprit of this issue is lack of team understanding of how a portion of the work impacts the broader body of work. This gap in understanding leads to unexpected consequences when those portions are introduced to the system.
Resolution:
It is critical to bridge the gap of understanding among all team members from design, to engineering, to QA. Maintaining up to date user journey flows and architecture diagrams help provide visuals that allow one to understand the impact a change in one area can impact the other areas of the system. Reviewing these documents prior to beginning work on a feature helps ensure that the different paths of a solution are accounted for in design, implementation, and testing which then begins to reduce the frequency and impact of unintended issues as the team broadens their awareness of the whole system.
Flip-flopping product requirements:
Pain area:
The same feature(s) keeps getting re-worked and progress on the other items stalls as the team keeps revisiting the same items.
Actual problem area:
In my experience this issue often lies between the stakeholders and product and design. When we produce solutions that are half-baked, meaning that those solutions do not fully meet the needs of the business then you are likely to find yourself re-working the same aspects of the application.
Resolution:
The best way to prevent this issue is to be rigorous with the solutions being presented to stakeholders during the design phase such that the feedback process elicits as many possible issues with the proposed solutions so that when it is time for implementation the proposed solution has undergone sufficient iterations to capture and resolve as many possible unknowns prior to implementation.