Demonstrating that you've learnt from why products/ projects 'failed' and how you've applied those learnings to your next piece of work is a valuable skill to demonstrate.

As Rory said, use the visuals to tell a story.

Cognitive Lode (from the team at Ribot) - is a really useful blog/newsletter that curates a list of biases that have relevance to product/service design http://coglode.com/

Nir Eyal: Hooked - Is a really good entry book, to understand how some of these biases can work in practice.

Books like Nudge, Drive, Contagious, Predictably Irrational - all good books and worth your time, but can get a bit long in some places.

I spent ages trying to learn processes and methodologies; should I learn to code? Do I need to do more testing? Do I need more features? Do I need to carve out more time for myself? Write more? Find more inspiration? Steal more?

The thing that changed the way I thought about everything was a simple maxim:

Ultimately the user experience is the product/service that the users engage (or don't engage) with at the end of it all.

As Dirk explained really well - everything else is just a tool to get you there. Wireframes and prototypes aren't the user experience, just communication tools.

This idea, challenged me to focus on greater collaboration, creating shared understanding across teams, less documentation, more experiments and learning. A lot of Lean UX stuff.

As I work for an agency I started to spend a lot more time 'thinking business' and helping clients set themselves up to build successful experiences (based on these principles), as ultimately, that'll make the UX work I do, more successful

I use 5 as the magic number for qualitative product testing but some stuff I've been re-thinking.

Is 5 still the magic number when you're doing generative research? (i.e finding problems to solve)

Is 5 still the magic number when you have a diverse user group (i.e TV app users)

Is 5 still the right number when you're investigating motivation to do something rather than the ability to do it? (this is probably where quantitative/MVP is preferred)

We adopted a lean methodology when it came to Product Discovery/ Exploration.

We work with a number of companies that traditionally aren't human centred. So using lean gave us a chance to start incorporating Human Centered design very early on.

Lean also emphasises speed to market and testing which is appropriate for the type of work we take on.

It's not for everyone - but for a new product it can be very beneficial in risk reduction for risk averse companies.

Yes I've tried it, yes it worked. Yes sometimes it feels too lean.

We now create a UX strategy based on time, budget and project - if lean is appropriate, we use it.

Every project requires a different approach it's important that your team and clients are aware of that.