About frameworks and when to use them

The other day I was reading the Mind the product newsletter when a sentence hit me.

”We all fall in love with methods and frameworks, and it’s just as dangerous as when we fall in love with a solution instead of a problem.” - Martin Eriksson

I stopped and read it again and realized that Martin really put into words one of the most common pitfalls for product teams. Something that I saw (and see) happening over and over: we read about some smart people advocating for a framework, we start testing it, we like it, we follow it by the book, fall in love with it, and then think that it is the only good way of solving our problems. At least until we fall in love with the next one.

If you think about it, we would never have the same approach when we define a problem or a solution. We would never think that the same data can tell us the size of different opportunities, or that the same solution can solve multiple problems. But for whatever reason, when it comes to tools we seem to get blinded and when we find one that we like, we think that it can solve all our problems. It is like that famous quote: when you have a hammer, everything looks like a nail. We fell into the trap with A/B testing, then OKRs, going through opportunity solution trees, ”how might we”, and impact/effort mapping.

To me all these frameworks are valid, useful, and really important, the trick is to know when to use what. The key is not blindly following one way, but enriching the toolbox and the way you think to be able to pick the right tool to serve your purpose.

So I reflected on the latest frameworks that we have been using and summarized what worked and what didn’t for us.

If you want to read more about frameworks:

• Interesting reflection about transitioning from How might we to Why are we solving this

• Teresa Torres on the Opportunity Solution Tree

• Spotify on broadening its horizon on solutions

• I wrote about why you shouldn’t use dot voting and buy a feature here