Ask HN: How would you create a project roadmap and with which tools?
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?
8 comments
I considered this for a long time, but I found bullet points work best.
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.
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 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:
- https://www.getshipit.com
- https://www.productboard.com
- https://www.productplan.com
- https://craft.io
- https://www.prodpad.com
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
Like a product roadmap?
You 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.
You 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.
I haven't yet used it but its on my todo: roadmunk.com
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, for the roadmap itself, I start looking through what I've documented so far, and I start thinking about the order in which I need to build things at the small level to begin building out the various domains up to the high-level. If there are common components used by various different business domains, those typically warrant being built out first. If there are independent domains, it can be a toss up—and the goals of the project and its stakeholders, as well as ideas about releasing in phases or all at once will inform how to pick which independent domains to build out before others.
5. I often review the linear, ordered outline a few times, and there are likely to be changes. But ultimately, reviewing is meant to ensure that you can read from the beginning of the development roadmap and follow that outline like a checklist, with the final product naturally resulting at the end.
6. Final step is to then go through the linear, ordered development outline and start putting time estimates on it. As you move from the earliest items in the list to the later items, expect the time to increase if the project is sufficiently complex. You will encounter challenges and things you did not anticipate or plan for as you start bringing all the pieces together.
Finalizing the Roadmap:
There should always be a roadmap for me and/or fellow tech/design team members, that may not be communicated to business or client stakeholders—this master roadmap is almost always in Markdown form. I often build it out as a Markdown document per domain. This allows me to create an overview document that links off to all the various domains if I'm keeping the roadmap itself inside the project (and perhaps linked via a git repo README). This usually gets turned into issues for each of the functional domains and their various subdomains, with checklists for all the relevant details to guide high-level feature development tracking.
There is often a roadmap that must be communicated to clients and/or business stakeholders. I typically take all the work done in the Markdown master roadmap (that can have checklists, links, notes, technical details, and so on), and I start trimming that down into a single text document via word processor. The vast majority of the content is focused on detailing out the business domains, their important subdomains, but it usually doesn't document the most technical details—especially if the stakeholders are non-tech people. The domains and subdomains are documented along with total time estimates from the Markdown roadmap, and usually include not only a brief technical overview of the domain/subdomain, but why it's there and what it accomplishes (reflecting back to the stakeholders how it achieves their goals).
tl;dr — text editor, Markdown files, break down the project into its constituent parts, order those parts according to how they build on top of each other to create a product, add time estimates once you've ordered the development processes, and then create a final version that is appropriate for the receiving audience.
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, for the roadmap itself, I start looking through what I've documented so far, and I start thinking about the order in which I need to build things at the small level to begin building out the various domains up to the high-level. If there are common components used by various different business domains, those typically warrant being built out first. If there are independent domains, it can be a toss up—and the goals of the project and its stakeholders, as well as ideas about releasing in phases or all at once will inform how to pick which independent domains to build out before others.
5. I often review the linear, ordered outline a few times, and there are likely to be changes. But ultimately, reviewing is meant to ensure that you can read from the beginning of the development roadmap and follow that outline like a checklist, with the final product naturally resulting at the end.
6. Final step is to then go through the linear, ordered development outline and start putting time estimates on it. As you move from the earliest items in the list to the later items, expect the time to increase if the project is sufficiently complex. You will encounter challenges and things you did not anticipate or plan for as you start bringing all the pieces together.
Finalizing the Roadmap:
There should always be a roadmap for me and/or fellow tech/design team members, that may not be communicated to business or client stakeholders—this master roadmap is almost always in Markdown form. I often build it out as a Markdown document per domain. This allows me to create an overview document that links off to all the various domains if I'm keeping the roadmap itself inside the project (and perhaps linked via a git repo README). This usually gets turned into issues for each of the functional domains and their various subdomains, with checklists for all the relevant details to guide high-level feature development tracking.
There is often a roadmap that must be communicated to clients and/or business stakeholders. I typically take all the work done in the Markdown master roadmap (that can have checklists, links, notes, technical details, and so on), and I start trimming that down into a single text document via word processor. The vast majority of the content is focused on detailing out the business domains, their important subdomains, but it usually doesn't document the most technical details—especially if the stakeholders are non-tech people. The domains and subdomains are documented along with total time estimates from the Markdown roadmap, and usually include not only a brief technical overview of the domain/subdomain, but why it's there and what it accomplishes (reflecting back to the stakeholders how it achieves their goals).
tl;dr — text editor, Markdown files, break down the project into its constituent parts, order those parts according to how they build on top of each other to create a product, add time estimates once you've ordered the development processes, and then create a final version that is appropriate for the receiving audience.
Thank you for this great answer! This was helpful and went into the direction of my current developing work flow.
Do you use any type of visualization of your results in?
Do you use any type of visualization of your results in?
Spreadsheet