The Trouble with Product and the Art of Pushing Back
(I am still working on this ok… Not a completed post yet)
I am just randomly jotting down some thoughts from my latest role in really being a Product guy drowning in a massive backlog of requirements and features. I’ve been in “fintech” for over 10 years now, working on a wide spectrum of stuff related to it. At the end of the day, the process is very much like everything else you do in life. So I’ve learned a few things I’d like to share.
Pushing back on business requirements
Technically, nothing is impossible to implement. So when your business stakeholder comes to you and says I want a pink button, instead of a blue button that is standard across all templates, will you do it for them?
Of course you can do it, it’s just a simple color change after all. But should you do it? The answer is, you need to find out WHY they want to do this, and evaluate whether your current resources will make sense for you to do it. Current resources include how soon they want it, determining how much time you have, the people to work on this, and any other costs involved.
So if and when you decide that it would not make sense to take up the request, you have to push back. That is not to say that you should just tell your requester a big NO. It should come along with a reasonable explanation. This explanation should NEVER be from a technical angle. Because like I said, technically, nothing is impossible.
One of the major reasons why a request cannot be justified is often because there is no benefit or good enough utility to it. In this example, the requester may only want the pink button because they believe their users prefer the color pink. Or, the color pink somehow provides ease to the requester. Other than that, if the button was blue, the core function of it will not change and the result of action will still be achieved.
So you never tell them that you can’t do it because it’s hard for the team to do it. You tell them you can’t do it because there is no need for THEM to have it.
The myriad of real life requests I’ve pushed back include,
- data validation in forms (is there any downstream impact?),
- changes in the order of design layout (is the user not able to find what they need now?),
- performance dashboards (what metrics do you really need? what do you want them to tell you?),
- complex dropdowns (do you really need info in such a granular level?)
Pushing back on developers and the pitfalls of agile
Very often, devs tell me we are using an open source tool and the more customization is done, the harder it becomes to upgrade that tool in the future. Same goes with any standard templates in any platform. You steer away from it, then any changes you do will require extra effort because it’s not automated.
The accountability of agile. Semi waterfall/agile model
Pushing back on your boss (not suggested)
Of all things you need to juggle, prioritize, and push back on, the last thing you should ever do is pushing back on your boss. In what circumstances is this valid, and how should go about it?
Be convincing and have support from all angles
