Avoid Lean Product Management Shock

When you’re doing lean product management, you often change the original requirements. Most management types don’t like this, and you get in trouble. Here’s two things to do to fix that. Check out VMware’s toolkit for building your own app dev platform on-top of kubernetes.

[embed][www.youtube.com/watch](https://www.youtube.com/watch?v=umxYwlyITa4[/embed])

Also, check out a slightly longer version of the video.

Here's the transcript:

One major fear people have when they go to a more agile, weekly way of doing software, where you're discovering what features are, and maybe even changing course, is that upper level management will get very upset when they find out six or eight or 12 months later, that you haven't implemented the features they ask you to do ahead of time. 

Well, here's two things you can do to maybe mitigate that. 

The first is that if you have this situation, you probably haven't involved management as much as you need to. They should be involved - maybe not week to week they really should, but you shouldn't expect that - but they should be involved at least on a monthly basis to see what you've learned, to discover how the requirements, the features that you wanted to have in there have changed and become different.

And if they have this, they will start to have ownership and be involved in that as well. So one, it won't come as a shock and two, it might even start to be something that they think of as something they've been more involved in.

Use verified thinking to show why you changed the requirements

Now the second thing is that if you are doing a more lean approach and more design driven approach, where you're coming up with a theory, you're writing code, you're deploying it to users, and you're observing if it helped them and made things better or not, you should have a tremendous amount of data that's verifying and not verifying that a feature was good that delivered on the outcome that you wanted.

So you have reports that you can generate. You can prove that you didn't just whimsically decide not to do something. You can go over why you decided to implement something differently. Why you went after a different feature than management originally asked you to. 

So focus on those two things, try to have them involve frequently, show them what you've learned and how it's going to help management achieve whatever their outcomes were. And build up kind of report that shows the path with data about why you changed course or why you stayed course. And that turned out to be the right decision. 

Good luck.