<img height="1" width="1" src="https://www.facebook.com/tr?id=1076094119157733&amp;ev=PageView &amp;noscript=1">

Learning What We Don't Know

Posted by James Brookes on 15/12/16 19:35

To thrive in today’s go-fast tech driven economy, a business needs to embrace uncertainty like never before, being able to accommodate rapid, unpredictable change, if that’s not an oxymoron.

We’ve had two Black Swan events happen in the last six months - first, Brexit and now the results of the US Presidential Election - I had doubted either would ever happen, but we’ve all been kicked out of our complacency. The world is suddenly a lot less predictable than we thought.

In my world of software projects, uncertainty is something that we equate with confusion, complexity, volatility, unpredictability. It’s not a good place to be, our project is going to derail, the team is uneasy, misunderstandings with the client will happen, the business won’t secure the RoI envisaged.

But to remove uncertainty, we have to learn stuff that we don’t know. How do we do this? We make assumptions, we engage users and manage their expectations as anticipated, but we don’t know the unknown unknowns. We are taught again and again that minimising uncertainty is a smart approach to decrease project risk and avoid bad outcomes. Or is it?

Nassim Nicholas Taleb, author of Black Swans the book about unexpected, game-changing events – wrote another book called AntiFragile in which he argued that it’s foolhardy to try to predict the future to try and reduce uncertainty. Instead, he says that it’s essential to embrace randomness and volatility, and to recognise how to thrive on uncertainty.

So how do you apply this thinking as a project manager? Rather than seek to eliminate risk in a project, recognise and include it as a fundamental element in the moving parts of a project. To do this, I’ve adopted the Lean Startup thinking to my project management philosophy.

Founder of the Lean Startup approach, Eric Reis, defines a startup as a human institution designed to deliver a new product or service under conditions of extreme uncertainty. That definition applies, including the bold text, to a new tech project.

Every startup is an experiment that attempts to answer a question: Can we build a sustainable business around this set of products and services? Likewise for a project: Can we create and deliver a sustainable product around this set of project tools and methods?

Traditionally, the product manager says, I just want this. In response, the engineer says, I’m going to build it, but adopting the agile approach and sprint based planning, building software in small steps embraces risk because we make lots of small ‘bets’, move incrementally, iterate and undertake retrospectives. It’s a learn-as-you-go-strategy.

Learning is the thus essential unit of progress for a project to avoid those Black Swan moments and learn stuff we don’t know. Effort that is not absolutely focused on learning can be eliminated. This is validated learning, backed up by empirical data collected from real experience, not the initial feature set assumptions in the initial sprint planning.

Success is not delivering a feature, success is learning how to solve the user’s problem. Until we can figure out how to make the product, it isn’t worth spending any engineering time on coding itself.

The Lean Startup provides a scientific approach to creating and managing startups and get a desired product to customers' hands faster. The method teaches you how to drive a startup-how to steer, when to turn and pivot, and when to persevere-and grow a business with maximum acceleration. It is a principled approach to new product development that overlays agile but puts learning at the heart of the build decisions.

Too many startups begin with an idea for a product that they think people want. They then spend months, sometimes years, perfecting that product without ever showing the product, even in a very rudimentary form, to the prospective customer. This is akin to the waterfall method of software development. Using the agile approach, companies can create new software projects by providing tools to test a vision continuously.

Lean thinking isn't simply about spending less money, or about failing fast, failing cheap. It is about putting a process, a methodology around the development of a product, A core component of Lean Startup methodology is the build-measure-learn feedback loop and we use this principle in our project management communications and culture.

We always lead the client’s thinking developing a minimum viable product (MVP) to begin the process of learning as quickly as possible. Once the MVP is established, we can work on tuning the engine. We also deploy the ‘Five Whys’ approach adopted in lean startup thinking - asking simple questions to study and solve problems along the way. When this process of measuring and learning is done correctly, it will be clear that a particular aspect of the project is either moving the drivers of the product or not. If not, it is a sign that it is time to pivot or make a structural course correction to test a new fundamental hypothesis about the product.

Embracing validated learning, the development process can shrink substantially. When you focus on figuring the right thing to build-the thing customers want and will pay for, you can adapt their plans incrementally, inch by inch, feature by feature.

