I'm here with Greg Cohen, 20 year project management veteran and an author of Agile Excellence for Product Managers. Greg, let's talk about prioritization. It's a pretty important job for a project manager. How do you do that? >> So the simple explanation is you prioritize the things of highest business value first, and it's easy to understand. But that's extremely hard once again to implement well. So it really helps to understand what is your goal or objective with each release. because if you understand that then usually that prioritization falls out of it. >> And would you agree that a lot of problems are exacerbated by not really being sure what's valuable to the user and just trying to cream in lots of stuffs, instead of being focused on doing a few things really well? >> [CROSSTALK] That stuff is only our really big challenge and everyone has their pep thing that they want to prioritize within the company. So that's where socialization of the backlog becomes really important. It is also as you said really understanding what is of value to the user. It reminds me of an experience I had when I was a younger product manager. I was working on contract management systems and I came into this company, it was a new role and they said in 90 days I had to have this product out to three customers, this was a commitment, we couldn't break it. It was in that time understand actually what was really needed for the users and also what the capability in my team was. And I had a small team which I think at the time I thought was a deficient but it's probably what allowed us to hit our deadline, but I also had to leave a major capability out of that system, and I lost so much sleep about this. And it's really rare I think, when I think about my experiences to have something that was so binary as this decision. because often products succeed or fail on hundreds and thousands of smaller design decisions. But you put in there, but we left this out. Our customers were furious, the three users, they said they would abandon the product, if we didn't fix it. But the reality is from an MVP standpoint, what was the minimum viable? My goal was to deliver value to those users. And they realized value from this more limited release and when I say they realized value, they saved hundreds of thousands and millions of dollars using the product as is. And they opted to use the product as is over not use the product. I lost a lot of sleep on this decision, thought about it for many years since. I think for me the true test here, was the fact that when we did release the next version, it took us nine months to get our customers to adopt the new version of migrate over to it, which to me says, the first version did a very good job of delivering early value to them. >> And- >> I wish the decisions were that simple and went that well but I think that was one that was very clear that there was an enormously tough trade-off to be made. But it was necessary to hit the deadline and get value delivered to that user and our customers sooner rather than later. >> And was it understanding that there was a going and talking to customers and watching what they did and understanding that there was enough value there without that feature that gave you that confidence to finally make the decision, or what is just strictly a matter of necessity? How did you get there with that decision? >> Well, on these it's tough because you actually, I went out and talked to customers and spent a lot of time with them but at some point it becomes a judgement call. >> Mm-hm. >> And it's a conviction and I don't think you can know that a priority whether that decision was right. What I do know is that the amount of time it took us to build version one was just about the same amount of time as it took us to build version two. because this capability added that much more complexity to the design and testing of the product. So in that sense I had a choice. I could leave this capability out and get this product to my users in 90 days. Or I could, actually it took us four months to do that the second version or they could sit seven months without us delivering any value through them and we were broken contract. Great. Well, that is some great advised on making a hard decisions about your backlog from Greg Cohen. Thank so much, Greg.
