A key to agile development is frequent feedback loop. Based on the feedback product manager can determine whether to make a course correction or continue on its course. Without feedback, PM won't be able to find out whether they have a right product market fit until product has been implemented and launched.
One implicit assumption about frequent course corrections is that as product owner PM will be able to steer the product development ship to the right orientation to get to the goal the fastest. Without PM's ability to keep their eyes on their original goal, all the feedback and subsequent changing tack will matter a little to shorten the product development cycle.
Take a look at the graph below:
It's converging, but it will take a considerably longer course correction to converge than the graph below:
The difference between the two graphs is that the first one had course correction done without really re-orienting to the project goal (Y value of 1) and the second one had methodical approach to introducing changes.
Comparing these two graphs a couple of points look obvious: PM needs to make big corrections early in the development cycle, and as product development cycle swings into the final stage there should be smaller and more measured changes.
One rule of thumb is that as it gets closer to product release date, PM should not introduce any work that will take longer to complete than the last round of feedback. Ideally it should be no more than square root of how long it took to implement last batch of changes based on the feedback. By limiting the number of days spent on incorporating feedback, PM can control how drastic of course correction that the engineering team will make.
So strive to get early feedback from customers. Always approximate how far the end product is from MVP, and make the smallest changes possible to turn it into MVP.
One implicit assumption about frequent course corrections is that as product owner PM will be able to steer the product development ship to the right orientation to get to the goal the fastest. Without PM's ability to keep their eyes on their original goal, all the feedback and subsequent changing tack will matter a little to shorten the product development cycle.
Take a look at the graph below:
| Source: http://math.eretrandre.org/tetrationforum/attachment.php?aid=720 |
It's converging, but it will take a considerably longer course correction to converge than the graph below:
 |
| Source:http://www.eng.cam.ac.uk/ |
The difference between the two graphs is that the first one had course correction done without really re-orienting to the project goal (Y value of 1) and the second one had methodical approach to introducing changes.
Comparing these two graphs a couple of points look obvious: PM needs to make big corrections early in the development cycle, and as product development cycle swings into the final stage there should be smaller and more measured changes.
One rule of thumb is that as it gets closer to product release date, PM should not introduce any work that will take longer to complete than the last round of feedback. Ideally it should be no more than square root of how long it took to implement last batch of changes based on the feedback. By limiting the number of days spent on incorporating feedback, PM can control how drastic of course correction that the engineering team will make.
So strive to get early feedback from customers. Always approximate how far the end product is from MVP, and make the smallest changes possible to turn it into MVP.
No comments:
Post a Comment