Okay, engineers are now supposed to evaluate the roadmap to strategic goals. in principle all good that everybody is involved in lining up with strategy. But the caveat here is, the CPO and leadership team should do this. And if this does not resonate with the engineers, is it really wise to educate the product manager by sending him/her some literature on how to do strategy?
I would suggest to handle this if this occurs with more care. And also consider that many very successful companies did not have a written mission and strategy, it is usually introduced in the scale up phase when stakeholders demand more on the why and how.
The problem is that product owners and managers are not learning software engineering to better communicate, design etc., This is a one way street, engineers have more and more non-technical responsibilities until they are barely coding and then are forced to manage a team of junior engineers to do the code for them.
> This title is not currently available for purchase - Have you moved recently?
Apparently this book did not pass the Dutch or Amazon censor. Makes me extra curious.
In my experience, if you don’t have a smart lead engineer who is working directly with the product people and is involved with the higher level roadmap then life is more difficult for engineers. There needs to be someone advocating for engineering needs and setting the correct expectations about what reasonably can be built and at what cost. If engineering isn’t involved, then there ends up being this toxic one-way relationship where engineers are just receiving marching orders from someone else who might not know what is impossible or who might not have the technical vision to dream of what might be possible.
If an engineer really goes and thinks they should evaluate a roadmap like this, that's toxic.
If the answer is "very few" then that might be an early warning sign you're working for a product or org that is headed for serious problems. As a technical IC who can't hope to solve those large scale management problems, this can be useful a red flag. Don't wait for shit to hit the fan to leave.
I have seen a large scale failure of this kind and the items listed here line up very well with some of the root causes I observed.
- Is the roadmap flexible or iterative? The roadmap was hard, aggressive business targets.
- Are the roadmap initiatives scoped and prioritized based on evidence? The roadmap initiatives were derived by working backwards from business targets and then evidence was found after the fact.
- Does the roadmap identify major dependencies or risks? Many risks were identified much later because techincal teams were not part of input to initial planning.
- Does the roadmap feel aggressive but achievable? Aggressive but not physically possible.
- Does the roadmap take on appropriate risk? No, there was multiple possible independent points of failure.
Anyways, if you ever see this kind of product culture I suggest running for the hills unless you like having your time wasted. And if you are a technical manager I hope you push back like hell when presented with this situation.
The thing that I don't expect is that the roadmap would stay static. Reality changes over time, you encounter new customers and opportunities, learn what's harder or easier than you thought, etc. So I would say "this is what we have today" and if that evolves somewhat even a few months down the line as we learn more, great. But at any given point, you should be able to articulate your best understanding in something that does hit against these checkpoints.
But if it's say in the next few months we better have a good stab at what the MVP or the next iteration and the initial market could look like.
I also agree that low-level teams might be very far removed from strategy, especially in large orgs. However, that team should have a clearly defined goal or mandate instead. So much of the product is context-driven, and the first few drafts were 3-4x longer to account for these differences between organizations, hierarchy, teams etc. I removed most of that to focus more on basic principles because this guide was starting to look like it was written by Charlie Kelly chasing Pepe Silvia accounting for all the edge cases :)
One piece of advice I’ve learned the hard way, however, is if the road map doesn’t make sense, it’s unlikely that making noise is going to make your life better.
I was reminded by this article of the time when my role as a PM was stymied by a lack of clear corporate strategy - I was told to make a road map without the support of any kind of goal or vision, told even that having a strategy would take “11 weeks” (yeah, an oddly specific number). Of course, I pushed back - but the outcome of doing so was very poor for me.
A road map doesn’t need to perfectly align with the very good points in your article, but there is a point at which it’s probably just better to cut and run.
That's in the realm of dreams, unless you're starting totally fresh, and have no dependencies at all.
The roadmap is not for the engineers to know what they are going to code next.
That comes through discussion and sprint planning in a tool that has tickets/milestones/epics etc.