Posts Tagged ‘Experimentation’

This is the best book I’ve read on DevOps and it follows on nicely from Gene Kim’s other book The Phoenix Project.

It’s quite easy to think that DevOps practices are just something that dev teams deal with and the value is simply just an increase in throughput, but the book provides clarity on the colossal value that adopting a DevOps culture and the principles can have on teams, the business, and customers.

Throughout the book, Gene echoes the importance of having the whole product team (product manager, designer and several engineers)) involved in the transformation, as well as focusing on outcomes, and to achieve outcomes you need to collect data and learn through experimentation which is covered in the book too.

Gene gives good advice that it’s important to avoid funding projects and instead you should fund services and products: “A way to enable high-performing outcomes is to create stable service teams with ongoing funding to execute their own strategy and road map of initiatives”.

This is the most comprehensive and practical DevOps guide out there and the layout makes the content easy to digest. The book covers:

– History leading up to DevOps, and Lean thinking
– Agile, and continuous delivery
– Value streams
– How to design your organisation and architecture
– Integrating security, change management, and compliance

The principles and tech practices of:
1. Flow
2. Feedback
3. Continual Learning and Experimentation

“Our goal is to enable market-oriented outcomes where many small teams can quickly and independently deliver value to the customer”

In this book, Frank Barrett writes remarkable stories on leadership, learning, and innovation from a range of industry settings-from Jazz performance to automotive manufacturing.

Saying ‘Yes to the Mess’ ultimately means accepting as a management team that you don’t have control over how the teams on the front line get to the end goal or get a detailed plan on how they’re going to get there, and Instead, you can see how the team navigate through the uncertainty by learning along the way, being curious, creative, innovative, driven to succeed no matter how many experiments fail, and having fun along the way…aka improvisation.

Whilst there is no mention of product management in the book, there are clear lessons that can be learnt from jazz, which are also covered in other Lean product development books on how to handle uncertainty – by providing a vision and empowering the team to decide how they are going to get there, which as a result yields creativity, ownership, autonomy, learning, loyalty, speed, and value.

Jazz is a ‘risky business’ and the mindset of jazz would work in a multitude of environments with high uncertainty such as a product innovation hub, a new product that hasn’t been validated in the market, or a brand new feature for an existing product. Everything is an experiment to a jazz player, which reminds me of the hypothesis-driven product development approach.

After reading this book I definitely have a greater appreciation of jazz because of the level of risk and improvisation that takes place.

This wasn’t an easy read, but I enjoyed it, as it provided a unique angle on leadership from different perspectives.

Mmp

MVP (Minimum Viable Product) – the minimum amount of features needed to validate the business hypothesis with target customers.

MMP (Minimum Marketable Product) – the minimum amount of additional features on top of MVP which will allow marketing to start growing the product.


Validated learning is one of the five principles of the Lean Startup method and the MVP technique aims to test the business hypothesis. MVP was introduced in 2001 by Frank Robinson but popularised by Eric Ries through his book The Lean Startup.

Since startups tend to work under conditions of extreme uncertainty with limited resources, validating the hypothesis with target customers early in an efficient way using a prototype, wireframes, surveys or marketing material becomes even more important if it is to avoid the scenario of spending months or years building a product which customers don’t need or want (does not have product/market fit).

Achieving product/market fit would involve multiple iterations on the MVP based on target customer feedback, but once the product/market fit is validated it’s time to build the product for real and head towards an MMP by adding features to enable marketing to start growing and scaling the product, with the first set of additional features usually focusing on MarTech and improving the core customer experience.

Now, with an Agile mindset of iterating frequently based on value, it makes the MVP technique similar to Agile product development – building a product that customers need, want and loves by frequently talking to customers/target customers and we only need to look at three of the twelve Agile principles (also introduced in 2001) to see this:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Simplicity–the art of maximizing the amount of work not done–is essential.

Welcome changing requirements. Agile processes harness change for the customer’s competitive advantage.

Because of this, I prefer to use a broader definition of MVP: the minimum amount of effort needed to learn. This is because you can apply the MVP technique (Agile mindset) to a multitude of scenarios outside of launching a new product at a startup where you get the same benefits of reducing wasted money/effort/time by learning sooner rather than later, whether it’s a:

  • New Product – validate before building the whole product
  • New Feature – experiment rapidly before building and rolling out the full feature
  • New Process – being inclusive/gaining feedback before a full roll-out
  • Retrospective – ensure teams are empowered to make changes before having retros
  • Complex Solutions – start discussions early with assumptions before waiting for concrete answers
  • New House – view before purchasing
  • New Job – research/interview before accepting a job
  • New relationship – dating before marriage
  • New Car – test drive before purchase

Start small and fail fast!

Adding a new feature to an existing product is the most common scenario where you can use an MVP approach, but also where it’s most common for businesses to spend months building a new feature that turns out to be low value to customers. Similar to a new product, it’s important to validate new features where the projected value is uncertain by building a lightweight prototype/wireframes to validate with target customers when conducting interviews.

Saying this, if you have qualitative/quantitive data which gives high confidence that solving the problem will be valuable and time to market is important, then it’s equally effective to just develop and go live with the basics you need for the new feature to function at the right quality, then iterate in an Agile way.

When there is uncertainty, break it down, start small, test and learn quickly and it’s surprising how much easier and efficient the problem is to solve.

With tools to easily conduct remote customer interviews (UserZoom, Lookback.io), A/B testing (Firebase, Maxymiser) and prototyping (Sketch, Figma), it makes it easier more than ever for empowered product teams to efficiently conduct experiments to validate that the solution will solve the problem.

A thought-provoking read which explains the impossibility of predicting a certain future, but using #experiments, working together and staying open-minded results in a more probable future.

Remarkably this book was written just before the Covid-19 pandemic!

Even though futures are impossible to predict, by having shared, passionate guiding #principles or an inspiring #vision can increase the chances of reaching our goals even with extreme uncertainty, where we only need to look at how art and cathedrals are created as evidence of this.

The book touches on how traditional management is addicted to masterplans and want safety and certainty, not creativity and risk that come with experimentation, which as a result constrains their chance to map a safer future. This section reminded me of Waterfall vs. #Lean/#Agile.

More automation is a common prediction of the future, but Margaret explains that this comes with a risk of falling into a trap: more need for certainty, more dependency on technology; less skill, more need. The more we depend on machines to think for us the less good we become of thinking for ourselves.

“Making the future is a collective activity…the capacity to see multiple futures depends critically on the widest possible range of contributors and collaborators.”