Small systems are more flexible and malleable; therefore, experiments are easier. Some experiments would work well, others wouldn’t. Because they would keep things small and flexible, however, it would be easy to throw away the mistakes. This would enable the team to pivot, meaning they could change direction based on recent results. It is better to pivot early in the development process than to realize well into it that you’ve built something nobody likes.
Google calls this “launch early and often.” Launch as early as possible even if that means leaving out most of the features and launching to only a few select users. What you learn from the early launches informs the decisions later on and produces a better service in the end.
I would need numerous hands to count the number of times I have seen product managers and clients add scope to a release, horde bugs, or refuse to deliver an MVP because they thought the next release was the only chance they had to complete a feature. Just last week a friend of mine at a well-known healthcare company said:
“We missed the May release train, so we go live in December. And that means January because of holidays, so we’re just doing some extra stuff until then.”
As PPM Leaders how can we expect other’s to deal with the profound organizational changes that will be required by life in the digital age if we aren’t willing to show the way by changing our own ways of doing things?
The second thing required of us on the road to achieving agility is a willingness to lead others through the change we ourselves have committed to.