PM, Devs, and the strategic bits and pieces
Not all PMs understand Devs. Some focus too much on customer needs, market trend, and business success, ended up overlooking the code quality, technical debt, performance, and new technologies.
The reverse can also be true.
Not all Devs understand PMs. Some delve too deep into problem-solving, innovation, processes, and code ownership, forgot to align themselves with the organisation’s strategy and goals.
This can be fun at times, when we help each other out, bring each other up. It can be a struggle as well, when a solution cannot be agreed on the table.
There are plenty of advices telling you how to solve it. But the fact that matters is, what is there to solve? Solve, as in Devs can direct strategies and PMs can monitor code efficiency? Or, we understand each other and the imperfection of us humble homo sapiens, so let’s try to work together.
The truth may lie somewhere in between.
Maintenance vs. discovery
Today, I couldn’t get Devs’s agreement to pull a ticket into the maintenance backlog. A 20 mins discussion splattered everywhere:
- This is not maintenance.
- If this is maintenance, then that one and that one and my neighbours and their dogs are all maintenance.
- You put this in maintenance because it’s not important enough comparing to other features.
- If we put everything in maintenance, then maintenance becomes meaningless, and so is planning.
- We must respect the process.
- If this is “really” critical, prioritise it higher than the other features.
- Prioritise this against features or no deal.
When I see it from Devs perspective, everything they meant was correct. It’s no use sitting in a stalemate with the team. As a PM, I’m in the position to step back and make a justified concession.
But was it really that much about maintenance?
- We are running a legacy solution while a new solution is ready.
- The legacy solution causes pain to our Devs and frustration to our customers.
- I’ve initiated the plan to migrate customers from legacy to the new. On the business-side, it’s progressing.
- On the technical side, to ensure smooth migration, we need one particular functionality to work. And the disputed ticket is the key.
- Without it, though the migration can still be done, sales motivation and data quality will take a hit.
The ticket came directly from the customer, fortunately. And the Devs know what to do. No need for product discovery. Unfortunately, a batch of other improvements came with it the same time, which Devs have grouped together in an Epic. Their expectation is that I prioritise this Epic against other features.
I believed the most responsible option was to pull those tickets into maintenance, especially the key one, to ensure it gets into an active Sprint soon.
Let the process serve the strategy, not undermine it.
There’s no perfect way to approach maintenance. But we could try to let the process serve the strategy, not undermine it.
On product discovery or feature level, like every company, we have multiple objectives derived from ambitious strategic goals. These objectives compete with each other when they were born. Thus we collect evidence, run discovery, do prioritisation, stay focused, etc. Objectives fall out of the priority list; Objectives get added to the list. Nothing special, common product management.
The truth that matters is, for everything that gets developed, there’s something that’s been traded off. And it never means that those are “not important enough”. Prioritisation is often misunderstood. Many imagine a group of managers with a warm cuppa, graphs and reasons, banters and laughters, making the perfect prioritisation list. But typically they are long meetings where innovation and debt, new feature and refactoring, all stumble on each other, with over a decade of customer data as the icing on the cake.
I couldn’t prioritise the Epic against other objectives like the Devs expected, cuz I know it will fall out of the list. So was I deceiving the process? Agile and product management purists may accuse me of violating frameworks. And all the management principles I studied at business school will haunt me tonight for disregarding the basic rules. But the nearly philosophical debate of what is maintenance was overshadowing the product, which became the victim of the process.
Now that I have all the time to reflect. Let me hear what AI has to say.
We are like Messi and Suarez.
10 out of 10 times, I’d tell you that working with Devs is a joyful part of the job. It still is. To see them solve problems and innovate is a wonderful experience. But nothing really competes when they are interested in the strategy and planning.
The strategy of migrating customers from the legacy solution to the new was shared with Devs not long ago, the very first draft, before I presented it to anyone else. To me, this is something not just for customers, but also for our Devs. Their feedback was everything. Thus, there was a moment of grievance today, when the Devs were fixated on the process instead of the outcome, and were against it instead of backing it.
In hindsight, I could have done many things differently, cuz after all, PM and Dev are one — either of us can only ever achieve any outcome by working together. It’s like Messi and Suarez. The entire FC Barcelona may look to Messi to score. But Messi will look to Suarez to give the right passing. They get frustrated at each other at times. And they’re back to work together as an A-team. And it goes on like that.
Finally, let’s hear what AI would advise to effectively listen and communicate with our Devs.
