
Ask HN: How would you create a project roadmap and with which tools? - akendo
I need to create a roadmap, however, I dislike the tools out there and was wondering about a more &#x27;hacker&#x27;-like way of creating a roadmap. Any suggestion?
======
tjomk
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.getshipit.com)

\- [https://www.productboard.com](https://www.productboard.com)

\- [https://www.productplan.com](https://www.productplan.com)

\- [https://craft.io](https://craft.io)

\- [https://www.prodpad.com](https://www.prodpad.com)

------
muzani
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](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](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.

------
beaconstudios
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/](https://www.productboard.com/)), if it fits
your requirements - I've made good use of it in the past for product planning.

------
lucasverra
[https://news.ycombinator.com/item?id=22092167](https://news.ycombinator.com/item?id=22092167)

------
apineda
I haven't yet used it but its on my todo: roadmunk.com

------
bobwaycott
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.

~~~
akendo
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?

------
smarri
Spreadsheet

