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


This is part five 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, in the fourth part we talked about the delivery process, and in this fifth and last part we will consider how we propose to learn.

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

5. Learning

After a successful delivery process the first version of the proposed value is out in production. Assumptions have been questioned and validated during the whole process, of course. Yet this dedicated learning phase is still very important. It exists so that we make sure to allocate time post-release to tweak the release based on the feedback that we collect from live users. Remember, the first package of value that is delivered is intended to be a scaled down core release, no more and no less than that which takes us to our primary goal with this value is to be released. This means that cool stuff that we came up with during the discovery phase has been left out of the scope. It also means that there are several potential releases left.

We operate this way because we believe that the core product that solves the customers main problem is most likely at least 80% of the value. This is what we want to tweak first to make sure that we capture this value. Once that work is done, and we have made new additions and changes, we measure again, and again we ask ourselves if we have now solved our customers problem adequately. Spotify has a similar approach which they describe with their mantra “Think it. Build it. Ship it. Tweak it.”. They are better than I am at making things sound cool, I guess.

Now, this “core product” is what some would call a “minimum viable product”, “minimum viable feature”, “minimum viable feature set”, or “minimum marketable feature”. A common problem with this otherwise intelligent strategy, is that companies often settle for the minimum release, and subsequently move on to the next minimum release in a completely different area. The problem here is of course that a product that consists of several minimum releases run the risk of being loved by none.

To handle this, we monitor what’s going on and then decide together: at what point, under which circumstances, are we ready to consider this work to be done. Once in agreement, we are ready to move on to the next thing. This gives us options regarding whether we think it’s time well spent to push this value from good to great, or if there’s more value in moving on.

So there it is. The baseline for our new product development process. To be continuously improved.