Not so long ago, the job of product manager was about assessing market data, creating requirements, and managing the hand-off to sales/marketing. Maybe you’d talk to a customer somewhere in there and they’d tell you what features they wanted. But companies that manage product that way are dying.
Being a product person today is a new game, and product managers are at the center of it. Today, particularly if your product is mostly digital, you might update it several times a day. Massive troves of data are available for making decisions and, at the same time, deep insights into customer motivation and experience are more important than ever. The job of the modern product manager is to charter a direction and create a successful working environment for all the actors involved in product success. It’s not a simple job or an easy job, but it is a meaningful job where you’ll be learning all the time.
This course will help you along your learning journey and prepare you with the skills and perspective you need to:
Create the actionable focus to successfully manage your product (week 1)
Focus your work using modern product management methods (week 2)
Manage new products and explore new product ideas (week 3)
Manage and amplify existing products (week 4)
This course is ideal for current product or general managers interested in today's modern product management methods.
This course was developed with the generous support of the Batten Institute at UVA’s Darden School of Business. The Batten Institute’s mission is to improve the world through entrepreneurship and innovation: www.batteninstitute.org.

レビュー

JH

Great overview of product management in a digital world. It was very accessible to a beginner like myself. There are a ton of great tools and process that are easily transferable to the real world.

PV

Apr 26, 2020

Filled StarFilled StarFilled StarFilled StarFilled Star

Very informative and well structured. Alex is very knowledgeable and he is capable of transfer his experience into practicable real business examples. Well done guys, I enjoyed taking this course!

レッスンから

Amplifying an Existing Product

If you want a product that does more than make a big splash, you’ll need to apply what you’ve learned here every week, every sprint to keep that product fresh and relevant. It’s not hard to let a great product get sidetracked and become irrelevant to its users--this happens all the time. Some figures show the portion of features on successful products that are regularly used to be well under 50%. Yikes! In this week, we’ll look at how successful product managers keep their products fresh and focused on valuable outcomes for their users. You’ll learn how to put a focused, sustainable, program in place to keep your product competitive.

講師

Alex Cowan

字幕

We've talked about the importance of lots of iterations paired with careful observation. And on the development side of things as a product manager, your interface with development, few things are as enabling for this as a continuous integration and continuous delivery and capability. With us today is Jim Rose, CEO of CircleCI, which provides commercial products that help enable this capability. Joe, thanks for joining us. Thanks for having me. How would you explain continuous integration and continuous deployment to a product manager who is new to the topic? So, continuous integration and continuous deployment are basically end to end automation of the development process between the time a developer makes a change to code until the time that that code is a running application in the datacenter. So, continuous integration talks to the first part of that and every time a developer makes a change to code, it merges that code into the main codebase and then test the codebase to make sure that everything is good and everything still works. Continuous delivery or continuous deployment is then being able to take that change in the codebase and then being able to push that actively and automatically into the datacenter. So that's kind of the Holy Grail. Once you get to continuous deployment, you have end to end automation from a change in code to an actual function application that instead of taking hours or weeks, can take just minutes. What do you think are the three, most important things that a product manager needs to know about this emerging super important area? The first is that is all about speed to learning. So, the idea of being able to make changes in their codes, see those changes to your code, ultimately in front of customers is all about trying to reduce the time it takes between coming up with an idea and then actually getting data from customers. So, it's all about getting things into small bite-sized pieces and being able to push those quickly and then iterate quickly on top of that. In order to be able to iterate, you have to be able to automate. So, as much as possible, you want to take out as many of the manual dates and as many of the manual processes between the time you make a change in code to that code being in front of a customer. And then, the last piece is because it's all about speed to learning and it's all about being able to see the impact of the changes that you're making to your code, you need to know what you're measuring. So, you need to in advance, be able to define what success looks like, how you would measure success. And then make sure in your system that you can actually see the results of the code as it goes live in front of a customer. Once you have all of those pieces together, you can really start to move quickly. Sometimes in practice, there's a tension between the product manager and their interface and development team where the product manager wants to get more features in there, and then the dev team wants to relieve some technical debt. For example, invest in improving this automation, this delivery capability. You thought a little bit about your [inaudible] perspective on technical debt. What is it and how PM should think about it? Yeah. So, technical debt is basically the remainder of your development equation. So, technical debt is a result of informed choices that you're making when you're trying to build new features and get them in front of your customers quickly. And also, potentially just shortcuts that you take ultimately to try and speed up. You should be incurring technical debt because you never want to be working on something until it's perfect and it's 100 percent done before you ship it out to your customer because chances are, you're 80 percent right on anything you ship. And the question is, which 80 percent? So, you want to get that feature in front of your customer as fast as possible so you can start getting data. And then ultimately, you just have decisions that are in your codebase that need to go back and be addressed. They just are shortcuts and they just have to be managed. What do you think is the best way to minimize and manage technical debt? So, we create time inside of our development process to always address technical debt and always have basically, a line item for maintenance inside our delivery system. So, the first step is, we divide product discovery. The idea of trying to find new and different features and new and different things to put in front of the customer away from delivery, the idea of being able to create production ready software. That's step number one. So it's called, dual track agile. It's the process that we use internally. The second part of that is in your delivery pipeline, you really want to break up each part of your delivery capacity into different buckets. The first is, you never want to allocate 100 percent of your time because things change. You get interrupted because production goes down. Something takes longer than you expected. So, what you want to do is leave at least 20 to 30 percent of your overall development capacity totally unallocated. It's basically slack in the system that as things come up, you actually have the ability to address it without necessarily pushing back the deliverables. The second part of it is, for the parts that you do allocate for your development team. The way that we do it internally is we take 40 percent of our time and we allocate it to the construction of new features or radically new versions of existing features. So, new things that are getting in front of customers, we usually take about 40 percent for that. We take 20 percent and allocate it towards the maintenance of existing features. Just fixes, enhancements and those different pieces. And we also leave 20 percent allocated for maintenance, bugs, technical debt, architectural debt. So your development team knows that they always have time to be able to address the pressing technical things that everybody wants to take care of and don't feel like they have to either do it off menu and not tell you about it, also don't end up in a situation where you end up with a pile of technical debt at the end of a development process. And then you have to start paying down. Some great advice on managing your delivery capability. Thank you so much, Jim. Sure. You're welcome.