A new hope: A Redesign of a Product Development Process – part 4


This is part four in a series of blogposts where we look into a re-design of a Product Development Process. In the first part we talked about how we can think about value, in the second post we discussed choosing value , in the third part we looked into how we explore value, and in this fourth part we will discuss how we deliver value

1. Understanding
2. Choosing
3. Exploring
4. Delivering
5. Learning

4. Delivering 

“Only a fool chooses tools before studying the job to be done” – Scott Berkun

Now, after the decision is made by the management team, the same team who investigated the task at hand is asked to deliver this to production. To make it a reality. I would strongly discourage breaking teams up and having different people doing the exploring and the delivering. The very reason why we put together this truly cross-functional team (some might call it a “Balanced Team”) is so that they can bring the value all the way across the finish line. And remember, at this stage the team have become knowledgeable of the challenge at hand, they have developed a deep shared understanding of both problem space and solution space and they have started to gel as a team.

How to work onward in the implementation phase is up to the team. Again, context matters. The task at hand varies. Stakeholders and their need for information and involvement vary. The people involved vary. Constraints vary. I propose to let the people who embark on this journey find their own way. I propose to let the team truly own their own process.

At their side is a coach (yes, that would be me) and a whole organization dedicated to helping the team make their own plan a reality. If you’re thinking that there’s a risk for some reinventing of the wheel here, you might be right. It could well be easier for us as an organization to just instruct the team that they must use some comes-in-a-box methodology for delivering, but I’d rather have the team make a few mistakes using their own ideas on how to best deliver, than go by the book and discover that the “not made here”-solution does not fit them, or the situation they find themselves in. There’s plenty of over-arching principles and heuristics that the team can use to guide them in their choices. These principles are sufficiently low on detail as to allow the team to design their own workflow moving onward.

In the next part of this series we’ll spend some time thinking about what happens after the delivery phase.

Leave a comment

Your email address will not be published. Required fields are marked *