The average engineer is quite capable of applying their capabilities to a diverse amount of tasks. Despite this, there is one widely known that is difficult for most to confidently grasp. This of course being product management and development. Ask anyone in project management or development, hired a freelance developer, or worked in agencies, they’ll probably say the same thing. Honestly, I had this problem as well.
Over time, and a few failed projects and client relationships, I got a better handle on things. Of course, there’s the occasional hiccup when conflicting working styles clash, but overall it’s now one of my strengths. In this article, I’ll be sharing a few of them to help you better navigate roadmap development as well.
Have Feature-Based Milestones
Nonengineers view progress completely differently from engineers. The more seasoned and technically inclined the engineer is, the more likely, the difference becomes greater. I say this because less capable engineers look to get things done, without much thought for infrastructure. While more experienced and capable engineers don’t look at just individual tasks, they focus on strong infrastructure to build a solid foundation and remove problems in the future.
This is a natural problem because, in essence, the communication of progress is broken. Solving this with feature-based milestones is suitable because it melds both viewpoints together. An engineer is able to break things out into shippable features, while still building infrastructure as he goes, and giving nonengineers the ability to see things moving.
Have Clear And Actionable Ticketing
Having no form of ticketing platform is impossible. Every project at any level relies on properly written planning in some system similar to Jira or Trello. While some people think of these platforms as a stressful addition, they do serve a purpose quite well. In fact, when used more purposefully, they can be a great key in better roadmap planning.
To do this, I’ve developed a straightforward system that is easy to understand and practical to follow. It can be broken down as follows:
- Begin with a top level story ticket that summarizes what needs to be done
- Under the story, create associated task tickets that accuratly define the work needs to be done
- Properly link tickets that rely on another to be completed before work can begin
See, very simple and to the point, while also giving us clear insight into complex solutions.
Ensure Everything Is Associated To The End Goal
Losing focus happens, and unfortunately, most of the time it’s at the detriment of the project. Scope creep, misestimation, priority shift, or anything possible that might can come up, are all examples of what possibly could lead to this misdirection. In the end, the only thing suffering is the project, from that probably some job security as a side effect as well.
The key here is pretty straightforward. Keep your blinders on, and reel in anything that distracts from the end goal. There is nothing wrong with fast follows or iterative releases. Anything is possible as long as the main goal is accomplished.
In Closing
Roadmap planning is hard and takes time to get an understanding of the best way to do it. As engineers, we’re not taught this side of the business, and depending on the size of the company, you’re not really expected to for most of your career upbringing as well. So with that, hopefully, these few keys are helpful for you and you can better your career with them as well.