Bite-Sized Product Management: How to Plan Projects | Fabian Frank | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Bite-Sized Product Management: How to Plan Projects

teacher avatar Fabian Frank, Bite Size Product Management

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

6 Lessons (27m)
    • 1. How to Plan your Project - Introduction

    • 2. Lesson 1: Planning Sequence

    • 3. Lesson 2: Prioritization

    • 4. Lesson 3: Scoping

    • 5. Lesson 4: Feedback

    • 6. Lesson 5: Review

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

In this class we'll go over some simple but extremely powerful strategies you can use to plan your next project as a product manager or project manager. We'll go over: 

  • The Importance of Prioritization
  • The CD3 Prioritization Method
  • Scoping and Versioning, Including tips for how to make that easy
  • RATs and how to structure your project to collect real user feedback early

If you've ever asked "what project should I be focusing on?" "how do I know I'm doing the right thing?" or "what's the best way I can plan a new project?" Then this is the course for you! 

The frameworks we go over in this course should prepare you well for your main duty as a product manager: prioritizing features and projects for the roadmap and planning projects in a way that let you collect feedback early and often. These scientific methodologies are the best way to logically structure your product management decisions. 

Useful for anyone in the business or entrepreneurial world, not just software product managers! 

Meet Your Teacher

Teacher Profile Image

Fabian Frank

Bite Size Product Management


Hey! I'm Fabian. I'm a Product manager, entrepreneur, and occasional ski-builder. I've got lots of neat tricks, skills, and strategies I've learned that I'd love to share with you! 

