I find this a really fascinating subject, but then again I suppose I should.
For me Lean Product Development (LPD) as defined by the thoughts of well known authors such as Steve Blank, Eric Ries and Marty Cagan in particular, fits nicely within the Cynefin complex domain and the probe, sense, respond approach to working within a complex adaptive system.
What follows are some of my thoughts on product development and links to the most useful stuff I’ve come across.
Note on MVP: Confused, you will be.
I find that the term MVP is used differently in many places, in many different ways and because of this the term has become highly confused. The originator of this term is Eric Ries in his book The Lean Startup, however I find that usually the term MVP is quite often used to mean the MMP or minimum marketable product, which is in essence the least thing that you would either want to sell or provide to a customer.
Marty Cagan calls the Ries MVP the MVP Test, with his MVP being the minimum product….
“that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available – also known as valuable, usable and feasible.”
Roman Pichler has a nice blog on this issue and on MMP and MVP, but we can see why things are so confusing right now in this space, there are also lots of other abbreviations that start with M too.
For me here I am going to use the term MVP to refer to Ries’s definition, which is simply about doing the least amount of work you can to find a customer to product fit, remember the most expensive way to do this is to actually write code.
Right then we need a place to start and I’m going to use the words of Jeff Patton who says what we should be looking to do is:
“Minimise output, Maximise outcomes”
Far too many projects focus on the outputs not outcomes, we seem as an industry to focus on delivering product features over delivering product value.
We really need to remember that ultimately the whole point of what we do is to make sure we build and deliver something that somebody actually wants, something that drives real customer or business impact or value, if we don’t deliver value we really should be asking ourselves why are we doing this?
A few months ago I did an assessment for a client of their Agile process for a particular product, I started at the top with the program manager and simply asked him what success looked like for him. He told me quite simply that he was measured on hitting project milestones on his plan and as the project team were doing that he was happy, the problems was that the product wasn’t really working for the customer for many reasons, but he didn’t care because the product was going out of the door.
This fortunately is where Lean Product Development can really help, right let’s get back to the MVP.
According to Ries, the purpose of the MVP is to obtain validated learning and this can only come from a customer or user. The MVP may actually not be any code at all, it could be a prototype or wire frame knocked up by a UX designer using a tool such as Sketch or Axure .. see here for a nice website on UX prototyping.
Interestingly Cagan waxes lyrically about using a rich, high-res prototype that forms a usable rolling MVP that allows users to interact with it and provides something very clear and unambiguous for the engineers to build, but the purpose and outcome remains the same. validated learning,
Ultimately and regardless of what approach we decide to use, what we are really talking about are doing experiments, this approach has its roots in Deming’s scientific method, PDCA ( Plan, Do, Check Act), Ries terms this Build, Measure, Learn
So as we experiment we learn, if something isn’t working we stop or dampen it, if it is working then we amplify it, again back to Cynefin as all experiments must be safe to fail, we don’t want to do something that causes real material pain if we have to kill it do we?
On that note its time for a quick segway into a past, painful experience
I was working for an Australian Bank in around 2006 as a development team lead and it was one of those non-agile projects where a real “us and them” grew up between the development team and the BAs, no togetherness here.
The BAs kept writing uber functional specs, detailing things down to a ridiculously low level, then flinging the spec over the fence to the developers looking for estimates with a high degree of accuracy, the concept now makes me cringe. However the development team just kept flinging it back looking for clarity and further details, the behaviours being driven by the level of accuracy insisted upon.by “the business”, another term that divides for you.
Eventually after 6 months of doing this and a not insignificant cost we stopped because we were simply not getting anywhere and in all this guess who had not been consulted, at all, not even once, yes that’s right the end users, I call this material pain, a smaller company may well have gone bust.
Incidentally this is where Thoughworks came into the picture and my own Agile transition started.
Back to the story ….
Once we have a fit then we move to creating something a bit more physical, this may simply be to code up a PoC, the important thing here to get it in quickly, get it working, then make it better..
Remember that perfect is the enemy of good.
Spotify have a really good way of describing this:
“Think It, Build It, Ship It, Tweak It” ( again Deming’s PDCA)
This is how spotify build products
Actually whilst we are talking about Spotify this is about their culture and well worth a look.
Another way at looking at product development is through Hypothesis Driven Development (HDD), this is used by Thoughtworks
Again we are back to Lean Startup, the Scientific Method and Cynefin, for me HDD appears to be a different option to Cognitive Edges Sensemaker product, I’ve never used Sensemaker, but the concept looks fine, perhaps the price may be high.
Finding an initial target or reference audience, users whom will be happy to work with this original PoC, however “dirty” it is, is very important. These are our innovators and early adopters, the people who happily get stuck in, report of even fix defects for you, however eventually the advantage gained by the product will diminish and they will move on to the next new bright shiny thing, that they believe may drive their business forward.
At this point you will need to get the product out to mainstream, this is called crossing the chasm and getting the product adopted by mainstream users, this is mentioned in the “what is value” Jez Humble video below . ( go to 13:00 and watch forward as it talks about Lean Startup).
I see this integrating with Cynefin like this-
The work with the innovators and early adopters sits in complex and moves towards complicated as the product fit becomes stronger. At the boundary between complex and complicated we need to be able to start to make the product as good as required to be able to move it into to mainstream, but I don’t see the product crossing into the complicated domain until its crossed the chasm.
Jez Humbles book Lean Enterprise is a must read for me, Jez puts this whole morass of information in a really good, simple, readable way.
Liz Keogh uses behavior driven development to drive product development, through her use of scenarios, I really like this approach and use it as a default approach. where I can.
see BDD with Cynefin with Liz Keogh
Liz talks about asking the question “give me an example of that” of a way of getting to the narratives or the stories behind user needs, to drive out “what they want, what they really really want”
I quite like Roman Pichler and the link between product Vision, Goals, Capabilities and Features / Stories and use it as the first place to start from.
Most recently I’ve really started to take an interest in Marty Cagan’s method as described in his book Inspired, the concept of usual, valuable and feasible ring very true with me.
There will be more to come here I’m sure but for now below are some “gold dust” references.
References and Further Reading
Eric Ries:
Book: The Lean Startup
Video:Eric Ries: “The Lean Startup” | Talks at Google – YouTube
Website:theleanstartup.com
Marty Cagan
Book: Inspire
Video – Marty Cagan at Mind the Product 2012
Here are a couple of nice summaries of the book and Marty’s ideas
Steve Blank
Book: The Four Steps to the Epiphany
Youtube Channel
I like the Mind the Product website too.
Roman Pichler:
Really like the stuff that this guy does, he talk hollistically across product development, not just in the Lean Startup space of Blank, Cagan and Ries. He ideas tie in what Humble has written in Lean Enterprise, so some nice confirmation bias there.
His site is great, lots of good resources like product Vision Boards
Book: Strategize
Agilisty Blog 