If you want to start a fight, ask a roomful of people what they think about product specs. Product Managers don’t like writing them, engineers don’t like reading them, and nobody actually refers back to them. A remnant from the days of waterfall development, they’re excessively detailed and irrelevant almost immediately after you finish writing it. The spec doc in Agile development isn’t perfect either, with a greater emphasis on flexible requirements based on iterative customer learnings, setting requirements at the sprint level, and the “discovery” of requirements. Between total omniscience and just-in-time requirements, both of these do a disservice to the skills we hire Product Managers for.
A deep understanding of customers has replaced the waterfall spec in terms of a Product Manager’s core deliverable.
Today’s Product Managers are increasingly accountable for the user’s experience. As the skills of the profession evolve, they are involved in more and more of the user’s journey through their product, from marketing, to sales, to support. Instead of communicating the product specs to all departments involved in product development, a PM must now teach engineering, design, marketing, support, sales, and more about the user.
As Product Managers are increasingly involved at every level of product planning with other departments, telling the user’s story is a crucial communication step for scaling a PM’s job. It helps every department understand who the user is, what success means to the user, where the product fits into his/her workflow, and more. All departments can then make decisions that benefit the user without necessarily needing the PM to be involved every step of the way.
Between design thinking, customer development, jobs-to-be-done and lean experiments, Product Managers are given more frameworks and advice than they know what to do with. They are in need of updated tools that help them think about and communicate the product vision to a wider audience.
Previous spec docs were written mainly for Engineering so they could successfully build a feature. The documentation required today needs to communicate a vision for Engineering, Design, Marketing, and more without being too long or prescriptive.
A user journey map is a visual tool that walks a reader through who the user is, his/her current workflow, where a new product would fit into that workflow, and how the user would progress through the product. It’s a crucial amount of context that can fit into a few simple diagrams:
It fits well with the Jobs-to-be-Done framework and the movement of the product industry towards understanding and planning for users’ holistic experience in products. User journey maps also utilize the core concept behind personas and use cases in a more organic way.
User journey maps replace use cases and personas with a deliverable that is steeped in the reality of a customer's day-to-day, and introduces an element of sequencing / time that was lost in the long list of requirements from past product specs.
Mapping out the user journey forces PMs to deeply understand real users and their day-to-day concerns. It also encourages critical thinking about whether a new product fits into a workflow, what it replaces, and how much friction the product will have to overcome for someone to adopt it.
Let’s take an example of a new travel planning product. This is a real example I’ve been evaluating lately.
Current user workflow for planning a trip.
3. What steps of the workflow would it replace, and what tools currently sit in those spots? It would replace the research, organization, and accessibility steps. Currently a mixture of tools sit in these steps, and the user is required to do a lot of manual work during upfront research, organization, and moving the itinerary into a final mobile-accessible form.
Tools for managing each step are scattered.
Doing this exercise taught me I need to validate assumptions such as the group size of people who plan their trips this way as well as whether there is a standard way people plan their trips. Otherwise this may end up being a niche product.
A PM can’t be everywhere, so they need to convey a critical amount of information in a clear way so multiple collaborators can work in parallel. The user journey map helps convey the background context and problem being solved in a way that is quickly understandable. Then the conversation can be reframed around the core assumptions for the product, instead of as a debate over the product details themselves.
This was based off various conversations with PMs and engineers about how they’re seeing the field change. Where do you think Product is headed?