Crafting your perfect Product Roadmap
If you had to use 1 word to sum up what PMs do, most PMs I know would likely pick “Product Roadmap”. (Okay that’s technically 2, but you get the drift.) Product Roadmap is so important, not because it’s the holy grail of what we do as PMs, but rather it embodies all the blood, sweat, and tears of what makes a product, the finished product. In my post today, I won’t attempt to show you exactly how to make the perfect Product Roadmap (mainly because I don’t believe such a thing exists), but rather the thought framework that I typically use when I’m creating a Product Roadmap. To give some color to the framework below, I’m going to pretend that we got the mandate to go build ‘HR software for candidate tracking and better communication between candidates and the firm as the candidate goes from the initial sourcing stage to when the candidate finally accepts the offer”.
One: What are you building?
This is the big ‘vision’ question, aka boiled down to “Why are we doing this?” “What is the value-add of what we’re doing?” So using our nice sample prompt above, this could be in response to the company lacking overall processes or rather the need to centralize all of the data inputs regarding the candidate; in more concrete examples, this could be an amalgamation of the candidate’s background and experience from LinkedIn, coupled by the candidate’s information stored in Applicant Tracking Systems (think Greenhouse.io, Jobvite, etc.) combined with something like Salesforce, which tracks the ‘opportunity’ (or in this case, the candidate), as s/he goes through the interview/hiring process. Let’s call our sample product a “CRM for Candidates”. (And this point in time, I would suggest that the PM in question have done a thorough market analysis on what the existing products provide and what the gaps are — for the purpose of this article, we’ll assume that a comprehensive analysis has already been done and that we know precisely where the gaps are and have validated our assumptions with market demand.)
So now after you hammer out the big questions, here’s where you can get creative. Besides knowing all about the candidate’s past experiences/education and tracking who they’ve talked to in the company and perhaps how well they’ve performed, what else could be useful? Hmm, how about:
(A) What if we could amass information across different companies, and create a comprehensive bio on the candidate? Let’s say the candidate did well at B2B companies, but maybe not so well in B2C companies’ interviews. Could this mean that the candidate is a better match for enterprise product management? So if the target company is a B2C company, then should the hiring department be upfront about the differences in product management between B2B and B2C?
(B) What if we could also make the candidate him/herself a consumer of this information? I know personally I’ve used tools to track my performance in interviews every time I’m on the job hunt, but what if there was a tool that could systematically track this for me? Provide me feedback (if possible, bc some companies have strict rules against sharing feedback) from interviews, or perhaps interviewers could submit anonymous tips on how to improve my answers? And most powerfully, track this through time. I know I would pay for this service if it existed.
Two: What is your audience?
Here, you identify the consumers for your product — in short, who will be willing to pay for your product. In the example product we’re building, an obvious choice would be companies who are looking for a single source of truth for a candidate — in our exercise, we identified that as a “CRM for Candidates”, an open platform that integrates with LinkedIn for jobseeker profile, but has the ability to track and record feedback as the candidate progresses through the hiring cycle, and lastly integrates with background check tools (e.g., Checkr) that can confirm the candidate’s identity and employers. And here, if we were to go further into creative brainstorming, we could think about how to make this data consumable for the job candidates themselves. As a job candidate, I would clearly care about: feedback for improvement and more transparency into where I stand in the process (side note: how many of you have sat in limbo waiting for a yes, or at the very least a no, so you could move on?? I know I have!).
Three: How much time do you have?
A quote from JRR Tolkien: “….All we have to decide is what to do with the time that is given us.”
So true. Most products, or MVP (Minimum Viable Product) products, are limited in scope by how much time the developers actually have to build the product. So let’s break this down into a rushed scenario, in which we only have 3 months to build the MVP.
Timeline: 3 months
Okay, 3 months is not a lot of time. So what is in scope (P0/P1) versus a ‘nice to have’? Well, if we’re building a “CRM for Candidates”, then the list of priorities might look like this:
P0: Dashboard where company recruiters can see candidates in various stages of hiring: sourced candidates >> phone screen >> first round >> technical interview >> onsite interview >> background check >> offer accepted.
Building an interactive dashboard (with dummy data) with rudimentary design might take 2 weeks using React.
P1: Integration with LinkedIn for candidate background/experience
P1: Tracking feedback from interviews and aggregating feedback
P2: Integration with ATS tools for a wider candidate pool
P3: Integration with background check tools
Four: Do you have dependencies?
Unfortunately, in an imperfect world, we have dependencies on other products, teams, decision-makers. So an accurate capture of that is critical to your product’s success.
Let’s say in our scenario that Integration with LinkedIn was a dependency on a partnership with LinkedIn (non-product/eng related), and that this needed to be carried out by the Alliances team. Thus, to get alliances engaged in the lead time that you anticipate before engineering work on the integration work is to be started would be the right move. And in the real world, dependencies abound and it is the PM’s responsibility to track all of them and to make sure none of them become blockers for the product.
In summary, I think Product Managers should in theory think about all 4 tenets above when constructing their product roadmap. Real-life products may be much more complex than the example we used to illustrate the creation of a product roadmap. If you run into questions, I’m always happy to lend a ear — just shoot me an email, tweet at me, Facebook message me! You can reach me by email at: nancy@advancingwomeninproduct.org.
About the author: Nancy is an experienced enterprise software product manager and VC, currently leading core product lines and a stealth product line (to be launched 2019) at Rubrik. She continues to engage herself in the tech VC landscape in her role leading product and engineering for Buttonwood, a software-focused platform for elite startups raising capital. Nancy was also formerly a PM at Google, where she led the development of products for the Google Fiber network infrastructure team. She is a passionate advocate for diversity and is an avid supporter of women empowerment in STEM through founding Advancing Women in Product, a 501(c)(3) non-profit dedicated to providing equal opportunities in tech for men and women. Nancy graduated from the University of Pennsylvania’s School of Engineering & Applied Sciences.
