[product] Can a good product originates from bad business requirements?
The short answer is yes. The long answer is, well, a bit longer.
I had a one to one with one of my smart product managers, and we were commenting on a product initiative we had to do out of some immediate business requirements. This made me think.
Despite how much they want to tell themselves the story of Agile Development and how much they invest in lean processes and training, most tech companies out there are very “waterfall.”
There is something I firmly believe in, and it is that “every human effort without predictability is not a job; it’s a hobby.”
Every company is in the market to create value — value for the users if they are virtuous ones or value for the shareholders in general. This requires predictability.
One of the easiest ways for leadership teams or boards of directors to generate predictability is to enforce a waterfall roadmap.When you receive the explicit mandate to deliver Projects A, B, and C by the end of the quarter, and you agree with the terms, then you are creating predictability.This refers to predictability about when the projects will be delivered and when the business will be seeing the impact.
There is nothing strange or wrong with this; the reality is just that you are killing most of the creativity in your people.
The point I am trying to make is that even if you start a project for the wrong reasons, it does not mean you have to do it in isolation and without trying to create value for the directors and the users.
My real life example perfectly fits the scenario above. We received a clear indication from the business that a specific feature needed to be delivered before everything else in the pipeline. This meant that we had to force people to context-switch and create a lot of “inventory.”
In my experience as a product manager, you have two ways of dealing with this: pushback to protect the initial priorities for the quarter or implement what was requested in the fastest way possible and then return to the core projects that were already planned.The balance between when you adopt the former or the latter is the key to success.
As a business person, you should understand the business needs that generated the urgency, but you must highlight the cost. Every change in priorities and every product decision comes at a price.
The moment the cost becomes transparent for the stakeholders then even the waterfall decision makes sense, or “-ish.”
As product and business persons, we should always clarify the tech, product, and UX cost of changing priorities, and it is our responsibility to make a great product out of debatable business priorities.