At the start of a project, when you start exploring new ideas, you are usually in a space of maximum uncertainty. You don’t know if your ideas will work. So here are five Lean Startup essentials I’ve adopted to help me optimise the time, energy and resources on a project to systematically reduce the risk and uncertainty. 

Uncertainty is at its maximum at the beginning of a project; don’t waste time on overly detailed plans


Acknowledge that uncertainty is at its maximum at the beginning of a project. This sounds obvious, but often we don’t always behave as if we understand the implications of high uncertainty. You shouldn’t spend time on refining and perfecting your plans when uncertainty is high and thus the risk of getting it completely wrong is very high.

When uncertainty is high you should hold your project vision, have a sense of direction and strategy, but be rough and shape the details just enough to be able to test the initial key underlying assumptions. Flesh out your ideas just enough to start testing. Remember, things will change as you learn more.

Start testing the riskiest assumptions: what’s the most important thing that needs to be done to get users on board?


We make a lot of assumptions (aka hypotheses) about how and why your development idea is going to work when you start a new project. Your most important task is to make these assumptions explicit and then test them. By doing this you reduce uncertainty and the risk of failure.

Assumptions are essentially all the things that need to be true for your project to work. When you have your list of assumptions, you need to identify the most important thing that needs to be true for your idea to work. That’s the assumption/hypothesis you will test first?

Start with cheap and fast experiments


You need to start with fast and cheap experiments when uncertainty is at its highest and you’re most likely to get it wrong. Starting with expensive and time-consuming experiments can become very costly if your initial assumptions turn out to be wrong. Take lots of small steps and expect most to be wrong.

Large companies think innovation is about making large and risky bets. However, it’s the contrary. The bolder the innovation, the smaller the initial bets should be. You’ll learn from those quick and cheap experiments and persistently reduce the uncertainty and risk of failure. At one point you’ll have sufficient evidence that your idea will work and you can move to serious execution and scaling.

Optimise your experiments (MVPs) for learning


The core of the Lean Startup is to build small, ‘scrappy’ versions of what you intend to implement later on, based on the ‘Build, Measure, Learn’ cycle. But ‘build’ shouldn’t be taken too literally. At the early stages of a project it’s often faster and cheaper to explore alternative ways of testing your ideas. 

Overlaying the Lean Startup thinking above, I’ve also adopted the concepts of ‘ultra learning’ developed by Scott Young in an attempt to learn things faster:

  • Self-education

    – a self-education mindset puts you in the driving seat. Don’t passively absorb stuff, go and find it and create it for yourself. Aim for total immersion.
  • Deep focus

    – learning isn’t a passive task, it demands focus. Learning about tech requires time, effort and focus. The rewards for this effort enable you to grasp things you need to understand.
  • Be informed

    – don't just skim, make it the best available understanding and skill acquisition experience you can, get into it.
  • Practice triage

    – focus on the hardest stuff first and check your understanding after each step. Some passive learning is probably unavoidable but make learning a step-by-step process.
  • Use the Feynman technique

    - break down difficult concepts into bite size chunks.

So, you don’t know what you don’t know, but you have to learn what you don’t know. Don’t confuse knowing a lot about something with knowing a little bit about everything. Project management isn’t a paint by numbers exercise where stuff you don’t know can just be picked up along the way. It’s ok if you don’t know. It’s not ok if you ignore or avoid having to learn what you don’t know.

Most of the time, I think this behaviour is driven by embarrassment about not knowing something or having to admit you don’t know something. That’s tolerable in a five year old, it just not an acceptable excuse as an adult. There are no shortcuts. There will always be a day of reckoning for behaviour where accountability and responsibility trumps preservation of ego and it rarely ends well for anyone.

So, are you doing all it takes to reduce risk and uncertainty by learning? Try accepting that you can’t know and plan everything - difficult as it is. In fact, you never really can. Use the openness to possibilities that it represents to question assumptions, learn faster, and start running experiments which might fail (in meaningful ways). Thrive on uncertainty but make sure you have a process to navigate through the unchartered waters, and a process for learning. Remember, black swans have a nasty bite.

Recent Posts

Posts by Topic

see all

Subscribe to Email Updates