Penchant for product

Writing Product Requirements Documents is a critical skill for a Product Manager. These documents are useful for aligning the engineering and other cross-functional teams on what should be built and why it should be built. There isn’t a standard for writing a product requirements document as different product managers have different styles and formats. However, regardless of which style or format is used, the outcome should be a product requirements document (PRD) that conveys the product vision, is clear and easy to understand.

At a high-level, any product requirements document should contain the following:

• What: The problem being solved
• Why: The importance and benefit to the customer/end-user as well as what happens if this isn’t done
• Proposal/Acceptance Criteria: Expectation from the customer/end-user’s perspective
• KPIs/Metrics to track

Example: Midpoint for Google Maps

I am directionally challenged unfortunately and rely on Google Maps almost every time I have to go somewhere. One of the features I am still hoping Google releases is what I call a Midpoint feature. This feature will provide a user with a halfway location when given 2 starting locations.

If I were the product manager for that feature, here’s what my requirements might look like:

Product Requirements for Midpoint Feature On Google Maps

Overview/Problem

Lara, 43, is a pretty tech-savvy but directionally-challenged (her words) individual. She is a freelance consultant who utilizes google maps at least 3 times a day to meet up with the clients she works with. She loves Google Maps for straightforward navigations but finds it doesn’t quite fulfill her navigation needs. Here’s what her journey with the current google maps offering looks like:

Once Lara decides on the halfway point that is convenient to meet up with her client, she then spends additional time on both Google search and Yelp to find a suitable coffee shop for the meeting.

Lara is just one of the millions of users that have frequently requested this Midpoint feature. 50% of our 150 million monthly Google maps users are not well served by the current Google maps capabilities (link to data). Like Lara, these users have reported having to utilize multiple instances of Google maps and Google search when looking for central meetup points for clients, friends, family amongst others. This has created a frustrating experience for these users and resulted in them spending an average of 20mins when looking for a midpoint/halfway meet up point.

All Google maps users should be able to easily use midpoint to find a coffee shop, restaurant, park or other meeting point that is halfway between two locations.

User Story

As a Google maps user, I want to easily find the halfway point between two locations so that my friend and I have an equitable commute thus allowing us to maximize our time together.

Acceptance Criteria

(P0): Must Have – Will not launch without it; (P1) Nice to Have for Launch – Available Post-Launch

• (P0) Midpoint shall be visible from within the homepage of Google Maps
  • (P0) A user shall, with no more than one-click,  easily see and select the Midpoint feature
• (P0) Once Midpoint has been selected, user can enter starting locations
  • (P0) There shall be obvious text boxes or entry points to input 2 locations (e.g. Location A, Location B)
    • (P0) Midpoint between Location A and Location B shall be +/- 3 miles from each other i.e. Location A can be 15 miles from the midpoint while Location B can be 18 miles from the midpoint
    • (P0) Up to 3 locations can be shown as midpoint e.g. City A is exactly at midpoint, City B is 2 miles from midpoint and City C is 3 miles from midpoint
  • (P0) A user shall be able to select locations via pin drops
  • (P1) A user shall eventually be able to find the midpoint amongst 3 locations (Location A, B, C)
• (P0) A user shall be able to input locations as well as categories of meeting places in the same UI i.e.
  • User enters location A and location B
  • User also selects coffee shop and restaurants from the checkbox as places that should be optimized for midpoint selection
• (P0) A user shall be able to select categories of meeting places after the midpoint has been determined and displayed i.e.
  • User enters location A and location B for midpoint determination
  • 3 potential midpoint options are displayed
  • User can then select a category such as coffee shop
  • Coffee shops within midpoint radius are displayed
• (P0) Midpoint shall present users with up to 7 places that match the selected category i.e. coffee shops, restaurants, bars etc.
  • These locations (coffee shops, restaurants, bars) shall be ordered by proximity to midpoint
  • They shall be displayed with star rating (if available) as well as open/close status e.g. Coffee shop A, ***, open now; Restaurant B, ****, opens 12pm; Coffee Shop C, ****, closed perm
    • This functionality should be the same or similar to what is currently available on Google maps
• (P0) A user shall be able to easily trigger navigation once the midpoint has been selected as currently available in Google Maps
• (P0) A user shall be able to make a reservation on the chosen midpoint location via OpenTable API as currently present in Google Maps
• (P0) The location chosen can be saved and shared as is currently present in Google maps

Measurement

The success of this feature will be determined by its overall adoption and usage by Google maps users. The midpoint feature will provide our users with less complexity and more efficiency when coordinating and navigating via Google maps.

Metrics

Feature Specific:

• Daily active users of the midpoint feature to find a halfway location
  • Percentage that are returning users
  • Percentage that are new users
• Daily active users who used the midpoint feature to find a halfway location and trigger a navigation
  • Percentage that are returning users
  • Percentage that are new users
• Average Session Length of Overall Daily Active Users
• Monthly active users of the midpoint feature to find a halfway location
• Monthly active users who used the midpoint feature to find a halfway location and trigger a navigation

Product Specific i.e. Google Maps

• Daily active users
• Monthly active users
• Session Interval and Session Length
  • It is possible that this metric will be impacted i.e. decrease as the midpoint feature is meant to increase efficiency thus eliminating the need for multiple session intervals

Team Needed

• UX Designer
• Frontend Engineer
• Backend Engineer
• QA Engineer
• Data Analyst
• Beta Program Manager
• Release Engineer
• Technical Program Manager
• Product Manager

Rollout Plan

Feature will be rolled out to:

• Google Maps Beta users who have session intervals
• After 1 month of Beta usage and performance analyses, Midpoint will be rolled out to all Google Maps Users as follows:
  • 1% daily rollout for 1 week
  • Increase to 2% daily rollout for 2 weeks
  • Increase to 5% daily rollout for 1 week
  • Increase to 10% daily rollout till 100%
• Entire rollout should take no more than 6 weeks to reach 100%

What about Wireframes?

A wireframe will definitely enhance any requirement. Including a wireframe depends on the comfort level of the product manager as well as expectations from the team. As this is a feature for a very robust product, I will mockup Google’s existing maps UI to properly convey my thoughts and then work directly with a designer to flesh it out fully.

For a completely new product, including appropriate wireframes with the requirements is highly encouraged.

I’ve used these tools to mockup wireframes and I recommend them to anyone starting out with wireframes:

• Balsamiq: Most robust wireframing tool I’ve used. It’s paid but they offer affordable options if you choose to store your wireframes on your own Google Drive account as opposed to their servers
• Draw.io: Free, not as robust as Balsamiq but once you’ve got practice with wireframing, it does the job quite well

Software and Hardware Requirements

The above requirements document is more suitable for Software Feature Requirements. As mentioned in this post, software and hardware product developments efforts are quite different. Firmware/Software for Hardware Features will be similar to the Midpoint feature. However, holistic requirements for a hardware product will take on a different format than what has been outlined here. This is discussed in the next post.

---

Liked the post and think someone else will? Please share 😃

---