I need to create a roadmap, however, I dislike the tools out there and was wondering about a more 'hacker'-like way of creating a roadmap. Any suggestion?
I've been doing this for well over a decade, and I still rely on a text editor and Markdown for nearly everything. My process is roughly as follows, and has over the years evolved into adhering pretty closely to domain-driven design principles and practices (before I stumbled upon the phrase itself and read up on it further):
Prep Phase:
A lot of conversation with stakeholders in the project. My job is overwhelmingly to ask questions, to understand what all the stakeholders are wanting to accomplish with the project. This is the most critical phase of developing any kind of reasonable and accurate roadmap. I say what they want to accomplish, and not what they want the software to do. These are not the same thing—especially if the stakeholders are not tech people. I typically work on new projects (from scratch) that are going to run business operations. In talking with stakeholders, they often have different individual needs and goals for what they're trying to accomplish regarding business processes, productivity, profitability, efficiency, etc. You need to understand what each of the stakeholders is trying to accomplish, what goals they have in mind that they believe software to be the answer to. My job is to translate their goals and individual accomplishment metrics into something that software can facilitate.
Rough Roadmap Phase:
1. I start by dividing the stakeholder input into what seem to me to be relatively logical and separated business domains. This is a high-level grouping of related concepts, features, and functionality that can be directly tied to and communicated about in light of one or more stakeholders' goals. The primary goal for me in this part of the roadmapping phase is to name things—if a group of people are going to be talking about a project a lot, it's going to need to be discussed with everyone using the same terms. This can be as simple as do we call users of the software users, clients, customers, or something else? Ensuring everyone in the project is talking about it using the same language is, in my opinion, critical to success, and helps the project start to take shape in non-tech people's minds before there's even code written.
2. Once I have the broad shape and some rough initial names of different business domains, I then dive into each of the domains, fleshing out their details. This is where I'll start detailing out various functional components of the project as they live inside a domain. I can keep it high-level at first, but eventually, I will start breaking things down inside a domain with increasing detail. That could mean I start moving toward defining the roadmap in terms of the tech that will be used to build it—for example, I may start naming some different modules or classes, depending on whether a functional or class-based language is being used. I don't necessarily go down to the level of naming functions here, as it's outside the scope of a roadmap at this stage.
3. When I feel like I've finished detailing all the critical components and functionality within a single domain, I repeat step 2 on each of the remaining domains. Sometimes, as I'm detailing out the shape of another domain, it helps me realize I missed something in another domain. There can be quite a bit of hopping around, but eventually, the domain map of the entire project starts taking shape.
4. When all domains have been sufficiently detailed, it's time to start looking at shaping these details into a project roadmap. Assuming a project roadmap is the deliverable handed to stakeholders that will guide development, it's critical that the domain map is turned into a linear time-focused outline. By the time I've reached this stage, I now have a very solid idea of what we're building, and I've created a whole domain language around the project itself. I've detailed out all the various domains, and I should know how they depend on each other. So...
It's legible enough. Information is clustered into relevant groups. You can see progress by the colors on indents. You can also ctrl+f to whatever you want to search.
I doubt there a cli or "hacker" ways of creating a roadmap. For a dead simple roadmap you just need a bullet point list with the items sorted in the order you want to crack them.
I do some personal goals and plans for the year in Evernote, which is to say, not a hacker way at all. But it works and I just need to sync between 2 devices.
Trello, Spreadsheet, and Presentation are another good way to build a roadmap. Again, far from being a hacker way but it works with small teams. In fact, it also works for huge companies. I've seen powerpoint used for building roadmap in a 2K+ person company.
Finally, the least hacker way but probably the most comfortable (when you know exactly what you need) is to use existing tools made for this specifically:
8 comments
[ 2.8 ms ] story [ 35.0 ms ] threadYou could try sticky notes on a whiteboard, they're easy to rearrange while you're shaping the roadmap and give you a good high-level overview.
Productboard is quite good (https://www.productboard.com/), if it fits your requirements - I've made good use of it in the past for product planning.
Prep Phase:
A lot of conversation with stakeholders in the project. My job is overwhelmingly to ask questions, to understand what all the stakeholders are wanting to accomplish with the project. This is the most critical phase of developing any kind of reasonable and accurate roadmap. I say what they want to accomplish, and not what they want the software to do. These are not the same thing—especially if the stakeholders are not tech people. I typically work on new projects (from scratch) that are going to run business operations. In talking with stakeholders, they often have different individual needs and goals for what they're trying to accomplish regarding business processes, productivity, profitability, efficiency, etc. You need to understand what each of the stakeholders is trying to accomplish, what goals they have in mind that they believe software to be the answer to. My job is to translate their goals and individual accomplishment metrics into something that software can facilitate.
Rough Roadmap Phase:
1. I start by dividing the stakeholder input into what seem to me to be relatively logical and separated business domains. This is a high-level grouping of related concepts, features, and functionality that can be directly tied to and communicated about in light of one or more stakeholders' goals. The primary goal for me in this part of the roadmapping phase is to name things—if a group of people are going to be talking about a project a lot, it's going to need to be discussed with everyone using the same terms. This can be as simple as do we call users of the software users, clients, customers, or something else? Ensuring everyone in the project is talking about it using the same language is, in my opinion, critical to success, and helps the project start to take shape in non-tech people's minds before there's even code written.
2. Once I have the broad shape and some rough initial names of different business domains, I then dive into each of the domains, fleshing out their details. This is where I'll start detailing out various functional components of the project as they live inside a domain. I can keep it high-level at first, but eventually, I will start breaking things down inside a domain with increasing detail. That could mean I start moving toward defining the roadmap in terms of the tech that will be used to build it—for example, I may start naming some different modules or classes, depending on whether a functional or class-based language is being used. I don't necessarily go down to the level of naming functions here, as it's outside the scope of a roadmap at this stage.
3. When I feel like I've finished detailing all the critical components and functionality within a single domain, I repeat step 2 on each of the remaining domains. Sometimes, as I'm detailing out the shape of another domain, it helps me realize I missed something in another domain. There can be quite a bit of hopping around, but eventually, the domain map of the entire project starts taking shape.
4. When all domains have been sufficiently detailed, it's time to start looking at shaping these details into a project roadmap. Assuming a project roadmap is the deliverable handed to stakeholders that will guide development, it's critical that the domain map is turned into a linear time-focused outline. By the time I've reached this stage, I now have a very solid idea of what we're building, and I've created a whole domain language around the project itself. I've detailed out all the various domains, and I should know how they depend on each other. So...
Do you use any type of visualization of your results in?
My benchmark is Dwarf Fortress: http://www.bay12games.com/dwarves/dev.html
It's legible enough. Information is clustered into relevant groups. You can see progress by the colors on indents. You can also ctrl+f to whatever you want to search.
I personally keep something that reminds my why I'm doing it so I don't drop off: https://random-character-generator.com/whatisthis.html
then I put the actual short term changelog on a page of its own for those who are interested in that.
If you need deadlines and dates, it's quite trivial to add.
I do some personal goals and plans for the year in Evernote, which is to say, not a hacker way at all. But it works and I just need to sync between 2 devices.
Trello, Spreadsheet, and Presentation are another good way to build a roadmap. Again, far from being a hacker way but it works with small teams. In fact, it also works for huge companies. I've seen powerpoint used for building roadmap in a 2K+ person company.
Finally, the least hacker way but probably the most comfortable (when you know exactly what you need) is to use existing tools made for this specifically:
- https://www.getshipit.com
- https://www.productboard.com
- https://www.productplan.com
- https://craft.io
- https://www.prodpad.com