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.
Teaching an Understanding of the User Scales a Product Manager’s Impact.
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.
New Tools to Communicate the User Journey
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.
Introducing the User Journey Map
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:
- How a product fits into a user’s day-to-day workflow
- How a user interacts with a product or feature from end to end
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.
User Journey Maps Should Provoke These Crucial Questions:
- Are there enough users with this workflow to justify building my product?
- Does this feature actually make my users’ workflows more efficient?
- What steps of the workflow would it replace, and what tools currently sit in those spots?
- How much friction does the user need to go through to “accomplish” your step in their workflow?
An Example: Trip Planning Product
Let’s take an example of a new travel planning product. This is a real example I’ve been evaluating lately.
- Who is the user? A millennial who is planning their next trip to a destination they haven’t been before. The discerning factor here is how organized they are about planning upfront.
- How are they currently planning their itinerary? Once they have a destination, they collect recommendations from various sources and compile them in a document. From there, they organize and schedule out the activities for their trip. Then they move the places into a mobile-accessible format (Notes, Google Maps, etc) for easy reference on the go. Once the trip is done, the user rarely touches it again unless they have a friend who asks for recommendations to the same destination.
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.
- How much friction does the user need to go through to “accomplish” your step in their workflow? The main goal would be to have previous trip planners upload their itineraries in a format that makes collecting and organizing ideas easy for future trip-takers. The format of the final itineraries should inherently translate to mobile.
Conclusions from the Trip Planning Example
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.
—
Scaling the Impact of Product Management
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?