Feel free to reach out with any questions or lesson suggestions! 

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. How to Plan your Project - Introduction: Welcome to bite sized product management. In today's course, we're going to be going over planning and scoping for the future. The easiest work you do is the work you don't do. So this course is going to focus on making sure we can prioritize and plan projects in a way, or we're optimizing value delivery per time and not working on anything that we don't need to be working on. In this course. We're specifically going to go over mathematical prioritization models. So that means looking at objective ways we can prioritize things and what metrics we can use to determine which thing we should be working on first or which feature set we should be working on first, or even which feature or component of we should be working on first. We're also going to go over scoping the project. That means looking at how big the project should be, what we should include and what we shouldn't include. And finally, we're going to be looking at building and feed back into those projects. So that means from the start, building in strategies that we can use to collect data that our customers are telling us or our stake holders are telling us. And make sure that we're optimizing and working on the right things at the right time. I'm Fabian, I'll be instructor for this course. My background is in engineering and I am also the Product Manager for Badger maps at the moment. I've been working there for a couple of years and I also do consulting on the side for other companies. So hopefully I can bring some of the knowledge I've learned throughout my years to you and you'll join me on this course. Thank you. 2. Lesson 1: Planning Sequence: All right, Welcome to Lesson 1 of planning for the future. And this lesson we're going to go over a little bit about why it's important and we're going to explain that with a fun analogy. So let's get started. Why do we plan? Planning is really, really important. It's super easy to get excited about new idea or new concept that you've found. And then go right to implementing it, right? And that's great. Enthusiasm is great. But the important thing to keep in mind here is that if we take our time to plan things, prioritize things correctly, and make sure that we're scoping them and building and feedback from the start, then we can save ourselves a huge amount of time. And let me explain that with a bit of an analogy here. Let's say you're skiing along on a perfect day. I like to go SKY. That's why I'm using this analogy. And skiing is great in the back country especially, but then sometimes it's dangerous, right? And there can be avalanches. And all of a sudden, there's an avalanche and your friend is in that avalanche somewhere. You don't know where he's buried under the snow. He's buried alive and he only has a couple of minutes to look to live before he runs out of air under there. What do we do? Well, thankfully, there's techniques for avalanche rescue. We all carry these beacons in the backcountry. These are tools we can use to find other beacons. So hopefully our friend has one of these. And what we do is we go along the path where we last saw him, And we kinda search the avalanche path and a very coarse way. Finally we hear a beep, beacon beeping. And we can then go closer to the victim and look at, you know, kinda find generally where he is, that we get on a probe and we figure out where exactly he is. So we probe the snow and figure out exactly where under the snow he is. And then we start digging. And digging in. This whole part is by far the longest process, right? Digging is, takes potentially ten or 15 minutes to get down to the your friend. If he's only a couple of feet under the snow. And we can take a couple of very important lessons from this for Avalanche, avalanche rescue and apply that to planning projects. Imagine what would happen if you just started digging in the whole avalanche path. You would never find your friend. You've been digging in the wrong spot for days, you would be some avalanches can be half a mile long or even longer. And potentially for a 100 feet wide, there'd be no way you'd ever find your friend in time. So what we can take from this is we need to look at the big picture first. We need to look at prioritization. We need to look at what's the most important thing for your business right now. What's the most important thing to make you money for your customers and so on. Then we can start narrowing down the scope and figuring out exactly what to do. That's the project scoping component of this. And then once you've done that, then you can start planning the details and implementing the project. And that's kinda the digging part of this whole analogy. 3. Lesson 2: Prioritization: Okay, now we're gonna go into prioritization using simple math to answer life's biggest questions. And trust me, I know the math and those background looks quite intimidating, but don't worry, it's all fairly simple in the end, and I'm going to guide you through it. So there's so many things we wanna do, but we can only work on one thing at a time. Or potentially we can work on a couple of things at a time if you've got a big team. But in general, we want to make sure that we have our priorities straight so that we can be working on the correct thing at the right time. How do we prioritize? So there's a million frameworks of how to prioritize these kinds of things. There's no objective frameworks and subjective frameworks. We won't go into all of them here. We're just going to go into the best one. And the best one is something that comes from industrial queuing theory. That's something that's been used in job shops, mechanical job shops, things like machine shops and mechanic shops and things like that. And there you generally have one fixed or scarce resource, right? You have the machine shop or the job shop that has a limited amount of personnel or tools or something like that. You or your team are likely the scarce resource in this case. So what we're going to use here is something called CD3. And CD3 is something that calls, comes from these machine shops where you have potentially many different jobs that all have different values. And only one way to process those jobs. And are really our end goal here at the end of the day is to create the most value in the nearest term. So that means we're going to optimize for the rate at which we create value. That's an important thing. To do that the CD3 score is something we can give each component we're considering. So let's say we're considering three different features. Each one of them can get a CD3 score, and then we can take the one with the highest CD3 score and use that. And the way we calculate the score right here is the cost of delay divided by duration. And I'll go into what each of those components are. One thing to keep in mind here is that this score works for 99 percent of situations. Very, very occasionally you'll get to have some existential threat to your business that doesn't actually deliver value per se to your customers maybe. But something you need to worry about. Because if you don't, then, you know, your business might end some things like legal changes, privacy laws, that sort of thing. The cost of delay really gives us how much it's costing us not having that solution. So the cost of delay is one of those, is the first term in our equation there. And cost of delay is basically very similar to how valuable your project is, with some slight differences on what we consider as part of that value. Cost of delay can include not only the financial gain you get from the project, the time saved that you get from the project once it's completed. Or the customers are retained or your happiness and things like that. But it also includes the amount of money we're losing by not having this feature. So things like. Support costs and things like that. The, so here we can see that the cost of delay is what you gained from the completion and what you don't lose anymore when you completed. So little bit different than value. This is kind of what cost of delay is really, really important thing for these whole prioritization methods is that you assign numeric values to these inputs, even if there's objective, even if their estimations, even if you're almost guessing at them or you're taking something subjective and assigning a number to it, you want to make sure that when you're doing these calculations that you have some sort of basis for these numbers and that you're using real numbers. Once you get a little better at this, you can kind of start to do this in your head a bit more. But for the beginning anyway, it's very important. And even so, even when you're good at this, it's a very useful tool because you're often be very surprised by the kind of results you get here. In the case of projects at badger where I currently work, they usually have a fixed cost per time, right? This is the case with most software companies. That's consistent across all projects. So we don't really need to consider implementation costs in the cost of the project, right? If you're running a software company, you tend to have a fixed development costs because you're salaried engineers and things like that. If you have, for example, contract employees or something like that, you need new equipments or other things like that, then you could also factor that into the cost of delay here as a negative term. The duration is fairly simple. The duration is just how long it takes you to complete that project. So the cost of the project, It's not the the difficulty of the project. It's how long it takes you to complete that project. And that's a very important thing here to how long it takes is much more important because we're, remember, we're trying to optimize the rate at which we're delivering value. So that means we're trying to optimize how quickly, how much value we're delivering per unit of time. And that's why duration is important. So now we have all the inputs we need. We have our cost of delay divided by our duration, and that gives us our CD3 score. Here's an example and I'll go through these numbers in detail here so you guys, you don't have to worry about it in practice just to prove that this works. Here's a quick example. So up here in the gray box, we have a number of different jobs. These are the different projects you're considering doing and you're trying to prioritize. Each one of them has a different time that takes to do. Right. So one of these projects, job four, takes four months to do. Job one takes only one month to do, and so on. The value, each project has a certain amount of value it delivers. And then we can calculate from that, from our cost of delay here, basically our value in this case, and our time, we can calculate our CD3 score. So we can see we get a number of different CD3 scores for each one of these. Now let's see if we order these jobs by shortest time first, right, that would be something simple to do. In this case, we would have job 1 first, then job five and so on. And when we look at how much value that delivers in the first five months, that delivers thirty-two dollars in the first few months. And it will deliver $48 and the first 10 months. If we look at highest value first, here, we would order the jobs accordingly, right? Job 31st, then job one and so on. And here we can see we've actually improved the first five months value. But in the first 10 months, that shortest time first would have delivered more value. So these don't seem to correlate well with how much value we can deliver in the near-term. Write our rate of value delivery. Highest CD3 first, you can see here, and the first five months we end up with the same amount of value delivered as the highest value first. And then the first 10 months we actually beat Both other methods for highest value delivered. So you can see that by doing this, we're prioritizing projects that are quick and easy to do but deliver a lot of value. And by doing that, we're delivering the highest rate of value per time. And we really can't go wrong by doing that because at the end of the day, you're going to be making more money for your company in the near term. And in the, in the end, you're going to be able to use that money you make in the near term much more effectively, right? You could say if you deliver value now rather than later, if you deliver it now, then you can maybe hire some extra engineers. And then in the future, you can use that money to work through projects even quicker. So in the end, it's all about numbers. It's just science. Even if you're estimating them, numbers are much better than guesses. And it's so easy to think, oh, it's clear what we should be working on, but oftentimes you'll be surprised, but what results you get here? And I really encourage you, even if it's just a simple Excel spreadsheet, work through these numbers and see where your priorities line up. 4. Lesson 3: Scoping: Alright, now we're gonna go over scoping. Scoping is the next most important part of this whole planning process. And let's get into it. So what is scoping? Scoping is the process of determining how big your project is going to be and what to include in the project. We need to ask ourselves what needs to be achieved? What's the easiest way to get there? Once you have a plan, then you can ask yourself, What don't we need? Just as another check to make sure that you're working on the things you need to be working on, but not including all the other fun things that you might not really neat though. Versioning and phasing is one important part of this that we use for big projects, usually. So big projects should be broken up into versions and phases. And one of the important things here is that this is actually applicable to many smaller projects too. Because if you start thinking in a v1 kind of way, then you often start to realize what's important for this first version and what might not be so important. Versioning can look like version one usually is the bare minimum that you need to get from a to B. So what's the bare minimum our customer needs to achieve this task? What's the minimum our stake holders need to be happy or to alleviate some workload issues or something like that. Version 2 can then be what are the next most important things? What other things are really nice to add to this that could make that workflow easier or quicker or performance improvements, things like that, right? And in version three and beyond, we kind of look into what problems do we occassionally run into and how would that be nice to fix and things like that. Or the basically all the nice to have elements of your project. And this is important because if you don't do this, you'll start to start including other pieces and your stakeholders. We're start pushing for inclusions of other kind of nice to haves because they're worried that it will not happen if, if you don't put it in the project in the first place, it'll never happen, right? So this is a great way to kind of break this out, to kind of alleviate some stakeholder concerns. And to make sure that you're thinking of just what we need to do. Quick tip for determining the scope of your project is map out all the workflows that your user needs, right? If you have a really complicated project and you don't even know where to start, just break it down by user. If there's multiple user groups involved, break it down by user group. Map out each workflow that they need to do. So what information do you need to do to get from them? What information do they need to input? What do they information do they need to see and return? And figure that out. Once you have all of that, assess each one of those pieces of that workflow. And usually it'll look kind of like a flowchart. Assess each one of those workflows, and check. Is it really critical for that job to be done? Is it critical for the user to be able to do this part without, for them to be able to use your project, um, and then once you, you know, you can usually eliminate a couple of them through that. And once you have all these critical workflows design or thought out, then you can start designing your project and designing your V1. If you have a designer that's great, you can work with them. You can bring these workflows to that designer and then start working on the kind of final design for the project. But that's a great way to determine your V1 for complicated projects and not get lost in all the detail on all the nice to haves. And that's scoping. 5. Lesson 4: Feedback: Okay, now we're gonna go into building in feedback. If you're going to fail, fail fast. And that's what I learned when I was trying to learn a backflip on skis is that I should probably not be attempting that because it generally doesn't go well. Admitting what we don't know is important. Whenever we have a new idea, It's tempting to think that it'll work flawlessly and that we will solve the problem at hand beautifully with the solution we have in our head. Unfortunately, the reality is often the disappointing opposite. The world is a very complicated and unpredictable place and customers are even more unpredictable than most other things in the world. We often have to operate on assumptions. We often don't have a choice, right? We have to assume things and operate on our understanding of a situation and then build what we can based off of that. But what's important here is building and feedback from the start of your project. And that's a very important thing because if we don't have that feedback, we won't be able to guide the direction of our project. We're just gonna kinda be operating blind and not making sure where we're going. And in the future once we have kind of some customer feedback that can help us allocate resources, even decide to focus on other projects instead, if that's not, you know, if this project, for example, isn't being used, if you built a feature for a customer that isn't being adopted and you've tried some easy mitigation strategies for that. If it doesn't work, maybe that's not the right feature for the customer. Maybe that doesn't solve their problem. So we need that feedback to figure that out. And potentially not spend any more time on that feature and focus on other features instead. Without feedback, we're pretty blind. And here's a kind of an example for that, right? Imagine if you're going along a straight line here, or maybe some sort of hiking path or a trail. Maybe. If you have no feedback, if you just put a blindfold on and going around in the direction you think you might start kinda close. But by the time you get there, you're going to be pretty far off, right? Without feedback, you're going to be way out in the rhubarb and you're not going to know how to get back to where you need to be with a long feedback loop. So that means long iterations in your project and not gathering customer feedback. Early. You're going to have something in the middle here. You're going to, you're going to be able to see halfway along that you're going to kind of, you're kind of going off course, then you can correct a little bit, maybe, correct again. And you'll get closer to your goal with a tight feedback loop where you can see we start to get right on that path. We might be gone off a little bit at the start, just like all the other cases here. But then we can go right back to where we should be and be delivering the ideal amount of customer value as soon as we can. And that is really what's going to make our product and our customers successful in the long run. Feedback loops and practice. The way you're going to organize your project to build in these feedback loops from the start. Is not rocket surgery. It's fairly simple, right? You just have to organize a project in a way that allows us to collect real feedback from users as early and as often as possible. And what I like to use for that is something called the rat, the riskiest assumption test. There's a million other frameworks around there, right? Minimum Viable Product, minimum lovable product, earliest lovable product, earliest usable product. There's a million of them, right? But riskiest assumption tests are the most powerful ones because we can build the project in a way where the only goal is to test a riskiest assumption as early as possible. So to give you an example, Let's say we're building a suggestion feature for a customer. We can then, first off, build a very simple suggestion feature that just has the user interface with almost no back-end work, right? We don't have to actually have an algorithm that suggests anything useful. We can just basically put trash data in there. But if our customers click on that and they're actually interested in that, we can measure that using standard analytics tools. And we can see if that's even a useful feature that customers would be interested in using. And maybe we'll find that they don't even want it, they don't even need it. And that is our riskiest assumption is that customers would maybe want to use this feature. If we find that they don't, then there's no need to continue on that. We can remove that feature and continue on building more high-value projects. If however, we find that a lot of people are clicking on that and trying it, then it's worth investing in better algorithms and better predictive strategies to make this as much of a useful tool as possible. There's a great analogy here For, called the skateboard analogy. We don't want to build for trying to get from point a to point B, we're trying to find the easiest and simplest way we can do that. So we can collect customer feedback early, right? We don't want to be building the full car version here. We want to be building a skateboard first, right? Skateboards are really easy way to get from a to B. And then we can add maybe a handle and some bigger wheels and a motor and then maybe a seat. And then we have a car, right? That is exactly what the customer wants. We don't want to be building a car for years and then end up with a nice looking car. But that's maybe not what the user really wanted. And by that point, you've already lost most of your customers to your competitors because it took you so long to build. The advantage here for this. Or the analogy here is basically try and figure out the absolute simplest way to get from a to B and get customer feedback. Because that customer feedback is so much more valuable than operating on assumptions and having your customers waiting for some sort of solution. 6. Lesson 5: Review: All right. In review, that was a lot of information. So what do I need to do before I start on my next project? Here's what your ideal project plan should include your kind of like a checklist for when you're planning and when you're thinking of starting a new project, make sure you've done your CD3 analysis with numbers, right? You need to be able to justify why this project is more important than other projects and why it's worth pulling your engineer's focus, your designer focus, and your focus off of that project, off of their existing projects and onto this one, right? So that means you need to know the cost of delay and you need to get an estimate for the implementation time from your engineers. Usually. Next thing we need is assumptions, right? We need to figure out what assumptions we're making, right? And it's really helpful to write these out and to check these against maybe other colleagues or something. Make sure you state the assumptions you're making. And then figure out the easiest way to test the most risky ones first, right? So you're usually going to have a couple of ones in there that you're like, I'm pretty sure this is correct and maybe a couple in there that you're going to be like, ooh, I don't know about this one. This one is kind of a risky thing that could make or break the project. Those are the ones you want to identify, build those riskiest assumption tests, use that kinda skateboard method and test them. Last thing is scoping, right? Making a plan for when to call your project done and prioritize within your project what needs to happen for Version 1. So that means you're front loading the value within your project. You're kinda doing a sub prioritization. Not prioritizing your whole project, but prioritizing the small parts and components of your project to make sure you have the first and most valuable ones there in your version one and you deliver that value as early as possible. You can apply this to anything from feature development and roadmaps to answering emails and even life's biggest question, right? Like if you have questions like what career path is correct for me, what do I wanna do with my life? What should, what should I be focusing on? Do a CD3 analysis, it's a great way to figure out the, what you should be prioritizing. And you can test your riskiest assumptions with these riskiest assumption tests. And you can scope things and make sure to limit scope so that you don't get too caught up in one thing. It's a very useful tool, not just in product management. By taking a structured approach to prioritizing all of these things, you'll inevitably end up in the right place. And that's all. Thanks for joining me first lesson here, and I'm looking forward to seeing you guys in the next ones.