Reflections for the Part I of the book “Inspired” from Marty Cagan
Part I is about “Lessons from Top Tech Companies”. It’s only 30 pages, but it gave me quite some insights that I wanted to keep for myself. Here is a small summary of the key points I interiorized the most.
Disclaimer: it’s not a summary of the first part. The first part talks about lots of more things. But these ones are the ones that I though they were worth keeping for me; maybe because of my context, maybe because something else. I don’t know. But these ones remained in my brain after reading the first part.
No silver bullet
Some tweets ago I was discussing this topic with @artolamola on how some customers used to ask the “silver bullet” for product development.
What I meant with that tweet is what just Marty Cagan was saying here: it’s not about getting the recipe for the right product creation, but it’s more about creating the right product culture in the organization (and customers). This is what the book is about.
A classic and obvious example, but look around you and think again
Marty Cagan starts with a excessively classic example: “In mid 80’s I was creating a product. The process of creating was great, perfect, but when we finally released it, nobody bought it. Oh, I just learnt what all about creating the right product means”.
It’s a classic example.
Too classic that is painful.
If I look around myself, with customers and / or with products and / or with tasks I daily do or work on, this is, in different degrees and situations, still happening. That is why it is painful, because the example is too obvious, but there are places and situations in which we still do this. Think in your situations and you will probably find the same.
This way of tackling things is excessively hardcoded in our human brain!
Project centric vs Product centric companies
This is another concept that it’s supposed to be not surprising; but when you think about it twice, it really makes sense a little bit more than before.
It made me think of how lots of customers and companies work when approaching the design of a new product:
- “Let’s do a project to launch the MVP of this”
- “Mmh, there are some risks here. Let’s do a project to clear them out”.
- “Let’s do these two projects to launch these two products this year”
For one product, they even launch different projects at different levels and they might even do it in parallel:
- A project for the business case
- A project for design
- A project for developing it
- A project for launching the product and the marketing stuff
- …
This creates “orphaned” projects, as Marty Cagan says. We do stuff whose result is not valid afterwards. Maybe because the context has changed, or the project is dead, the leader changed, the learnings got late, etc.
And the inherent truth of products is that (1) you can’t know what will work or what customers will value, so maybe all the work that you do in one project is too much waste if you could learn that before, and (2) for things to work (time to money) you might need some more iterations that just one project. And you will not be able to know it beforehand.
We should look for another way of framing and tackling this work (the proposal of the book that will be seen later is maintaining two parallel threads, Discovery and Delivery).
Discovery — about doing experiments that clear risk. Prototyping. The faster the experiments, the better.
Delivery — about delivering the features discovered. Creating the product. The faster the releases, the better.
It might be complex to tackle this when you are a product company, but I even see it harder if you are a services company that work towards customers. As an example: imagine a customer asking you to help him with one product they want to launch. And they have some main questions to solve first to clarify if it is technically possible. Probably your conversations will start from this sentence from your customer: “I want you to tell me how much would be to do a project to clarify these questions”. Now, explain to your customer that you do not work like that anymore and that you should be doing Discovery and Delivery.
Agile fundamentals
In this book, Marty Cagan highlights from the principles these three fundamentals:
- It’s about tackling the risk first.
- It’s about colaborating and talking (not doing tasks sequentially).
- It’s about business, about solving problems (outcome vs. output).
It was a coincidence that a few days ago I just had written this for other purposes. I think I’m starting to like Marty :)
As you can see, there is something I miss for the statements of Marty: It’s also about learning, and learning fast.
The Issue with MVP
I’m working on a personal project called Tooché. It’s an open project / experiment, and anyone can follow its progress. In one of the recent posts, I was exposing my new doubts about the terminology of MVP.
Curiously, Marty also tackles this point. Although I’m not sure I’m 100% aligned with his proposal.
Marty says that MVP should not be about the product. It’s not about delivering a real product. It’s about doing experiments and validating results. Marty says that should not be “Minimum Viable Product” but we should name it “Minimum Viable Prototype”.
In my case, I’m lately thinking that we should kill this concept.
When we use MVP, our mindset suddenly focuses on “Let’s do this one MVP to clarify this learning. Later, we will do this other one”. This means that some people consider the MVP as the first version of the product.
Marty says that it’s not a product, it’s prototype. So in this case, what is the MVP? The first prototype we do? But, taking into account that Marty proposes to do experiments to tackle risks in 4 areas, it is really common that we can execute different experiments in parallel to solve them (as each one of them will have different time for gathering results and learnings). Maybe not in the execution, but the MVPs will not need to be executed in order. You do not need the result of the first one for the second one; as maybe the learning from the second one does not depend on the first one.
So, I am starting to think to talk plainly about “Small Viability Experiments”. What do you think?
And this is the beginning
This are the ideas that my mind started to boil up when I read the first 30 pages. The book is 326 pages long.
It’s going to be a long but enjoyable journey.
