When you join a company, you do not just get a job.
You get an inheritance. And, let me tell you, most of it is broken.
You get a lot of legacy code, yes. A collection of different, strange old functionalities. Often, no one truly knows how the whole thing works, but now you are supposed to support all of it. This is the tangible part of your inheritance. But you also inherit something less visible: the roadmap. The history. The vision.
I was once ignorant, perhaps even scared, of real discovery work on a platform team. It is easy to be like this. You join, they hand you the keys to a kingdom of undocumented features, and they point you towards a pre-written future.
It is a simple process. You talk to your chief, to some colleagues. You take over the old roadmap. Your work is planned for the next quarters, maybe even a year. This is a very easy job, to do it this way. You are just executing a plan. The work is packaged and planned in advance, and you are the one to deliver it. Economically speaking, this is where your learning curve flattens. A considerable number of jobs are not that challenging; let's be honest.
But then, you start having the discovery calls (if you do XD).
Many people, after they read the book by Teresa Torres, they think they understand discovery. I have to admit that only a few do.
The majority is just using this word - discovery - to hide their old requirements collection process. This is requirements theater, nothing beyond it.
They are not asking the real questions, not thinking about outcomes. They are just collecting a list of demands. It is a very convenient way to hide behind the word value, even though you have no analytics in place, no real metrics. In truth, you have no idea what the value is. You are just guessing.
If you’re not asking 'What problem does this solve?' and 'How will we measure success?' - you’re not doing discovery. You’re just making a list.
But real discovery, when you do it, is dangerous.
The more you talk to your real users - the other teams, the other engineers - the more you may realize something deeply uncomfortable.
I remember once, I got a "performance optimization" project that, after digging in, turned out to be built on a deprecated API. Six engineers had spent months on it. The worst part? Nobody actually needed it anymore.
You may realize that the entire vision that was being worked on for the past two, three, four quarters… actually didn't make any sense.
That historic track, that previous product roadmap? Yes, it might have been useful in the past. But at this point of time, it is irrelevant. The problem it was solving is gone, or the solution is no longer the right one.
This is the moment of truth.
The hardest moment in product management isn’t saying 'no' - it’s realizing that the last year of work was wasted because no one asked the right questions.
So now it is your choice, and your battle.
Do you really want to pick that enemy? Do you want to challenge yourself and actually turn the things for the good, by making the point what is relevant now?
It is up to you. You can either stay with the current take of things and actually do nothing, or you can make a few enemies and do the actual work.
I have encountered this many times. The CPO, the majority of tech people, the other product managers - they have this unconfirmed, very biased opinion about certain things. To show them the way, to show them the real priorities, it is quite difficult.
Because some people just can't take the fact they are wrong. This is extremely hard for some, especially the arrogant types. For them, when you show with data and interviews that their pet project is a waste of time, they do not see a professional discussion about priorities.
They associate this with a personal attack. Nothing else.
This is the real inheritance. Not the code, not the roadmap. It is the choice between the easy path of complacency - where your professional challenge level diminishes daily - and the hard path of integrity. A choice that defines your value far more than just executing on a dead plan.
So, what do you do? Start small.
Pick one "sacred" project and ask:
What problem does this actually solve?
Who told us this was important?
How will we know if it worked?
If the answers are vague, you’ve found your first fight.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.