Three posts about product development

I’m catching up on some reading at the moment. Trying to make headway on some other work while jet lagged is proving a challenge. Anyway, here are a couple of nice posts about product development that popped up in my feed (hat tip to Mind the Product Weekly Newsletter.

## What do people do in the spaces in between?

When thinking about what people do with your product, also think about what they don’t do, and how to help them get to where they are going.

The takeaway from this post is that by mapping out these interstitial moments you can get to a better understanding of your users needs, and better map the requirements of what you need to build.

## We have been getting MVP wrong all this time, the point is to validate, not to delight for it’s own sake.

Forget “MVP”, focus on testing your biggest assumptions

The key point in this post is that when deciding what to ship, use each iteration as an opportunity to test your riskiest assumptions, and understand what you expect to learn with each release. If you don’t know what those assumptions are, or what you are going to learn, why are you shipping a feature? I imagine that this post is mostly directed towards products that are still exploring the market-fit space, however even established products live within spaces that are evolving so some of this thinking carries over too.

It reminds me of the Popperian view that you can’t prove hypothesis, but you can reject them, so each experiment to be most valuable should be constructed to try to reject the most critical hypothesis.

I think there is at least one counter argument to the main point in this post, but you know things are complex, so that’s OK. If you are in a space where you understand your users well, and you have considerable experience to hand, it is probably OK to just do what you know to be right in terms of benefitting the user.

Burn the roadmaps!!

Throw out the product roadmap, usher in the validation roadmap!.

This post was very welcome reading for me as I have a terrible relationship with product roadmaps, I just think that in a fast moving environment you don’t know what you are going to be doing in 12 months, and god forbid if you are tied down already to what you are going to be doing in 18 months, then you are probably not exploring a new space. Of course when you get to scale, and when you get to work on projects at scale, those kinds of timelines do in fact make sense, but I still like the idea of flipping the roadmap into one that is constructed around confirming/testing our understanding of the world in contrast to constructing how we want to roll our our features.

Lean value tree, and constant experimentation

The image at the top of this post is a representation of a tool called the lean value tree (see slide 30 from this deck. We have been using it a bit in the last two months at my current role, and I’m finding a lot of value in it. One of the things that ties all three of the posts that I have linked here together is the idea of experimentation. Understand your missing assumptions, test rigorously, be led in decision making about what you can learn. Something like the lean value tree can sit above these imperatives and help you make decisions around which experiments to spin up, and how to balance opportunities. Having worked it pretty hard in the past few weeks I can see that it has a lot of value, but it still does not beat open conversation in an open team.