Module: Ownership. Today's lesson: You'll learn how to party with PRDs! In this lesson you will learn how to use, draft, and critique product requirement documents. Now that you understand your customers and their journeys, it's time to design your product or feature. And the design for your product is called the PRD or product requirements document. You give the PRD to everybody else on your team, ranging from engineering, QA testing, customer service or the field sales team, marketing, finance, legal, so on and so forth. The larger the organization, typically, the more other teams that you'll have to be working with. These other departments then study your priority, maybe give you some comments, add some complimentary documents on how they are going to build, support, maintain, go to market, all these things that surround a successful product launch. So, for example, these include, from engineering, a design document that explains different resources or maybe technical approaches that they need to build it. From legal, a memo that might request changes to different functions or language for many public launches, for example, these often come in tandem with the press release that might be shared with press or might be shared with the general public, so on and so forth. For visual products, these might even include simple sketches, right? In the PRD itself. So, again, no hard and fast rules. Oftentimes, what I end up doing, is I go into a boardroom where there's usually a whiteboard. And, simply drawing out UI workflows or boxes and arrows, sometimes is enough to give those reading your PRD, a sense of, what are the steps? A sense of, what is the flow that you had in mind? Of course, later on as you work with product designers, as well as UX researchers, these can be then fleshed out into very beautiful high resolution fidelity mocks. In practice, there are many methods for writing PRDs. For, one example, this is software company method. In this lesson, I'll teach you how to write a product requirements document in a simple way, that works with Coursera's interface. And, regardless of whatever software you have access to, my focus will be on the substance of what you write, not how your text will be displayed. For our See One, Do One, Teach One example, we're going to write our own PRDs. Let's start with a simple PRD that I've created. So, in this PRD, Responsible Product Manager will be me. The organization is Mint Mobile. And so, for those of you who aren't familiar with Mint Mobile, they are a mobile carrier provider. And, they provide a service as you can see here in the ad for unlimited talking and texting at a low price of $15 per month, recurring. And so, the specific feature that we're going to work together, and I will walk you through this example, is the US-Canada border crossing alert. And so that's a specific feature that, as a product manager, you will be responsible for building. So, the background is, as I mentioned, they're a low-cost wireless provider that offers 3GB of data per month at 4G LTE. And, as we mentioned before, unlimited talks and text for $15 a month. They're based in the US. And, in terms of their infrastructure, they're simply tagging on to T-Mobile's existing infrastructure. And so, the users, right? Going back to, again, right? Calling upon things that we've already talked about during our course, is user personas, right? So, one of the users that we're going to focus on for this feature PRD, is Ernest. So, who is Ernest? Well, Ernest is a 28 year old American male. He lives in Seattle, and he is a Mint Mobile customer. About once or twice a year, his friends will ask him to visit Vancouver, which calls for him to cross the US-Canada border. He owns a car, and sometimes during these journeys, he's happy to give a ride to his friends. So, the first time he drove to Vancouver, his cell phone lost all connection until he could go to the hotel and get on their WiFi network. So what did Ernest do? Well then, he googled the issue at his hotel, and he discovered UpRoam, which is Mint Mobile's international roaming program. According to Mint Mobile, UpRoam allows you to add $5, $10, $20, $5 increments, seems like, into your account, which can be used for all calls, texts and data used in international locations. So, of course, Ernest being in Vancouver needed cell access. And so, he added money to UpRoam, and received a confirmation text. However, right? And this is a problem statement that we're looking to address. Every time Ernest left the hotel, he ended up losing his data and was unable to use his phone. And because he couldn't access his phone's GPS, he resorted to hand drawing maps in his hotel room, poor guy, and carrying them around in his pocket to safely navigate Vancouver streets and British Columbia's highways. Also, his enjoyment of the trip was severely diminished because he couldn't call or text his friends, right? And so, next year, and this brings us to the point of which we are trying to build this feature to solve a problem, is that Ernest's friends started planning another Vancouver roadtrip. So Ernest, being a Mint Mobile customer, emailed to ask them what happened, right? Then Mint Mobile support responded, kindly be informed that you would need to put your phone on airplane mode before leaving the United States. And when you arrive in your destination, deactivate it, then turn on Roaming, and then you'll be able to use it. So, I mean, without creating judgments, first off, doesn't that seem like a very convoluted process, right? So, as a product manager and you're encountered with this situation, what you want to think is, how do I put myself in the shoes of customer, here being Ernest or folks like his profile, right? Who are already users of Mint Mobile. Who may have different needs to travel across the border, and yet still retain access or usability to their cell phone data plan, right? Clearly the process shouldn't be that convoluted. And so, Ernest's GOAL is to use this phone in Canada. A SUBGOAL is to be reminded of what to do before he loses reception, driving across the border.