How to build a complete product story, in one view, and align your organization with ProductBoard- hands on
This article complements the previous one “aligning the organization with ProductBoard”. I hope you liked it, if you’re here, because I’d like to guide how to do it.
Before we dive in, let me add a theoretical, maybe controversial thought. Why this focus on the roadmap? Well, because the roadmap is what matters. If you have something outside the roadmap you really need to ask yourself why it matters. Now, roadmap is not only made of user-facing features, it includes tech debt, improvements etc. As a derivative of that statement, one of my biggest lessons was to not try to build your hierarchy in the product tool according to anything other than the constructs I described in the previous article, made ONLY of the things that matter.
Usual disclaimers:
1- I’m not a ProductBoard employee, not compensated by them etc etc. I am a product geek and I happened to use ProductBoard at the time I was looking for an awesome view that had the entire story, vision to features.
2- I’m pretty sure what I’ve done might not be a ProductBoard best practice. I took the tool and molded it to do what I needed. Hope they aren’t too unhappy with me now going and documenting the thing!
3- There are probably other, better ways to accomplish what I was trying to do. Also maybe with other tools. Dunno.
Quick reminder: The components of the “story” I wanted visible: Vision, focus (monthly and marketing events), product swimlanes, initiatives, features, notion of timing (I selected monthly granularity), and, of course, the linkage to the ticketing tool (can be Jira, MS etc.).
Cherries on top: I wanted to solve a couple more scenarios at the same breath:
1- Can we distinguish and create different views that include or exclude internal features and improvements? (YES)
2- [This one is really important, I may write a whole separate blog about it) Can we modify the weekly “scrum of scrums” from an unstructured stream of features to an outcome-focused, product led weekly meeting?
3- Can we enable PMs to see and manipulate the roadmap in a priority order?
OK, let’s get to work. Word of advice: Go deep on 1–2 initiative until you hit the end. On the path, collect your notes, tweaks etc. Then you can apply those to the rest of your process. Going wide before your go through the entire process once means that you will go back and have to reapply your tweaks many times.
Foundations (we’re now in the ‘features’ view):
1- Create a new product called “Roadmap” or whatever you like
2- Create the product initiatives under it as components
3- Create a feature under one of the initiatives. Note when you click into the description field, it will allow you to create or use a template. I highly recommend using this capability. Here are a few fields I highly recommend:
- Summary- the one liner what this is
- Problem- What problem does this solve and why we care
- Persona- who will use it
- Use cases- how will they use it
- Competitive- how solving this problem place us vs. the competition
- How to demo- Obvious
- Future improvement- what didn’t you get into this deliverable that you’d like to add in the future
- Discovery questions- what would you like your presales to ask to uncover the problem with your prospects and users
- UX/UI design: link to Figma
- Assumptions and limitations- obvious
- Metrics of success- What are 2–3 indicators, metrical and time bound, that indicate either this was delivered successfully or you need to go back and refine the experiment. For example: 5 users uploaded a file with this new method in the first week, growing 30% weekly in the next two weeks.
4- Connect ProductBoard to your ticketing system (Jira, MS etc.). Create a new dummy feature and send it to the ticketing system, then see that you can navigate back and forth, states change etc. The connection should be visible on the “Development” task in ProductBoard.
5- Set the tasks: Go to the tasks panel and add tasks for Problem Discovery, Solution Discovery and Delivery. Set all three to be visible at the view for features. Set “Development” to show in the view for subfeatures.
You should now see this view:
Let’s talk for a minute about the product conversation with R&D, and specifically the integration between the tooling. Here’s a simplistic perspective:
- A feature in ProductBoard is a high level construct that talks mainly about the business impact and the problem we’re solving. Hence, it does NOT have presence in the development ticketing tool. As you can imagine, a feature may have one or more solution alternatives (Experiments- a big part of modern product management).
- A ProductBoard subfeature is an experiment. A candidate solution to the problem. R&D are responsible to suggest experiments to a problem that was defined in the feature. Essentially, an EXPERIMENT is an EPIC (that later gets broken down into stories).
Please notice the following as it’s tricky: To save money, typically product managers have access to ProductBoard and not R&D. So, FEATURES are created in ProductBoard. How can R&D create constructs in ProductBoard without a license? They cannot. They create EPICS in the ticketing tool, Product managers create stub sub features under the features and IMPORT the epic to ProductBoard (see ProductBoard “LINK TO EXISTING”).
Lifecycle of a feature/subfeature in ProductBoard:
- A feature is created in ProductBoard (The WHAT and WHY)- Product manager. A product manager OWNS the state of the feature throughout.
- An Epic is created in the dev ticketing system (The HOW and WHEN)- R&D. R&D OWNS the state of the subfeature throughout. If this isn’t automatically sync’ed to the “Development” task state of ProductBoard, the Product manager may need to manually manage the subfeature state.
OK, what do we have:
- Product hierarchy: Product, initiatives, features (user problems), sub features (experiments)- tied to the ticketing system.
- Prioritization perspective: from users input, but can also add others
- We can see the progression of each feature, including the CDH components (problem/solution discovery and delivery), and we can see the ‘development’ progress of sub features.
Let’s go now and build the roadmap. One note: the following will include some constructs that might seem artificial. They are necessary to build this beauty though.
Let’s stay for another minute on the features view. Let’s add a couple things:
1- Go to “Releases” and add a new release family. I recommend calling it “roadmap” because it will facilitate the roadmap view. In Releases, add releases for each initiative, each month and each marketing event. Give all of them HIGH LEVEL TIMEFRAMES (in months).
You will notice that you can enter information on the releases, let’s do another “template” exercise: For the months, I would pick “Outcomes” and “Focus”. Outcomes means, what would we like to achieve in this month, and focus is the list of deliverables (no more than 2–3, very high level) that we should focus on.
For the marketing event, I have a slightly more evolved template, that you should align on with your product marketing manager:
Great. Let’s now start associating features with initiatives so they show on the roadmap. You will notice that each feature has a new field called “Roadmap Releases”:
Lastly, pick a timeframe for each of your features, month level.
Let’s go build the actual roadmap, we’re almost done. Got to the ProductBoard roadmap view. Pick a new “Release timeline” roadmap.
Name the new roadmap (top left; my recommendation: 2–3 words about the vision). Go to Settings and set as follows:
Set the swimlanes: My recommendation is
- Marketing focus: This row is the monthly calendar of marketing events and announcements
- Month focus: what is the focus for Product and Dev
- Core: The core components of your product
- Governance: same
- Experience: UX improvements, APIs, integrations etc.
Now, select the bottom-left “+” and add releases. Add ALL of the releases we added earlier. One by one, associate them to the right swimlane.
Drumroll…..all of your elements appear!
Some goodies:
- ProductBoard have a couple useful features for the view at the bottom-right. You can do a horizontal zoom so you can focus on any timeframe you want. You can record a video of the roadmap so everyone can self consume the key points. Lastly, there’s a legend.
- Do you want to have a way to include/exclude internal features? No problem, add a tag to the relevant feature(s) (something like, ‘Internal’) and filter on that.
- Lastly, how about running a weekly status meeting with R&D that is focused on business impact (vs. that stream of features that nobody can connect to a story)? Focus your view on the current/next month, and go down based on the month focus. Most of the features will already have been understood and on track, some others may represent a risk. Look at the feature progress (the blue line on top) and if it doesn’t match your expectation, you can expand it and drill into the subfeatures, even link over to Jira/MS.
In summary, there is a path to align the organization from Dev to sales, from vision to feature status, using product tools, one of which is ProductBoard. As product people, we have the opportunity to really impact our users and the business through a thoughtful product investment, clarity and alignment of our vision and plan. I hope the previous article on the approach, and this one on the mechanics, are helpful. I’d love your comments. Thanks for watching ;)
