Welcome to Week 2. We're going to focus here on a portfolio of methods that will help you across the product pipeline, do the jobs, effectuate the solutions you learned about in Week 1. We're going to start out the week talking a little bit about the ways that different PM roles might differ on these dimensions that you see here. That'll help contextualize when and how these different methods might be the right fit for you. We're going to take a look at Agile. Agile is this big tent of practices that product managers and team leads and agile teams can draw on, pick and choose and adaptively find what works for their particular product and team. However, all these methods have one thing in common, which is that they're generally after, how do we help this product pipeline work better? Specifically, how do we make sure that at the beginning of one sprint and the end of another, we're punctuating that with a retrospective where we're asking both and this is one of the really great parts about it, how did things work out amongst the team from a process perspective? Also, how did the things that we released to the user workout in terms of our outcome focused definition of done? How do we continue to do that better, experiment and find what worked for us? Because again, there's no single blueprint of agile that always works the best for every single team. A strong practitioner will generally tell you, I work with a team and then we find what works for us. That's the whole point of Agile is to adaptively figure out what's working, and what isn't. Then, this area of continuous design is a place where you'll probably do a lot of work as a product manager or as an individual contributor. We're going to unpack that and look in more detail at how we go out and talk to customers and ask and answer the right questions, the relevant questions for whatever it is we're doing so that we're doing as they say in the design world, just enough research continually to make sure that we're operating on a strong foundation of knowing who this user is and knowing what's on their a list so that we don't build things that have no customer and no problem that they're actually solving for anybody. Then where we are going to go even further as far as trying to go to the hoop in this continuous design area and minimize waste and maximize wins by looking at this body of work around testing demand hypotheses with lean startup. What this will help us do is find propositions that are investable from a code perspective. We're going to eliminate things, minimize waste before we even invest in moving them along the product pipeline, and in that fashion, we can maximize our wins. Now, as you do all these things, you're going to accrue a body of work and a body of evidence, both qualitative and quantitative, they'll help you focus and help you make good crisp evidence-based decisions about where going to focus week-to-week. For that, we're going to learn about this UX map that helps us marry those things together and have a little bit of a persistent lattice that we operate on week-to-week. There's some consistency on what we're focusing on why, and how it fits into what we did before and what we might do in the future. Then we're going to turn our attention to this usability hypothesis. How do we build UIs that are highly usable? We're going to look at how we create outcome focused definition of done with user stories. Make sure that we're layering in instrumenting observation that answers very crisp focal question so that when we do that hypothesis testing, when we enter the next sprint, we're coming into that with an evidence-based point of view on what's really done from an outcome perspective, what isn't, and based on that, where we should focus to maximize value. Then we're going to look at in the same general area, how we can do continuous usability testing, both using non-code low-fidelity prototypes, as well as high-fidelity prototypes implemented in code or different tools. How we can just make a habit of pairing our user stories with a test plan and thinking of our user stories in a more test-driven fashion to both focus and make the stories easier to understand and more actionable for our developers. Finally, we're going to look at the Hook Framework, what's created by Nir Eyal. It's a way to think about creating durable habits for the user. We will dive into this question of trigger action, reward and what investments mentally and using the product do users make as they progress through that UXR, how do we create durable habits around them? Then we're going to close the week by looking specifically at how we apply these things in the context of enterprise software business to business products, where we want to make sure that we're not doing either of these two things because they don't work. But instead, we're going out, we're working with these customers to find out what really matters to them and how we best deliver that to them on top of our existing product or maybe a different way. Then we'll close the week looking at funnels. We're going to take this question on the UX map of, what do we mean by acquisition and we're going to unpack that into the items that you see here. We're going to look at how we pair qualitative and quantitative evidence specifically there, since this is so critical to consumer-facing products or even things that you're selling goods, the mass market to let's say a small business, for example, where their customers are finding out about you online. They're all at arm's length. You don't have, for example, the high-touch account management process that you have with most enterprise customers. It's very important to have on hand a portfolio of methods as a product manager that spans the product pipeline and particularly digs in on this question of continuous design. You can be really good at, like let's say lean startup or really all in on Agile. None of those things is really the best in terms of just doing all these jobs by itself, really is a portfolio methods that get you the best results that allow you to draw on the lessons learned from the last few years of modern product management. You won't necessarily be an expert on all these things, but you will know when they might be applicable. That puts you on the path to being an expert because it'll allow you to do high-quality, relevant, directed practice in your work so that you can apply these skills and get more and more comfortable with them as you go along in your journey as a product manager. Let's get started.