coda.You have a team of designers, engineers, and product managers who are ready to work on a new product launch. The first thing you might do is consult a product plan or product roadmap. With this product plan example, you can save a lot of time and resources from having to buy expensive software for managing your team’s resource allocation for getting your product out into the market.
If you want to get started right away with the product plan and roadmap, copy
by signing up for Coda. Watch the video below on how to build this product plan from scratch:
What Is A Product Plan or Roadmap?
At a high level, a product plan or roadmap does the following:
Provides the guiding strategy for your product
Details the work required for your product
Evaluate how new features and functionality impact planned work
Do a quick Google search for a product plan or roadmap, and you’ll come across platforms and software like the following:
If you read my previous post about picking
, you’ve probably noticed I prefer to build my applications rather than work within the constraints of a piece of software. Nothing is wrong with purchasing software that does one thing really well, but your product might take twists and turns during the development cycle that your software was not built to handle.
Instead of relying on someone from the software company’s support desk to help you tweak something about the software, let’s see how we could build a product plan or roadmap from scratch in 15 minutes or less in Coda. The 3 main tables we need to build to make this app work are:
— Stores all the people on our team and their roles/skills
— All the product features we will build
— How our people will be staffed to work on the product features
Start With Your Team
Before we get into features, resource allocation, and effort, we need to identify who is going to work on this product. This probably means a mix of Engineers, Designers, and Product Managers.
In the table above, I have 3 columns:
column is a People
in Coda allowing you to select all the teammates in your domain. Where does the
select list that contains the options Engineer, Designer, and Product Manager come from? I created a separate “Team” table that just has those 3 options as the
You’ll notice that the
column in the “Team” table contains all the team members from my “People” table correctly assigned to their respective roles. The formula in the
column of the “Team” is:
=Lookup(People, Role, thisRow).People
This formula does a lookup to the “People” table, finds the rows where the
in the “People” table matches the current row in the “Team” table, and just brings back the
column. It’s kind of like doing a
in Excel except you can return
from your Lookup table instead just one value. The
column in the “People” table let’s you select what skills your teammates are good at, and the values for this select list are determined by a small one-column table called “Skills”:
Now that we have the basic tables for our team (“Team”, “People,” and “Skills”), it’s time to build out two more tables:
. Then we’ll have the tables we need to create our own product roadmap application that is flexible and customizable to our team and product launch.
Features In Your Product Plan
This is the master list of where your team can store all the specific product features you want to build and launch. Some of the columns we are going to add include:
You don’t need to have all these columns in your final product plan app, but you may find some of these columns useful depending on how you want to track resource allocation for your team. Here is what our final Features table looks like:
columns are in the Text format so you can enter free-form text here. We will revisit the
Effort per day
columns after we talk about our “Resource Allocation” table. A few things to note about the “Features” table:
represent the dates when the features should begin and end working. These columns are in the Date format which opens up the date picker to let you select the appropriate dates for your feature.
is a table formula that calculates — you guessed it — the number of business days between the
formula is used to get this number. This is one of my favorite formulas since it excludes weekends from the calculation.
Let’s move on to our final table:
Story Points Vs. Hours
This is an
in the agile world, and we don’t have an opinion on which method you use to estimate work for your team. The great thing about building your own product planning app:
you can pick whatever method of work estimation you want.
Our “Resource Allocation” table should do a few things:
Assign a team member to a specific product feature (from our “Features” table)
Give you the ability to entire in a work estimate (story points, hours, etc.) for a person
Associate feature start dates and end dates for a person working on that feature
As you can imagine, this table is tightly integrated with the “Features” and “People” tables. Here’s what our final “Resource Allocation” table looks like:
This looks like a pretty basic table, but let’s dive into each column to see how this table ties into the “Features” and “People” tables.
column is a
format that connects to the “Features” table. Once you create this column, you can select
of the features in the “Features” table. Want some more context about that specific feature? Just hover your cursor over the feature and you’ll see all the other columns from the “Features” table (e.g.
column is also a lookup but to the “Team” table we created when we created the “People” table. If you recall, the “Team” table also has a
column in it, so we can reference this column by writing the formula
. We use this formula in the
This means all the team members who have a job title of
in the “Team” table will show up as selectable options in the Assignee dropdown:
Finally, let’s take a closer look at some of the other columns like
. Since our first column — the
column — is a lookup to the “Features” table, we can also reference other columns from the “Features” table like
simply by starting our formula with
If we revisit the “Features” table now and look at the
column here, you’ll notice it references the “Resource Allocation” table in order to sum up the effort associated for a feature with the following formula:
column is also used in the “Resource Allocation” table as well (see the previous gif). You just built some pretty complicated logic to enter in effort at the team member level but also have the sum of the effort show up in both tables. If you had to get this same functionality in a spreadsheet, you would have to do a combination of
So we’ve built out our 3 main tables, let’s get into the fun stuff of
our data so we can see what features are being staffed by whom, which team members are being over-allocated, and where effort is being distributed among the team.
Product Feature Roadmap and Timeline
Let’s build a simple view of our “Features” table that hides a few columns so that it only shows the feature name, description, start date, and end date. When you create a
, it’s like creating a copy of that table but all changes you make in the view also carries over into the table as well.
While this view of the “Features” table looks ok, it would be a lot more useful if we could see a waterfall or timeline of how these features stack against each other. If we insert a gantt chart, Coda automatically looks at your start and end dates to build out the gantt chart:
You’ll notice that when you move the bars in the gantt chart, it also changes the dates in the “Main Features”
. This is a core concept in Coda where all your data — regardless if it’s in a table or chart — are connected.
Assigning Work and Estimating Effort
Now that you see how we can build views off of tables, let’s build a view off of the “Resource Allocation” table. With this view, we can group by the
column to quickly see the team members working on each feature in an organized way. If we change the number in the
column of our
, it changes it in the master “Resource Allocation”
Resource Utilization by Person
Nothing is worst than a team member who is overloaded, so being able to see utilization by team member can help you balance the load. The chart below is a view of your “Resource Allocation” table but the
is a stacked bar chart. You can quickly see who is being overloaded based on the total
that team member has:
Perhaps you still want to see how your team is being resourced in a table format, so you can build a view for that. One of my favorite layouts is the gantt chart broken down by person, so now you see a timeline by person but you can drill down into the features that person is working on as well:
Resource Utilization by Feature
Since we have our “Resource Allocation” master table built out, we can view our data in many ways. This is similar to how PivotTables work in Excel. In this view, we see a timeline/gantt chart broken out by features, but once we drill down we see the
associated with that task. This like the reverse of the gantt chart you see in the previous gif:
Resource Utilization by Team
Finally, a really useful view of our “Resource Allocation” table is grouping data by Teams. Since we have entered all the
for a team member and we have mapped team members to teams, we can get a bird’s eye view of the total estimated effort by Team:
If you recall our original “Team” table, it only had two columns:
. There are actually a few columns hidden in that table, so the view below, we
Avg effort / person
columns to see the total hours or story points each team has:
Avg effort / person
is a formula that takes the
and divides it by the number of people in each team (represented by a hidden
column. Now we can see that the Engineering team is clearly the team that is adding the most effort to this product launch.
Building your own product roadmap in Excel or Google Sheets can get complicated as your team grows and the features you need require extra customizations. On the flip side, if you buy a specialized piece of software to manage product planning or product roadmapping, you are constrained to that software’s own feature set.
There are many
for managing a project, and sometimes the most important part is focusing more on the process rather than the final product. By building your own application that looks and feels like a real product roadmap software (without needing to be a programmer), you can get the best of both worlds.
Find freedom on the canvas.
— Bob Ross