Making a Product Map: Product Manager Scalability as the Product Nexus

Here is an article about a document I created when I worked at Handsome to facilitate communication in the team around the product.


We hear a lot that the role of a Product Manager is creating a Product Roadmap, focusing on strategy, being the voice of the consumer and the market, and making certain that the right features of the product are built in the right order. I summarize this into one statement, Figuring out the right thing to build, and getting it built. However, one of the biggest jobs is implicit in the role of a product manager. This is keeping the product team on the same page and updated. Ultimately the Product manager is the nexus, the great collaboration engine of the product team. Yet, being this nexus point its timing consuming, and not without its own challenges.


This is especially a problem when the product team has rolling members, where some members roll off the project and new ones come on. Added to this constant churn of teammates, there are multitudes of tools used that store information about the product and project. At my previous company, we had documents on Dropbox, Google Drive, InvisionApp, Trello, videos, audios, transcripts, walls filled with post-its, etc… you get the picture. There was a never-ending maze to navigate making it difficult even for current members of the team to find what they needed. With all of these tools, multiple stakeholders (customers or internal people), designers, developers, UX researchers, and other product folks, the product manager becomes not only the central repository of knowledge of the product but also the central collaborator on where the information is hidden. I quickly realized that my time was best suited to create one master document that told the story of the Product. Having one place where I could update relatively frequently in high-level detail, and point everyone to it in the old way of RTFM. This one document would contain all the knowledge someone would need in order to find where stuff was at, but also, the vital knowledge of what we are building and why we are building it. I call this document the “The Product Map.”

Click here to view a template of the Product Map on GoogleDocs where you can duplicate it and tailor it to your own needs, and feel free to leave your comments and questions on the document.


The Product Map can take many forms so I don’t want to get caught up in its format. The main point is that it is the summary of the sum total of the most important things that the Product Manager knows about a product, and would want everyone else to know on the team, including the clients if you have them. At my previous company, we made the Product Map out of a GoogleDoc and placed it in the Root directory of each project file system called README_PRODUCT-TITLE_PRODUCTMAP. Check-out the above link to view the Product Map Template with examples and details of all sections.


So as you can see, the Product Map was an amazing repository of information. It held the summary of the project and product and was enough information to get people moving quickly with links to dive deeper where they needed. Customers would read it, co-workers would look at it, and the biggest benefit by any measure is that when new people joined the team, I simply showed them the document, let them read it, then answered their questions. It was also great at helping out the remote development team to read as much as they wanted so they could leverage the information, become product experts and gain insights they helped them build a better product and ask us better questions. The development team especially found it useful to watch videos of client meetings and user interviews which I also linked to in this document.


As time went on in projects, less and less time was available, and if I didn’t make an effort to spend 5 minutes every day updating the document, then the task would slip, slip some more, and ultimately, get a week out of date, making it harder to update. On retrospective, I think this might have been more of our particular team's issue than a fault in the document itself. On our team, we had Project Managers and Product Managers. It became unclear who would update the document, and while I allowed anyone on the team to edit the document, the reality was that no one wanted another thing to edit. My recommendation is to have the Project Manager update files, and links and status update, while the Product Manager focuses more on writing the content of passing on information about the project and deep understandings of the product.


Creation of the Product Map helped our team, especially given how people came on and off of projects. It was after all an agency where each employee had multiple customer projects they worked on. The goal of it was not to replace the other tools we used but to be a 50,000ft view of information in these tools. The Product Map was simply a summary document that deep linked to other sites and places where you could dig in deeper if you wanted.


About the Author

Mark Stephan is an entrepreneur and product enthusiast.

Starting off as an Archeologist, Mark graduated university with 5 majors and 3 minors and worked on his masters in History and Archeology. However, taking an abrupt turn, in 1999 he entered into the tech world by working at Trilogy Software in Austin, Texas. After the DotCom collapse in 2001, Mark moved to Istanbul, Turkey where he taught entrepreneurism to persecuted communities and refugees. He also attended Istanbul University, learned Turkish, and on graduation started his own software company in Istanbul and ran it there for 5 years. In 2008, Mark moved back to Austin, Tx moved his company and ran a consulting company helping start-ups start up. In 2012, Mark closed his consulting company and focused full-time on his new product start-up, Community Raiser, launching a crowdfunding platform for non-profits. In 2015, Mark took a short break from his start-up to work at a human-centered digital product design agency as product manager helping clients build the products of their dreams.

Today, Mark is still very involved in giving back to the community and serving refugees and persecuted communities around the world. He is also working on a new product at his start-up Community Raiser and is about ready to launch a mobile app to build generosity of thought. Afterward, Mark is intending to work for a yet to be determined product company building the next great thing.

Want to learn more about Mark Stephan?